Internacionalización (i18n): beneficios, mejores prácticas y consejos de implementación

¿Qué es i18n?

La internacionalización (i18n) es el proceso de diseño de software para que pueda adaptar a diferentes idiomas y regiones sin cambiar su código. El apodo "i18n" proviene del hecho de que hay 18 letras entre la "i" y la "n" en la internacionalización.

Piense en i18n como sentar las bases para:

• Localización (l10n): Traducir y adaptar tu contenido para un mercado específico.
• Globalización (g11n): Coordinar la preparación y las operaciones del producto en todos los mercados.
  
  

En la práctica, i18n se trata de cerciorar de que su aplicación pueda manejar:

• Texto en cualquier idioma
• Fechas, horas, números y monedas en el formato correcto
• Reglas de pluralización que coinciden con la gramática local
• Diseños de derecha a izquierda (como árabe o hebreo)

Por qué es importante i18n

Invertir en i18n por adelantado aporta beneficios tangibles a sus equipos de ingeniería y productos:

• Menores costos de localización: Extraer y reemplazar cadenas es más fácil cuando la lógica de traducción está integrada desde el principio.
• Desarrollo más rápido: La infraestructura compartida para gestionar cadenas reduce el retrabajo futuro.
• Mejor UX: Los usuarios ven el contenido en su idioma, formateado de manera natural.
• Escalabilidad: Las aplicaciones se pueden lanzar en nuevos mercados con menos cambios de código.

Patrones de implementación de i18n en aplicaciones modernas

A continuación se muestran algunos patrones comunes para implementar i18n en aplicaciones de nivel de producción. Recorreremos React (frontend), iOS y Android.

Independientemente de la plataforma, las traducciones suelen provenir de un sistema de gestión de traducciones (TMS) como Smartling como JSON o archivos de recursos. Luego, tu app carga estos archivos en tiempo de ejecución a través de un marco i18n o una API de localización nativa, lo que garantiza que se muestren las cadenas correctas para el idioma o la configuración regional del usuario.

Frontend (React)

Las aplicaciones modernas de React suelen usar una biblioteca i18n dedicada. Dos de los más populares son i18next y FormatJS, que son independientes del marco. En React, sus respectivas implementaciones son react-i18next (basada en funciones y ganchos) y react-intl (basada en componentes y ganchos, basada en ICU MessageFormat). Ambos se integran limpiamente con canalizaciones empresariales y controlan la pluralización, las variables y el formato con reconocimiento de configuración regional.

1. Reacciona con i18next + react-i18next

i18next es una de las bibliotecas i18n de JavaScript más populares y, cuando se combina con los enlaces react-i18next , brinda a las aplicaciones React una API poderosa y fácil de usar para cargar y renderizar traducciones.

En el siguiente ejemplo, recorreremos un patrón i18n empresarial común. Definiremos archivos de traducción, inicializaremos i18next en el punto de entrada de la aplicación y luego renderizaremos las traducciones en componentes. Este enfoque funciona en todos los marcos, se integra perfectamente con la mayoría de los sistemas de gestión de traducciones (TMS) y se escala bien a medida que crece la aplicación, ya sea que muestre cadenas estáticas o mensajes dinámicos basados en variables, como recuentos.

Ejemplo de patrón i18n: i18next + reacti18next

Probablemente recibirá contenido como archivos JSON de su sistema de gestión de traducciones. El siguiente ejemplo de archivo JSON muestra cómo se almacenan las traducciones para el inglés. Cada entrada tiene una clave única y las formas plurales se definen por separado para que la biblioteca pueda elegir la correcta en función del recuento que pase. Su TMS generará un archivo coincidente para cada idioma admitido.

{

  "welcome": "Welcome",

  "visits_one": "Visitaste {{count}} vez.",

  "visits_other": "Visitaste {{count}} veces."

}

A continuación, verá un ejemplo de cómo configurar i18next para que sepa qué idiomas admite su aplicación, dónde encontrar las traducciones y qué hacer si falta una traducción. Este archivo de instalación se ejecuta una vez cuando se inicia la aplicación (a menudo en el archivo de punto de entrada como index.js o main.tsx) para que las traducciones estén listas antes de que se procese cualquier interfaz de usuario. La centralización de la configuración en un solo lugar mantiene la coherencia de la lógica de localización en toda la aplicación.

importar i18next desde 'i18next';

import { initReactI18next } de 'react-i18next';

import en from './locales/en/translation.json';

import fr desde './locales/fr/translation.json';

configuración regional const = 'fr'; En producción, resuelva dinámicamente

i18siguiente

  .use(initReactI18next)

  .init({

    lng: locale,

    fallbackLng: 'en',

    Recursos: {

      en: { translation: en },

      fr: { traducción: fr }

    },

    interpolación: { escapeValue: false }

  });

exportar el valor predeterminado i18next;

Una vez inicializado i18next, puedes usarlo en cualquier parte de tu app. En el siguiente ejemplo, el gancho useTranslation recupera la función t , que toma una clave y variables opcionales para representar la cadena correcta. Cuando pasa count como variable, i18next selecciona automáticamente la forma plural correcta en función del archivo de traducción.

import { useTranslation } de 'react-i18next';

import './i18n';

export default function App() {

  const { t } = useTranslation();

  recuento constante = 3;

  return (

    <>

      <h1>{t('welcome')}</h1>

      <p>{t('visitas', { count })}</p>

    </>

  );

}

2. Reacciona con FOrmatJS + react-intl

react-intl es parte del ecosistema FormatJS y proporciona un enfoque basado en componentes para i18n en React. Se basa en el estándar ICU MessageFormat, por lo que obtiene pluralización integrada, formato de fecha / número y reservación de configuración regional.

En el ejemplo siguiente, configuraremos archivos de traducción, ajustaremos la aplicación en un IntlProvider y renderizaremos texto localizado mediante FormattedMessage. Este enfoque es adecuado para equipos que desean un estilo declarativo basado en componentes para manejar i18n en React.

Ejemplo de patrón i18n: FormatJS + react-intl

El archivo JSON siguiente contiene traducciones que usan la sintaxis ICU MessageFormat, que coloca la lógica plural dentro de la propia cadena. Esto mantiene todas las reglas del idioma en un solo lugar y permite a los traductores controlar completamente la gramática sin la intervención del desarrollador. Su TMS gestiona estos archivos por configuración regional.

{

  "welcome": "Welcome",

A continuación, verás un ejemplo de ajuste de la aplicación en el componente IntlProvider . Esta es una configuración única, generalmente realizada en un componente raíz como Root.tsx o index.jsx. Hace que la configuración regional activa y sus mensajes estén disponibles en toda la aplicación para que cualquier componente pueda usarlos sin importaciones adicionales.

import { IntlProvider } desde 'react-intl';

import en from './locales/en.json';

import fr desde './locales/fr.json';

const MESSAGES = { en, fr };

const locale = 'fr';

export función predeterminada Root() {

  return (

    <IntlProvider locale={locale} messages={MESSAGES[locale]}>

      <App />

    </IntlProvider>

  );

}

Por último, lea a continuación para ver cómo el componente FormattedMessage busca una traducción por su ID y controla la pluralización automáticamente. Todo lo que necesita pasar es el recuento y la biblioteca aplica las reglas de lenguaje correctas de su archivo JSON.

import { FormattedMessage } desde 'react-intl';

export default function App() {

  recuento constante = 3;

  return (

    <>

      <h1><FormattedMessage id="welcome" defaultMessage="Welcome" /></h1>

      <p><FormattedMessage id="visits" values={{ count }} /></p>

    </>

  );

}

Algunos consejos adicionales para el uso en producción:

• Fuente local: En aplicaciones reales, determine la configuración regional de forma centralizada (por ejemplo, desde una URL como /fr/*, el perfil del usuario o una configuración proporcionada por el servidor) y pásela a <IntlProvider>.
• Organización de mensajes: Para la escala, divida los archivos de mensajes por dominio o característica (por ejemplo, auth.json, dashboard.json) y fusionarlos para la configuración regional activa.
• Alternativas: defaultMessage es su red de seguridad durante la implementación: manténgalo en su idioma de origen.
• Carga asíncrona (opcional): Para paquetes grandes, importe dinámicamente archivos de mensajes por configuración regional (división de código) antes de representar <IntlProvider>.

Ios

iOS le brinda herramientas de localización sólidas listas para usar, pero escalar limpiamente a muchas configuraciones regionales requiere una implementación cuidadosa de las mejores prácticas de i18n. De lo contrario, sin una estructura clara, puede terminar con claves duplicadas, formato inconsistente y archivos de traducción que se convierten en un dolor de cabeza para mantener. La clave es tomar algunas decisiones estructurales con anticipación para que su localización se mantenga organizada y sea fácil de ampliar a medida que se agregan nuevos mercados.

Consejo 1: Organice los recursos de una manera que se amplíe

Un buen lugar para comenzar es con catálogos de cadenas (.xcstrings) en Xcode 15 y versiones posteriores, o .strings/.stringsdict archivos si estás en una configuración anterior. Estos funcionan bien con un TMS, que generalmente le enviará traducciones en formato XLIFF. Puede importarlos directamente a su catálogo, y el sistema se encargará del trabajo pesado de fusionarlos y gestionarlos.

Probablemente le resultará más fácil mantener las cosas ordenadas si organiza los catálogos por función o módulo. Los archivos más pequeños y específicos facilitan la búsqueda de claves, la revisión de cambios y la entrega de trabajo a los traductores. Aquí hay un ejemplo de cómo podrías organizarlos:

Recursos

  i18n/

    Auth.xcstrings

    Pago.xcstrings

    Perfil.xcstrings

Sugerencia 2: Manejar la pluralización en el catálogo, no en el código

La pluralización es otro lugar donde la estructura da sus frutos. Es mejor definir todas las reglas plurales en el catálogo en lugar de en Swift, de modo que su código simplemente pase variables y la frase correcta se elija automáticamente para cada idioma. Así es como se vería en el catálogo:

Clave: unread_messages

Formato: Plural

Uno: "%d mensaje no leído"

Otro: "%d mensajes no leídos"

Y así es como puedes usarlo en Swift:

let unreadCount = 3

let format = String(localizado: "unread_messages")

let mensaje = String.localizedStringWithFormat(format, unreadCount)

"3 mensajes no leídos"

De esta manera, no está codificando la gramática en el código y los traductores pueden obtener los detalles correctos para cada idioma.

Consejo 3: Centralice el formato de números, fechas y monedas

También querrá centralizar el formato de número, fecha y moneda para que cada parte de la aplicación se sienta consistente. Una utilidad o servicio compartido puede ayudar con eso. Aquí hay un ejemplo simple usando la moderna API FormatStyle de Swift:

precio let = 19.99

let display = price.formatted(.currency(code: "EUR"))

"19,99 €" o "19,99 €" dependiendo de la ubicación

Al mantener organizados los recursos de cadena, controlar la pluralización en el catálogo y centralizar todo el formato compatible con la configuración regional, configura la aplicación iOS para que crezca sin crear trabajo de mantenimiento adicional. Una vez que esas prácticas están en su lugar, el proceso para agregar nuevos idiomas se vuelve mucho más previsible y mucho menos estresante. Ahora echemos un vistazo a Android, que ofrece sus propias herramientas de localización integradas.

Android

El sistema de recursos de Android ya está diseñado teniendo en cuenta la localización, pero mantenerlo mantenible en muchos idiomas requiere algo de planeación. Si mantiene todo en un archivo grande o dispersa las reglas gramaticales en el código, puede complicar rápidamente. En su lugar, priorice la organización segmentada de archivos, defina todas las reglas gramaticales en XML y cerciorar de que su formato y diseños funcionen para todos los sistemas de escritura que planea admitir.

Consejo 1: Mantener los recursos organizados por característica

Para la mayoría de los equipos, las traducciones provendrán de un TMS como archivos XLIFF. Los importas a los directorios res/values para cada configuración regional, y Android se encarga de hacer coincidir las strings correctas con el idioma del usuario.

Dividir sus recursos en archivos separados por característica es una forma sencilla de hacer la vida más fácil. Los archivos más pequeños hacen que sea más rápido revisar los cambios y ayudan a evitar conflictos de combinación.

app/src/main/res/

  values/strings_auth.xml

  values/strings_checkout.xml

  values/plurals_checkout.xml

Consejo 2: Defina reglas gramaticales en recursos, no en código

Al igual que en iOS, la pluralización es una de esas cosas que se maneja mejor en los recursos para que los traductores puedan adaptarla por idioma sin cambiar el código. Aquí hay un ejemplo de un recurso plural en inglés:

<plurals name="checkout_cart_items_count">

    <item quantity="one">%1$d item</item>

    <item quantity="other">%1$d artículos</artículo></item>

</plurals>

Y así es como lo usarías en Kotlin:

val msg = resources.getQuantityString(

    R.plurals.checkout_cart_items_count, contar, contar

)

De esta manera, nuestro código se mantiene limpio y Android elige automáticamente el formulario correcto según la configuración regional.

Consejo 3: Usar formato con reconocimiento de configuración regional 

Para los diseños, es un buen hábito usar start y end en lugar de left y right para que se adapten a idiomas de derecha a izquierda como el árabe o el hebreo:

<LinearLayout

    android:paddingStart="16dp"

    android:paddingEnd="16dp"

    android:layout_width="match_parent"

    android:layout_height="wrap_content">

</LinearLayout>

Y al formatear números o monedas, pasa la configuración regional actual de la aplicación para que todo se vea consistente:

val appLocale = LocaleListCompat.getAdjustedDefault()[0] ?: Locale.getDefault()

val price = NumberFormat.getCurrencyInstance(appLocale).format(1234.56)

"$1,234.56" o "1 234,56 €"

Al final, hacer bien Android i18n se trata principalmente de dejar que la plataforma haga el trabajo pesado. Al mantener todo el texto en los recursos, estructurar esos recursos con carpetas específicas de la configuración regional y crear RTL y formato compatible con la configuración regional desde el primer día, evita las trampas comunes que hacen que la localización sea frágil. Muchos de estos principios se hacen eco de las mejores prácticas de iOS, pero el sistema calificador de recursos de Android significa que a menudo puede admitir nuevos idiomas simplemente agregando los archivos correctos. Si se hace bien, escalar a nuevas configuraciones regionales se convierte en un proceso previsible y de bajo esfuerzo.

Errores comunes de i18n

Desafortunadamente, incluso los sistemas bien construidos a veces se encuentran con problemas evitables. La siguiente tabla menciona algunos de los errores más comunes, por qué causan problemas y cómo prevenirlos. Considere esto como una referencia rápida que puede usar para verificar su propia configuración antes del envío.

Preparación para la localización a escala

Una vez que su aplicación esté configurada para la internacionalización, el siguiente paso es hacer que la localización sea lo más eficiente y de bajo mantenimiento posible. Algunas herramientas de automatización y flujos de trabajo pueden llevarlo de "podemos traducir" a "podemos implementar nuevos idiomas rápidamente, sin carga de desarrollo adicional". Considerar:

• Usar un sistema de gestión de traducciones (TMS) con una API de nivel empresarial, como Smartling, para sincronizar archivos de traducción y gestionar flujos de trabajo de revisión.
• Automatización de la extracción y entrega de cadenas mediante la canalización de CI/CD.
• Uso de herramientas de IA (como AI Hub de Smartling) para traducciones rápidas de primer paso con controles de calidad incorporados como manejo alternativo y mitigación de alucinaciones.

Reflexiones finales

La internacionalización es una práctica fundamental para cualquier producto que se globalice, y lo más pronto posible la implemente, menos dolores de cabeza tendrá más adelante. Combine prácticas estables de i18n con flujos de trabajo de automatización y pruebas de traducción, y su equipo estará bien equipado para enviar software listo para el extranjero de manera más rápida y segura.

¿Quieres profundizar? Echa un vistazo a Smartling Seminario sitio web de la Conferencia Global Ready sobre i18n estrategia en la era de la IA.