Aprende a diseñar e implementar una arquitectura técnica que soporte la internacionalización (i18n) y localización (l10n) de tu aplicación desde el inicio. Evita la deuda técnica de la internacionalización tardía.
Cuándo usarlo: Diseñar la arquitectura técnica de internacionalización y localización de software
Herramienta recomendada: Claude
Actúa como un arquitecto de software con experiencia en proyectos de internacionalización a gran escala. Necesito una guía técnica completa para diseñar e implementar la internacionalización y localización de una aplicación web o móvil. **Por qué la i18n debe diseñarse desde el principio** La internacionalización tardía es costosa. Refactorizar una aplicación que asume un único idioma, zona horaria y formato de datos puede consumir semanas o meses de desarrollo. El coste de hacerlo bien desde el principio es marginal comparado con el coste de la deuda técnica de i18n. Además, una mala implementación genera bugs sutiles: fechas que se muestran incorrectamente, strings truncados por diferencias de longitud entre idiomas, caracteres especiales que rompen formularios. **Lo que necesito que desarrolles** 1. **Principios de arquitectura i18n**: Qué decisiones de arquitectura afectan a la internacionalización: separación de strings de la lógica de negocio, uso de sistemas de gestión de traducciones (TMS), diseño de base de datos para contenido multilingüe, gestión de URLs internacionalizadas (subdominio vs. subdirectorio vs. parámetro). 2. **Gestión de strings y archivos de traducción**: Formatos estándar (PO/MO, JSON, XLIFF, ICU MessageFormat). Cuándo usar cada uno. Cómo estructurar los namespaces de traducción. Cómo manejar pluralización, género gramatical e interpolación en diferentes idiomas. 3. **Fechas, horas, números y monedas**: El infierno de los formatos locales. Cómo usar la API Intl de JavaScript o equivalentes en otros lenguajes. Gestión de zonas horarias (almacenamiento siempre en UTC, conversión al mostrar). Formatos de fecha que varían por cultura (DD/MM/YYYY vs MM/DD/YYYY vs YYYY-MM-DD). 4. **Diseño de UI para múltiples idiomas**: Cómo diseñar interfaces que soporten idiomas de diferente longitud de texto (el alemán suele ser 30% más largo que el inglés), idiomas RTL (árabe, hebreo), y caracteres especiales de diferentes sistemas de escritura. Uso de unidades relativas, truncado inteligente y diseño flexible. 5. **Pipeline de localización y flujo de trabajo**: Cómo integrar la traducción en el proceso de desarrollo: extracción automática de strings, integración con herramientas de TMS (Phrase, Lokalise, Crowdin), revisión y aprobación de traducciones, importación al repositorio. Cómo evitar strings perdidos o desactualizados. 6. **Testing de i18n**: Cómo hacer QA de una aplicación internacionalizada: pseudolocalización para detectar problemas de UI sin traducciones reales, testing de RTL, testing de caracteres especiales (ñ, ü, 中文, árabe), verificación de formato de fechas y monedas por locale. **Formato de salida** Estructura la respuesta con secciones técnicas claras. Incluye ejemplos de código en al menos dos lenguajes o frameworks populares. Proporciona una checklist de implementación de i18n y los diez errores más frecuentes en proyectos de internacionalización.