Gestiona varios idiomas en tu app

Flutter gestiona la localización mediante el paquete oficial intl y los archivos ARB. ARB, por Application Resource Bundle, es un formato JSON sencillo donde cada clave corresponde a un texto traducido, y mantienes un archivo por idioma, como app_en.arb y app_es.arb. Activas la generación de código en tu pubspec para que Flutter construya una clase de mensajes tipada a partir de esos archivos, y luego lees los textos con AppLocalizations.of(context) en vez de escribirlos a mano. El framework elige el archivo ARB correcto según el idioma del dispositivo, y MaterialApp expone una lista supportedLocales y unos delegates de localización que también traducen widgets integrados como los selectores de fecha. El flujo es: extraer cada texto a tu ARB plantilla, traducir las copias, regenerar y referenciar los getters generados en tus widgets.

1. Añade flutter_localizations e intl a pubspec.yaml, y activa generate: true en la sección flutter.
2. Crea un archivo plantilla como lib/l10n/app_en.arb con tus textos de origen y sus descripciones.
3. Añade un archivo ARB por idioma de destino, manteniendo las mismas claves con valores traducidos.
4. Conecta supportedLocales y localizationsDelegates en tu MaterialApp para que Flutter resuelva el idioma del dispositivo.
5. Sustituye el texto escrito a mano por los getters AppLocalizations.of(context) y recompila.

React Native no tiene una capa de localización integrada, así que la pila habitual es i18next con react-i18next, junto con un detector de idioma. Guardas las traducciones como namespaces JSON, un objeto por idioma, y envuelves tu app en un I18nextProvider. Los componentes leen el texto con el hook useTranslation y una llamada t('key'). Para detectar el idioma del dispositivo añades una librería pequeña como react-native-localize, que informa de los idiomas preferidos y la región para elegir un valor por defecto sensato y recurrir con elegancia cuando falta una traducción. i18next tiene soporte de primera para pluralización e interpolación, lo que te ahorra escribir esa lógica a mano. El modelo mental es idéntico al de Flutter: los textos viven en archivos de datos, el código referencia claves y el idioma activo decide qué archivo gana.

• i18next y react-i18next para el almacén de traducciones y el hook useTranslation.
• react-native-localize para leer los idiomas preferidos y la región del dispositivo.
• Un archivo JSON por idioma, idealmente dividido en namespaces por función para que los archivos sean pequeños.
• Un manejador de clave ausente que recurra a tu idioma por defecto en vez de mostrar una clave en bruto.

Son los detalles que separan una app traducida de una realmente localizada. Las reglas de plural varían según el idioma: el inglés tiene dos formas, pero el polaco y el árabe tienen varias, así que debes usar la sintaxis de plural de tu librería en lugar de un if-else sobre un contador. Fechas y números también varían, donde 1,000.50 en Estados Unidos es 1.000,50 en gran parte de Europa, y los formatos de fecha invierten el orden de día y mes. Tanto intl en Flutter como Intl en JavaScript los formatean correctamente a partir del idioma, así que nunca los formatees a mano. Los idiomas de derecha a izquierda como el árabe y el hebreo necesitan que todo el diseño se refleje, no solo el texto. Flutter lo hace automáticamente cuando fijas la dirección del texto según el idioma, y React Native expone I18nManager para lo mismo. Prueba el sentido de derecha a izquierda pronto, porque adaptar un diseño reflejado tarde es doloroso.

Los archivos de traducción se pudren rápido cuando un equipo crece, así que un poco de estructura vale la pena. El objetivo es que cualquier desarrollador pueda añadir un texto, cualquier traductor pueda encontrarlo y ninguna clave salga vacía. Unos pocos hábitos lo mantienen limpio, tanto en Flutter como en React Native.

• Mantén un idioma como fuente de verdad, normalmente el inglés, y trata cada otro archivo como su traducción.
• Divide los textos en namespaces o archivos por función, para que una pantalla de pago no viva en el mismo archivo de 4.000 líneas que el onboarding.
• Añade una descripción o comentario a cada clave para dar contexto, porque «Abrir» puede ser verbo o adjetivo.
• Ejecuta un paso de lint en CI que rompa el build cuando a un idioma le falte una clave que existe en el archivo de origen.
• Nunca dejes que un desarrollador escriba el texto final a mano. Añade primero la clave y luego rellena las traducciones, para que nada esquive el pipeline.

Una vez que la app habla varios idiomas, la página de la tienda también debe hacerlo, y aquí se ganan o se pierden muchas instalaciones. Tanto la App Store de Apple como Google Play permiten añadir una localización por idioma, cada una con su título, su subtítulo o descripción corta, su descripción larga, su campo de palabras clave y su propio juego de capturas. Un visitante que navega la tienda en español ve tu ficha en español, y si no la has creado, ve tu idioma por defecto. Ese desajuste mata la conversión en silencio, porque alguien que no puede leer tus capturas rara vez instala. Localizar la ficha son tres cosas: traducir los metadatos, adaptar las palabras clave a cómo busca la gente de verdad en ese idioma, y localizar las capturas para que los rótulos y el texto en pantalla coincidan. No hace falta localizar todos los mercados de golpe, pero cada mercado en el que entres merece los tres.

Los metadatos y los visuales son trabajos distintos. Para las palabras, nuestra guía sobre cómo generar los metadatos de la App Store cubre escribir títulos, subtítulos y descripciones que respeten los límites de caracteres de cada tienda. Para las imágenes, crear visuales de la tienda fácilmente explica cómo producir juegos de capturas localizados sin un diseñador por idioma. Trátalos como una pareja, porque una descripción traducida sobre capturas en inglés se ve a medio hacer, y los revisores lo notan.

No conviene localizar a todos los idiomas de golpe, porque cada uno añade mantenimiento continuo de traducciones, capturas y soporte. Prioriza sopesando dos fuerzas entre sí: el tamaño del mercado y la competencia. El tamaño es cuántos usuarios potenciales y cuántos ingresos desbloquea un idioma, donde el inglés, el español, el portugués de Brasil, el japonés, el alemán, el francés y el chino simplificado cubren una gran parte del gasto mundial en apps. La competencia es lo difícil que es posicionarse en la tienda de ese idioma, y un mercado más pequeño con competidores localizados débiles puede convertir mejor que uno enorme ya saturado. Mira dónde ya recibes descargas orgánicas con una ficha en inglés, porque esos países te dicen que la demanda existe antes de gastar un céntimo en traducción.

• Empieza por los idiomas que ya aparecen en tus analíticas de instalación, porque la demanda está probada.
• Añade mercados de alto gasto donde tu categoría no esté ya dominada por actores localizados.
• Prefiere idiomas que desbloquean varios países a la vez, como el español o el árabe, por su apalancamiento.
• Despriorriza un idioma si no puedes dar soporte a sus usuarios, porque las instalaciones que no atiendes se van rápido.

Una ficha localizada ayuda dos veces, una en el algoritmo y otra con la persona. En el posicionamiento, ambas tiendas indexan tus campos de palabras clave localizados, así que un juego de palabras clave en español te hace visible en búsquedas en español para las que nunca posicionarías con una ficha en inglés. Traducir a máquina tus palabras clave en inglés se pierde todo esto, porque las palabras que la gente teclea en español rara vez son la traducción literal de las inglesas. En la conversión, un visitante que lee tu título, tu descripción y tus capturas en su idioma confía más en la app e instala a una tasa mayor que quien entrecierra los ojos ante una ficha extranjera. Por eso un ASO real por idioma supera a una simple traducción automática: investigas los términos de búsqueda reales de cada idioma y luego escribes los metadatos alrededor. El efecto se acumula, porque una mayor tasa de instalación también realimenta el posicionamiento. Para la mecánica del ASO por tienda, mira nuestra guía sobre cómo mejorar el ASO en App Store Connect, y para convertir ese tráfico en instalaciones, mejorar la conversión de la ficha.

La traducción automática es un buen borrador pero una mala ficha final. Maneja aceptablemente las frases descriptivas, pero falla en las dos cosas que más importan para la tienda: las palabras clave y el tono. Los términos de búsqueda rara vez coinciden con la traducción literal, y el texto automático suele sonar algo raro a un hablante nativo, lo que erosiona la confianza. Úsala para una primera pasada y luego haz que un hablante nativo ajuste las palabras clave y pula la redacción antes de publicar.

Sí, y con fuerza. Cada localización que añades le da a la tienda un nuevo campo de palabras clave que indexar, así que te vuelves localizable en búsquedas en ese idioma para las que tu ficha por defecto nunca posicionaría. En la App Store, las localizaciones incluso permiten apuntar a juegos de palabras clave adicionales que pueden ayudar en mercados cercanos. Añadir un idioma es una de las palancas de ASO más potentes disponibles, siempre que investigues las palabras clave en vez de traducirlas literalmente.

La mayoría de las apps nuevas deberían lanzarse con uno a tres idiomas, no diez. Empieza por tu mercado principal y cualquier idioma que ya aparezca en tus primeros datos de instalación, y luego amplía a medida que confirmas la demanda y puedes dar soporte a los usuarios. Localizar demasiados idiomas en el lanzamiento reparte tus capturas, tus metadatos y tu soporte con demasiada holgura, y las localizaciones a medio mantener se ven peor que una ficha limpia en un solo idioma. Alarga la lista con criterio, un mercado cada vez.

Localiza ambas cosas, porque las capturas pesan más en la decisión de instalar que la descripción. Un visitante ojea primero las imágenes, así que unos rótulos en su idioma y un texto en pantalla localizado hacen que la app se sienta pensada para él. Dejar capturas en inglés bajo una descripción traducida es la localización a medio hacer más común, y baja la conversión de forma visible. Si solo puedes localizar bien un elemento, que sean las capturas, y luego traduce los metadatos alrededor.