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

Revisado por última vez: 31 de agosto de 2022

¿Qué herramientas permiten la localización y las pruebas de aplicaciones móviles en iOS y Android?

• Capa de archivo de recurso y formato: Smartling analiza directamente los formatos nativos móviles, incluyendo recursos de cadenas XML de Android y archivos Stringsdict de iOS, además de ICU MessageFormat para pluralización en archivos JSON, Java, XML de Android y YAML, por lo que las cadenas traducidas vuelven a la misma estructura de archivos que ya espera una compilación.
• Capa de contexto visual: dado que las aplicaciones nativas no tienen HTML que escanear, la función de contexto visual de Smartling utiliza el OCR para hacer coincidir las capturas de pantalla cargadas o un vídeo grabado en pantalla con la cadena específica en la que está trabajando el traductor, sustituyendo las conjeturas por una vista de la pantalla real.
• Repositorio y capa de CI: el conector GitHub de Smartling (también disponible para GitLab y Beanstalk) rastrea una rama específica para ver los cambios en los archivos de recursos, reenvía cadenas nuevas o modificadas automáticamente y retrasa las traducciones finalizadas, manteniendo la localización dentro del mismo flujo de solicitud de extracción que ya ejecuta un equipo móvil.
• Capa de pruebas de control de calidad y dispositivo: errores de seudolocalización integrados de Android Studio (inglés XA/XB) y de seudolocalización de Xcode, expansión de cadenas de la superficie y diseño de derecha a izquierda antes de que un traductor abra el archivo; Firebase Test Lab y TestFlight de Apple validan la versión localizada en dispositivos reales antes de que llegue a la reseña 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 incluye el proceso de localización de aplicaciones para teléfonos inteligentes?

1. Extrae e internacionaliza cadenas — extrae texto orientado al usuario del código y lo lleve a archivos de recurso (XML de Android para Android, Localizable.strings o Stringsdict para iOS) para que nada esté codificado y cada cadena tenga una clave única.
2. Conecte los archivos de recursos a una plataforma de traducción: inserte esos archivos mediante una API o un conector como el GitHub Connector de Smartling, que rastrea una rama del repositorio y reenvía automáticamente las cadenas cambiadas.
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?

• Los equipos envían a tres o más idiomas con un ritmo de lanzamiento recurrente, donde la traducción ad hoc deja de ampliarse después de los dos primeros idiomas.
• Equipos cuyo contenido de aplicaciones se encuentra en parte en archivos de recursos y en parte en contenido dinámico entregado por el servidor, ya que ambos necesitan un proceso de traducción coherente.
• Los equipos ya están publicando versiones móviles a través de una canalización de CI/CD, donde un conector de repositorio coloca la localización en un flujo de trabajo de solicitud de extracción existente en lugar de en una transferencia manual.
• Equipos que necesitan un historial de calidad documentado, como los sectores regulados en los que una puntuación de LQM basada en MQM funciona como prueba de la 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 un programa completo de localización no es 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 coste hundido hasta que el producto principal sea estable.
• Una traducción única a un solo idioma adicional sin una cadencia de actualización planificada, donde un pase de traducción único más ligero puede resultar más rentable que un proceso basado en conectores.
• Una aplicación con solo unos cientos de cadenas para el usuario, en la que la transferencia manual de archivos puede seguir siendo gestionable sin herramientas automatizadas.

¿Qué debe comprobar antes de enviar una versión localizada de aplicaciones móviles?

¿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 ha revisado cada cuerda con contexto visual, no de forma aislada?
Una cadena traducida sin ver su pantalla es una fuente común de errores sin importar el contexto; hacer coincidir capturas de pantalla o grabaciones de pantalla con cadenas mediante OCR proporciona a los lingüistas la interfaz de usuario real con la que trabajar.

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

¿Las notificaciones y el texto de gestión de cuentas, incluida la cancelación de la suscripción y la copia del centro de preferencias, están localizados con el mismo estándar que la aplicación principal?
Las notificaciones push, los correos transaccionales y los flujos de baja de baja suelen mantenerse fuera de los archivos principales de recursos de la app y se pierden en una auditoría de localización, lo que crea tanto una brecha de confianza del usuario como de cumplimiento.

¿Se ha probado la versión en dispositivos reales antes de su presentación?
Ejecute la compilación localizada a través de Firebase Test Lab o TestFlight con la combinación real de dispositivos del mercado objetivo, ya que las pruebas solo con simuladores omite problemas de renderización de fuentes y versión del sistema operativo en el mundo real.

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

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

Smartling soporta localización móvil nativa directamente dentro de los formatos de archivo que ya utiliza una versión de iOS o Android — recursos de cadenas XML de Android, archivos Stringsdict de iOS y ICU MessageFormat para pluralización — por lo que el contenido traducido vuelve a integrarse en una compilación sin un paso de conversión separado. Como las aplicaciones nativas no disponen de HTML para que una herramienta basada en navegador pueda escanear, la función de Contexto Visual de Smartling utiliza OCR para emparejar capturas de pantalla subidas o vídeos grabados en pantalla con la cadena exacta en la que trabaja un traductor, eliminando la incertidumbre de traducir texto de la interfaz sin vista de la pantalla donde está enseguida.

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.