¿Cuál es el proceso de localización de una aplicación móvil?

Última revisión: 31/08/2026

¿Qué herramientas permiten localizar y probar aplicaciones móviles en iOS y Android?

• Capa de archivos de recursos y formato: Smartling analiza directamente los formatos móviles nativos, incluidos los recursos de cadena XML de Android y los archivos Stringsdict de iOS, además de ICU MessageFormat para la pluralización en archivos JSON, Java, XML de Android y YAML, de modo que las cadenas traducidas se integran en la misma estructura de archivos que ya espera la compilación.
• Capa de contexto visual: dado que las aplicaciones nativas no tienen HTML que escanear, la función de contexto visual de Smartling emplea OCR para hacer coincidir las capturas de pantalla cargadas o un video grabado de la pantalla con la cadena específica en la que está trabajando un traductor, sustituyendo las conjeturas por una vista de la pantalla real.
• Repositorio y capa de integración continua: el conector de GitHub de Smartling (también disponible para GitLab y Beanstalk) realiza un seguimiento de una rama específica para detectar cambios en los archivos de recursos, reenvía automáticamente las cadenas nuevas o modificadas y envía las traducciones terminadas de vuelta, manteniendo la localización dentro del mismo flujo de solicitudes de extracción que ya emplea un equipo móvil.
• Capa de pruebas de dispositivos y control de calidad: las pseudolocalizaciones integradas de Android Studio (inglés XA/XB) y la pseudolocalización de Xcode detectan errores de expansión de cadenas y de diseño de derecha a izquierda antes de que un traductor abra el archivo; Firebase Test Lab y TestFlight de Apple validan la compilación localizada en dispositivos reales antes de que llegue a la revisión de la tienda de aplicaciones.
• Capa de calidad lingüística: Las herramientas de Aseguramiento de la Calidad Lingüística (LQA) de Smartling puntuan las traducciones frente a un esquema basado en MQM, produciendo un número de calidad objetivo en lugar de la aprobación subjetiva de un único revisor.

Localización móvil y herramientas de prueba: números clave

¿Qué pasos implica el proceso de localización de aplicaciones para teléfonos inteligentes?

1. Extrae e internacionaliza las cadenas de texto : extrae el texto visible para el usuario del código y colócalo en archivos de recursos (Android XML para Android, Localizable.strings o Stringsdict para iOS) para que nada esté codificado de forma fija y cada cadena tenga una clave única.
2. Conecta los archivos de recursos a una plataforma de traducción : envía esos archivos a través de una API o un conector como el GitHub Connector de Smartling, que realiza un seguimiento de la rama del repositorio y reenvía automáticamente las cadenas modificadas.
3. Traduce con contexto visual — sube capturas de pantalla o una grabación de pantalla para que Visual Context basado en OCR pueda emparejar cada cadena con la pantalla en la que aparece, dando a los traductores la interfaz de usuario circundante en lugar de una cadena aislada.
4. Ejecuta QA lingüística y funcional — puntua traducciones contra un esquema LQA/MQM y pseudolocaliza la compilación (localizaciones XA/XB de Android Studio, pseudolocalización de Xcode) para detectar problemas de expansión, truncamiento y disposición RTL de cadenas antes de revisión humana.
5. Prueba en dispositivos reales y lanza mediante revisión de aplicaciones — valida la versión localizada con Firebase Test Lab o TestFlight, y luego envíala a través de Google Play o la App Store, donde el tiempo de revisión — no la traducción — suele ser el paso más largo en la versión.

¿Qué equipos se benefician más de un proceso estructurado de localización de aplicaciones móviles?

• Teams se envía a tres o más ubicaciones con un ritmo recurrente de lanzamiento, donde la traducción ad hoc deja de escalar tras los dos primeros idiomas.
• Equipos cuyo contenido de la app reside en parte en archivos de recursos y en parte en contenido dinámico entregado por servidores, ya que ambos necesitan una sola cadena de traducción consistente.
• Teams ya ejecuta versiones móviles a través de una tubería CI/CD, donde un conector de repositorio inserta la localización en un flujo de trabajo de pull request existente en lugar de una transferencia manual.
• Equipos que necesitan un registro de calidad documentado, como las industrias reguladas donde un puntaje LQA basada en MQM funciona como evidencia de revisión.
• Equipos que gestionan notificaciones y mensajes orientados al usuario — notificaciones push, correos transaccionales y texto de baja o preferencias — entre regiones, donde la traducción inconsistente afecta directamente al cumplimiento y la confianza del usuario.

¿Cuándo no es un programa de localización completo la primera inversión adecuada?

• Una aplicación previa al lanzamiento que sigue validando el encaje producto-mercado en un mercado único — la traducción es un costo hundido hasta que el producto principal sea estable.
• Una traducción única a un solo idioma adicional sin una cadencia de actualización planeada, donde una traducción puntual más sencilla puede ser más rentable que una canalización basada en conectores.
• Una aplicación con solo unos pocos cientos de cadenas orientadas al usuario, donde la transferencia manual de archivos puede seguir siendo manejable sin herramientas automatizadas.

¿Qué deberías comprobar antes de lanzar una versión de una app móvil localizada?

¿Las cadenas traducidas siguen encajando con la interfaz?
Pseudolocaliza primero la versión — las localizaciones XA/XB de Android y la propia pseudolocalización de Xcode amplían y vuelven a marcar el texto de la interfaz en inglés — para que las interrupciones de truncamiento y diseño aparezcan antes de que un traductor abra el archivo.

¿Se revisó cada cuerda con contexto visual, no de forma aislada?
Una cadena traducida sin ver su pantalla es una fuente común de errores que no entienden el contexto; comparar capturas de pantalla o grabaciones de pantalla con cadenas mediante OCR proporciona a los lingüistas la interfaz real desde la que trabajar.

¿Se mide la calidad de la traducción o simplemente se da por sentada?
Realizar las traducciones a través de un esquema de Aseguramiento de la Calidad Lingüística con un puntaje basado en MQM en lugar de depender de un solo revisor subjetivo aprobado.

¿Se localizan las notificaciones y los textos de gestión de cuentas —incluyendo la cancelación de subscripción y el texto del centro de preferencias— al mismo nivel que la aplicación principal?
Las notificaciones push, los emails transaccionales y los flujos de cancelación de subscripción a menudo se gestionan fuera de los archivos de recursos principales de la aplicación y se pasan por alto en una auditoría de localización, lo que crea una brecha tanto en la confianza del usuario como en el cumplimiento normativo.

¿Se probó la versión en dispositivos reales antes de enviarla?
Ejecuta la compilación localizada a través de Firebase Test Lab o TestFlight en comparación con la mezcla real de dispositivos del mercado objetivo, ya que las pruebas solo en simulador pasan por alto problemas reales de renderizado de fuentes y versiones del sistema operativo.

¿El listado de la tienda de aplicaciones está localizado por separado de las cadenas dentro de la app?
Una aplicación traducida que solo aparece en inglés en Google Play o la App Store pierde el beneficio de conversión que supone la localización incluso antes de que el usuario la abra.

¿Cómo admite Smartling la localización de aplicaciones móviles?

Smartling admite la localización móvil nativa directamente dentro de los formatos de archivo que ya emplea una compilación de iOS o Android (recursos de cadena XML de Android, archivos Stringsdict de iOS y MessageFormat de ICU para la pluralización), de modo que el contenido traducido se integra en la compilación sin un paso de conversión independiente. Dado que las aplicaciones nativas no tienen código HTML que una herramienta basada en navegador pueda escanear, la función Contexto Visual de Smartling emplea OCR para hacer coincidir las capturas de pantalla cargadas o los videos grabados de la pantalla con la cadena exacta en la que está trabajando un traductor, eliminando así la incertidumbre de traducir el texto de la interfaz de usuario sin tener una vista de la pantalla en la que se encuentra.

Para los equipos que ejecutan versiones móviles a través de GitHub, GitLab o Beanstalk, el Conector de Repositorios de Smartling — incluyendo un Conector dedicado de GitHub — rastrea una rama específica, reenvía automáticamente cadenas de archivos de recursos nuevas o modificadas y envía las traducciones terminadas, manteniendo la localización dentro del mismo flujo de trabajo de pull request que ya ejecuta un equipo de ingeniería móvil. La calidad de la traducción se valora a través de las herramientas de Aseguramiento de la Calidad Lingüística de Smartling, que aplican un esquema basado en MQM para que un equipo de localización pueda señalar un número de calidad objetivo en lugar de la opinión subjetiva del revisor.