Implementa la internacionalización en tu aplicación desde la arquitectura: gestión de strings, formatos locales, RTL, plurales y el flujo de trabajo de localización con traductores.
Cuándo usarlo: Implementar internacionalización técnica robusta desde la arquitectura hasta el flujo de trabajo con traductores
Herramienta recomendada: Claude
Eres un ingeniero de software con amplia experiencia implementando internacionalización (i18n) y localización (l10n) en aplicaciones web y móviles. Conoces los estándares Unicode, ICU, los formatos de mensajes más populares (ICU MessageFormat, GNU gettext, XLIFF), las librerías más utilizadas por ecosistema (react-i18next, vue-i18n, i18n de Rails, intl de Java), y los puntos problemáticos que aparecen cuando una aplicación no fue diseñada para internacionalización desde el principio. Necesito tu ayuda para implementar o mejorar la internacionalización de mi aplicación. Aborda los siguientes aspectos: **1. Diseñar para i18n desde el principio: los errores que cuestan caro** Antes de hablar de implementación, explícame los errores de diseño que hacen que i18n sea una pesadilla: - Concatenación de strings: por qué nunca debes construir frases concatenando traducciones de palabras sueltas - Asumir el orden de las palabras: por qué `"Hello " + username` es incorrecto y cómo usar placeholders correctamente - Hardcodear formatos de fecha, hora, número y moneda en lugar de usar las APIs de internacionalización - Asumir que el texto siempre ocupa el mismo espacio: el alemán puede ser un 30-40% más largo que el inglés - Iconos y emojis con significado cultural específico - Asumir LTR: cómo el soporte RTL afecta toda la arquitectura de UI si no se planifica desde el inicio **2. Gestión de strings y archivos de traducción** La infraestructura de los textos traducibles es fundamental. Explícame: - Formatos de archivos de traducción: JSON, YAML, PO/MO (gettext), XLIFF, ICU. Cuándo usar cada uno y sus tradeoffs - Organización de los archivos: namespaces, estructura de carpetas, granularidad de los archivos - ICU MessageFormat: cómo usar plurales, selección por género, ordinales y otras construcciones que varían según el idioma - Plurales: por qué casi ningún idioma funciona como el inglés (solo singular y plural) y cómo manejar las formas plurales de ruso, árabe o polaco - Keys vs values: cómo nombrar las claves de traducción para que sean mantenibles a largo plazo **3. Implementación por ecosistema** Explícame los patrones de implementación según el stack: - React/Next.js: react-i18next o next-intl. Configuración, lazy loading de traducciones, integración con SSR - Vue/Nuxt: vue-i18n. Modo legacy vs modo composición, integración con Nuxt - Node.js backend: i18n en respuestas de API, emails, notificaciones y mensajes de error - iOS/Android nativo: Localizable.strings, strings.xml. Cómo funciona el proceso de traducción para apps móviles - Ruby on Rails: la gem i18n, backend alternativo, i18n lazy lookup - APIs: cómo manejar el Accept-Language header, respuestas localizadas, mensajes de error internacionalizados **4. Soporte RTL (Right-to-Left)** El RTL es el mayor desafío técnico de i18n para equipos que no lo han hecho antes. Explícame: - Los idiomas RTL: árabe, hebreo, persa, y los detalles que los diferencian entre sí - CSS logical properties: la forma correcta de hacer layouts que funcionen tanto en LTR como RTL sin duplicar el CSS - Frameworks CSS y RTL: cómo Tailwind, Bootstrap y Material UI manejan RTL - Bidireccionalidad dentro del texto (bidi): cómo mezclar texto RTL con números y URLs correctamente - Iconos y assets direccionales: qué iconos hay que voltear en RTL y cuáles no **5. El flujo de trabajo de localización con traductores** El código es solo la mitad del trabajo; el otro es el proceso con traductores. Explícame: - TMS (Translation Management Systems): Phrase, Lokalise, Crowdin, Transifex. Cómo integrarlos en el workflow de desarrollo - CLI tools y automatización: extracción de strings, push/pull de traducciones, integración en CI/CD - Contexto para traductores: cómo proporcionar screenshots y contexto para que las traducciones sean correctas - Pseudo-localización: cómo testear el layout y la expansión de texto antes de tener las traducciones reales - Continuous localization: cómo integrar la localización en el sprint para que no sea un bloqueo al hacer release **6. Testing y calidad de i18n** La internacionalización es propensa a bugs silenciosos. Explícame: - Qué testear: strings sin traducir, keys faltantes, truncado de texto por expansión, formatos de fecha/número, RTL layout - Herramientas de linting para detectar strings hardcodeados en el código - Testing automatizado de RTL: cómo incluir tests visuales de RTL en el pipeline de CI - Cómo validar traducciones antes del release: revisión nativa, herramientas de QA lingüístico Dame recomendaciones específicas adaptadas a tu stack y el estado actual de tu aplicación cuando me cuentes más contexto.