Cómo localizar una aplicación móvil

TABLE OF CONTENTS

Si estás buscando cómo localizar una aplicación móvil, probablemente no necesitas “consejos de traducción”. Lo que necesitas es un flujo de trabajo seguro para producción que cubra cadenas de texto, diseño, reglas de plurales, soporte de derecha a izquierda, capturas de pantalla y metadatos de la tienda sin romper el producto.

Esa es la distinción clave: la localización de aplicaciones móviles no es solo traducir texto. Es adaptar la app, la página del producto y el proceso de QA para cada mercado objetivo. Apple indica que la App Store está disponible en 175 regiones y 40 idiomas, mientras que Android 13 introdujo preferencias de idioma por aplicación a nivel de sistema. En otras palabras, ambas plataformas principales ahora asumen que la elección del idioma es una experiencia central del producto, no algo secundario.

Esta guía recorre los pasos prácticos para equipos de iOS y Android.

De un vistazo:

Separa la localización dentro de la app de la localización en App Store y Google Play.
Externaliza las cadenas de texto antes de traducir nada.
Gestiona plurales, variables, fechas, monedas y RTL desde el principio.
Prueba con pseudoidiomas antes de enviar traducciones reales.
Localiza capturas de pantalla y recursos de la tienda, no solo las descripciones.

Qué incluye realmente la localización de aplicaciones móviles

El trabajo de localización suele dividirse en dos líneas.

1. Localización dentro de la app

Este es el producto en sí:

Cadenas de UI
Mensajes de error y textos de onboarding
Fechas, horas, números, monedas y unidades
Cadenas sensibles a plurales y género
Expansión de diseño y comportamiento de derecha a izquierda
Imágenes o iconos que contienen texto o significado direccional

Apple recomienda explícitamente usar Xcode, las APIs de Foundation, Auto Layout, soporte Unicode, catálogos de recursos localizados y símbolos adaptados a la dirección para preparar las apps para mercados globales. Android recomienda de forma similar recursos adaptados al idioma, soporte de idioma por aplicación y diseños compatibles con RTL en lugar de texto y posicionamiento codificados de forma fija.

2. Localización de la ficha de la tienda

Así es como los usuarios descubren tu app:

Nombre de la app
Subtítulo o descripción corta
Descripción completa
Palabras clave
Capturas de pantalla
Vídeos de vista previa o promocionales

Trata esto como un entregable separado. Una app bien localizada puede tener un rendimiento inferior si la página del producto es genérica, no está traducida o visualmente no encaja con el mercado objetivo.

Empieza con la internacionalización, no con la traducción

La traducción es el último paso en un proceso que comienza con la estructura.

Externaliza las cadenas y mantén un idioma de respaldo completo

En Android, Google advierte que tu archivo res/values/strings.xml predeterminado debe definir cada cadena que tu app necesite. Si el archivo predeterminado está incompleto y el dispositivo se ejecuta en un idioma no soportado, la app puede fallar al cargar y mostrar un error con un botón de Cierre forzado. Por eso la localización empieza con la higiene de recursos, no con la selección de idiomas.

Para iOS, Apple recomienda separar el texto e imágenes visibles para el usuario del código ejecutable para que puedan localizarse como archivos de recursos. En los flujos de trabajo modernos de Apple, los catálogos de cadenas son el enfoque recomendado en Xcode 15 y posteriores para cadenas que contienen plurales.

Regla práctica:

Nunca codifiques texto de UI directamente en vistas o controladores
Mantén un único idioma fuente canónico
Asegúrate de que cada cadena visible para el usuario tenga una clave estable, contexto y un valor de respaldo
Incluye comentarios para los traductores en cadenas ambiguas

Un pequeño ejemplo lo hace más fácil de visualizar.

Android normalmente empieza con un archivo strings.xml predeterminado:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Luego tu UI lee el recurso en lugar de codificar el inglés directamente:

Text(text = stringResource(R.string.checkout_cta))

En plataformas Apple, Xcode 15+ suele gestionar la misma idea en un catálogo de cadenas. Un extracto simplificado de Localizable.xcstrings puede verse así:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

No necesitas memorizar el formato del archivo. La lección operativa es más simple: cada cadena visible para el usuario necesita una única fuente de verdad, suficiente contexto para los traductores y un respaldo seguro cuando un idioma está incompleto.

Si tu app también envía archivos de idioma estructurados, nuestra guía sobre Best JSON Translators in 2026 puede ayudarte a pensar en automatización y preservación de formato.

Si quieres una opción de herramienta directa para archivos de recursos de aplicaciones, vale la pena echar un vistazo a OpenL JSON Translator. Está diseñado para traducir archivos .json sin romper claves ni estructura, que es exactamente lo que necesitas cuando las cadenas de la app se almacenan en archivos de localización legibles por máquina. El flujo de trabajo es simple: sube el JSON exportado desde tu app, CMS o pipeline de localización, elige el idioma de destino y descarga un archivo JSON traducido con la misma estructura. Según la página del producto, soporta más de 100 idiomas y archivos de hasta 50 MB, lo que lo convierte en una herramienta práctica de primera pasada para equipos de localización de apps que manejan contenido estructurado.

Soporta la selección de idioma a nivel de app

Los usuarios esperan cada vez más poder elegir el idioma de la app de forma separada al idioma de su dispositivo.

En plataformas Apple, los usuarios pueden seleccionar su idioma preferido para una app de forma independiente al idioma del dispositivo. En Android, Android 13 añadió una configuración centralizada de idioma por aplicación, y Google recomienda habilitar el soporte automático de idioma por app o conectar tu selector a las APIs oficiales.

Esto importa para productos reales. Los usuarios bilingües y multilingües pueden mantener su teléfono en inglés pero preferir una app de compras, banca o delivery en otro idioma. Si tu app fuerza un único modelo de idioma, estás creando fricción antes de que la calidad de la traducción siquiera se cuestione.

Usa la pila de localización de la plataforma

Resiste la tentación de inventar un sistema de localización paralelo a menos que realmente lo necesites.

Para la mayoría de los equipos, la pila predeterminada de la plataforma es suficiente:

iOS: catálogos de cadenas, Localizable.strings, .stringsdict, formateadores de Foundation, Auto Layout
Android: res/values/, carpetas de recursos específicas por idioma, LocaleConfig, setApplicationLocales(), supportsRtl

La infraestructura de localización personalizada tiene sentido a muy gran escala, pero añade sobrecarga operativa. Empieza con el sistema nativo y extiéndelo solo donde sientas un problema real.

Localiza las partes que la mayoría de los equipos pasan por alto

Los equipos a menudo traducen las frases visibles y pasan por alto la mecánica del producto que las rodea.

Plurales, variables y gramática

Las reglas de plurales no son universales. Las reglas de plural de Unicode CLDR definen categorías como zero, one, two, few, many y other, y diferentes idiomas usan subconjuntos distintos. Apple señala que en los flujos de trabajo antiguos con .stringsdict, other es la única categoría obligatoria, pero omitir categorías específicas del idioma puede producir resultados gramaticalmente incorrectos. Tanto Android como iOS dependen del manejo de plurales adaptado al idioma por una razón.

Aquí es donde la traducción automática ingenua falla:

1 file vs 2 files es fácil en inglés
Los idiomas eslavos a menudo necesitan más de dos formas de plural
Algunos idiomas cambian sustantivos, verbos o palabras circundantes juntos

Nunca construyas UI pluralizada concatenando fragmentos como "You have " + count + " messages". Usa recursos de plurales de la plataforma en su lugar.

Aquí está la forma mínima de hacerlo en cada plataforma.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>

Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

Ejemplo legacy de .stringsdict para iOS:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

En Xcode 15 y posteriores, Apple recomienda manejar los plurales en catálogos de cadenas, pero el principio sigue siendo el mismo: dale a la plataforma un patrón de mensaje y deja que elija la forma correcta del idioma.

Para más protecciones en el flujo de trabajo con marcadores de posición y cadenas estructuradas, consulta How to Translate Technical Docs Without Breaking Code.

Fechas, números, monedas y unidades

Apple recomienda explícitamente usar las APIs de Foundation para formatear fechas, longitudes, pesos, precios y símbolos de moneda en diferentes idiomas. El mismo principio se aplica en Android: formatea los datos con APIs adaptadas al idioma en lugar de codificar puntuación, marcas decimales u orden de unidades de forma fija.

Los fallos típicos incluyen:

03/04/2026 significando cosas diferentes en distintas regiones
Signos de dólar codificados de forma fija para mercados que no usan USD
1,234.56 mostrado incorrectamente en idiomas que usan comas como separadores decimales
Unidades de medida mostradas en el sistema incorrecto

Si tu app contiene programación de citas, facturación, ventanas de entrega o analíticas, esto es parte de la localización, no un detalle de pulido.

Expansión de diseño y soporte de derecha a izquierda

El inglés suele ser compacto. El alemán se alarga. El árabe y el hebreo invierten la dirección de lectura. Un diseño que se ve bien en inglés puede romperse seriamente en otros idiomas.

Apple recomienda probar con pseudoidiomas, incluyendo un pseudoidioma de derecha a izquierda y un pseudoidioma de longitud doble, antes de importar traducciones reales. Android recomienda usar start y end en lugar de left y right, habilitar android:supportsRtl="true" y probar diseños RTL en el dispositivo con Force RTL.

Tu lista de verificación aquí es simple:

Permite que los botones y etiquetas crezcan
Evita contenedores de texto de ancho fijo para UI importante
Refleja la UI direccional donde sea apropiado
Verifica iconos, flechas, flujos de progreso y carruseles en RTL
Prueba texto de dirección mixta como UI en árabe con nombres de productos o códigos de cupón en latín

Imágenes, iconos, capturas de pantalla y vídeo

La guía de localización de Apple hace un punto importante que muchos equipos pasan por alto: las imágenes también pueden localizarse. Esto incluye conjuntos de imágenes, conjuntos de símbolos y direccionalidad para símbolos personalizados. Si tu captura de pantalla contiene UI en inglés, texto en inglés en banners o flechas de izquierda a derecha, entonces la captura de pantalla en sí no está localizada.

Eso es especialmente importante para pantallas de onboarding, tarjetas de tutorial y recursos de la App Store. Los usuarios no separan mentalmente “elementos visuales de marketing” del “idioma del producto”. Juzgan toda la experiencia de una vez.

Localiza tus páginas de App Store y Google Play por separado

Aquí es donde muchos equipos pierden instalaciones incluso después de hacer bien el trabajo dentro de la app.

Requisitos de la App Store a planificar

Apple recomienda localizar los metadatos en App Store Connect, incluyendo la descripción de la app, palabras clave, vistas previas y capturas de pantalla. Apple también indica que puedes mostrar hasta 10 capturas de pantalla en tu página de producto, y hasta 3 vistas previas por tamaño de dispositivo e idioma soportado. Las vistas previas pueden durar hasta 30 segundos, y las capturas de pantalla importan aún más cuando no hay vista previa porque las primeras una a tres capturas de pantalla pueden aparecer en los resultados de búsqueda.

Esto tiene dos implicaciones:

Tus primeras capturas de pantalla son recursos de descubrimiento, no solo documentación.
Deberías localizar capturas de pantalla y vistas previas para los mercados prioritarios en lugar de reutilizar recursos en inglés en todas partes.

Requisitos de Google Play a planificar

Google Play trata la localización de la ficha como su propio flujo de trabajo también. Play Console te permite añadir texto localizado, capturas de pantalla en el idioma local y recursos gráficos localizados. Si añades traducciones de texto sin recursos gráficos localizados, Google indica que los elementos visuales del idioma predeterminado seguirán mostrándose.

Google también señala que si no añades tus propias traducciones de la ficha de la tienda, los usuarios pueden ver una traducción automática con un aviso de que fue generada automáticamente. Eso es útil como respaldo, pero no es una estrategia fuerte de entrada al mercado.

Una función actual especialmente relevante: Play Console indica que puede traducir continuamente las cadenas de la app usando modelos Gemini sin costo. Más específicamente, Google dice que esto aplica a las cadenas de strings.xml en app bundles subidos a versiones en borrador, y que puedes previsualizar las traducciones generadas en un emulador integrado antes de publicar. Es una forma potente de acelerar la cobertura de primera pasada, pero aún debería ir seguida de revisión humana para flujos críticos.

Construye un flujo de trabajo de lanzamiento y QA

Un buen proceso de localización se trata menos de traducir más rápido y más de lanzar con menos sorpresas.

Paso 1. Elige los idiomas objetivo deliberadamente

No empieces con “traducir todo a 20 idiomas”.

Empieza con:

Tu mix actual de descargas
Países que soportas activamente
Cobertura de facturación, legal y soporte al cliente
Si puedes localizar tanto la app como la ficha de la tienda juntas

Lanzar un mercado de principio a fin suele superar lanzar cinco mercados a medias.

Paso 2. Crea recursos listos para localización

Antes de que empiece la traducción, congela y prepara:

Cadenas fuente con contexto
Lista de capturas de pantalla por idioma
Glosario y reglas de nombres de producto
Reglas de marcadores de posición
Guía de límites de caracteres para textos de la tienda
Responsables de revisión por idioma

Si la app usa repositorios separados o múltiples formatos de archivo, estandariza los nombres y la extracción desde el principio.

Paso 3. Prueba primero con pseudolocalización

En plataformas Apple, usa pseudoidiomas de longitud doble y de derecha a izquierda. En Android, prueba idiomas no soportados, Force RTL y configuraciones de idioma de la app. Esto detecta:

Botones truncados
Encabezados recortados
Texto oculto
Alineación incorrecta
Cadenas no localizadas
Suposiciones fijas de izquierda/derecha

Esta es una de las pasadas de QA más baratas que puedes ejecutar.

Paso 4. Ejecuta QA lingüístico en dispositivos reales

Después de que lleguen las traducciones:

Prueba los flujos críticos en cada idioma objetivo
Compara el comportamiento del idioma del sistema y el idioma de la app
Verifica el comportamiento de plurales y marcadores de posición
Revisa pagos, fechas y direcciones
Revisa capturas de pantalla y fichas de la tienda en el mercado

Si un bug afecta el onboarding, checkout, verificación de identidad o notificaciones, trátalo como un bloqueante de lanzamiento.

Lista de verificación para un primer sprint de localización

Si este es tu primer lanzamiento serio, mantén el sprint lo suficientemente pequeño para terminarlo limpiamente:

Esa lista de verificación es intencionalmente reducida. Un idioma con una experiencia de app limpia y recursos de tienda sincronizados te enseña mucho más que un lanzamiento apresurado en muchos mercados.

Ejemplos del mundo real

Las ideas centrales anteriores no son teóricas.

DoorDash construyó la traducción como un problema de plataforma

En 2022, DoorDash dijo que ya había traducido más de un millón de cadenas en cuatro idiomas y redujo la incorporación de nuevos idiomas de horas de esfuerzo de desarrollo a un solo comando en un minuto. La lección interesante no es solo la escala. Es la estructura: DoorDash separó cadenas estáticas y dinámicas, añadió soporte de glosario y guía de estilo, y construyó protecciones para evitar que cadenas sin traducir se colaran.

En una publicación del blog de DoorDash del 2 de febrero de 2026, la empresa dijo que su plataforma de onboarding reconstruida ahora gestiona registros en todos los mercados de DoorDash y soporta lanzamientos internacionales rápidos con localización integrada. Eso es exactamente lo que parece una localización madura: flujos de trabajo reutilizables, flexibilidad regional y menos parches improvisados.

Meta trató la localización como un problema tanto de idioma como de tamaño de la app

Meta indica que alrededor del 57% de los usuarios de Facebook para Android y el 49% de los usuarios de Facebook para iOS usan la app en un idioma distinto al inglés. En el mismo artículo, Meta dice que eliminar los archivos de traducción incluidos ahorró hasta 16.6 MB en la app de iOS y permitió a Android añadir casi una docena más de idiomas sin aumentar el tamaño de la app.

La conclusión es útil incluso para equipos más pequeños: la localización tiene consecuencias de ingeniería. Afecta el tamaño del binario, la carga en tiempo de ejecución, la entrega de traducciones y la mecánica de lanzamiento, no solo la redacción de textos.

Lista de verificación final antes de lanzar

Usa esto como una última pasada:

Todas las cadenas visibles para el usuario están externalizadas.
Los recursos de respaldo predeterminados están completos.
Los plurales y marcadores de posición usan soporte de localización nativo de la plataforma.
Las fechas, horas, números, monedas y unidades son adaptadas al idioma.
Los diseños RTL y el texto de dirección mixta han sido probados.
El texto de la ficha de la tienda está localizado para los mercados objetivo.
Las capturas de pantalla y vistas previas están localizadas para los idiomas prioritarios.
La selección de idioma dentro de la app funciona como se espera en iOS y Android.
El QA lingüístico ha cubierto los recorridos de usuario más importantes.

Reflexiones finales

La forma más simple de pensar en la localización de aplicaciones móviles es esta: traduce el producto, localiza la experiencia y prueba el lanzamiento.

Si estás haciendo esto por primera vez, no apuntes a una cobertura global perfecta desde el primer día. Elige uno o dos idiomas estratégicos, localiza la app y la página de la tienda juntas, ejecuta una pasada de QA seria y aprende del uso real. Si ya estás gestionando archivos de recursos y contenido orientado a desarrolladores, combina este flujo de trabajo con How to Translate Technical Docs Without Breaking Code y Best JSON Translators in 2026.

Si solo tomas una acción esta semana, haz esto: elige 1 idioma, ejecuta 1 pasada de pseudolocalización y localiza 1 ficha correspondiente de App Store o Google Play. Esa prueba de tres partes te dirá más sobre tu preparación que traducir veinte idiomas en paralelo.

Si necesitas una primera pasada rápida para textos de la app, capturas de pantalla o archivos de idioma estructurados, usa automatización para acelerar el borrador y luego mantén un paso de QA humano antes del lanzamiento. Esa es la parte que protege la confianza del usuario y previene un lanzamiento “traducido pero no verdaderamente localizado”.

Referencias

Apple Developer. Localization. https://developer.apple.com/localization/
Apple Developer. Creating Your Product Page. https://developer.apple.com/app-store/product-page/
Apple Developer. Upload app previews and screenshots. https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
Apple Developer. Localizing strings that contain plurals. https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals
Apple Developer. Testing Your Internationalized App. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/TestingYourInternationalApp/TestingYourInternationalApp.html
Apple Developer. Get it right (to left). https://developer.apple.com/videos/play/wwdc2022/10107/
Android Developers. Localize your app. https://developer.android.com/guide/topics/resources/localization
Android Developers. Per-app language preferences. https://developer.android.com/guide/topics/resources/app-languages
Android Developers. Support different languages and cultures. https://developer.android.com/training/basics/supporting-devices/languages
Google Play Console Help. Translate and localize your app. https://support.google.com/googleplay/android-developer/answer/9844778?hl=en
Google Play Console Help. Create and set up your app. https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
Unicode CLDR. Plural Rules. https://cldr.unicode.org/index/cldr-spec/plural-rules
DoorDash Engineering. Building a Platform to Translate DoorDash into Multiple Languages. https://careersatdoordash.com/blog/building-a-platform-to-translate-doordash-into-multiple-languages/
DoorDash Engineering. Unified Dasher Onboarding: A modular platform to scale globally. https://careersatdoordash.com/blog/doordash-unified-dasher-onboarding-a-modular-platform-to-scale-globally/
Engineering at Meta. Language packs: Meta’s mobile localization solution. https://engineering.fb.com/2022/05/09/android/language-packs/