Localización de Software y Aplicaciones

JSON simple no tiene comentarios ni soporte para plurales: funciona para inglés, pero es frágil en producción cuando los traductores añaden apóstrofos tipográficos (' frente a '), espacios finos insecables alrededor de la puntuación francesa o comillas alemanas (», «). Un traductor francés que escribe correctamente L'application con un apóstrofo tipográfico pasará el control de calidad lingüístico pero romperá un analizador JSON frágil. Normalizamos los apóstrofos en la importación, validamos la presencia de BOM UTF-8 y ejecutamos una pasada de sintaxis antes de que se publique cada locale.

Android almacena los apóstrofos como \' y los símbolos de unión como &. Los traductores suelen pegar caracteres curvos de Microsoft Word que parecen idénticos y se publican, hasta que el diseño renderiza mojibake en tiempo de ejecución. Utilizamos un proceso de ida y vuelta XLIFF personalizado para recursos de Android para que el traductor nunca vea XML sin procesar, y volvemos a escapar en la exportación.

El problema clásico son las reglas de plural. iOS usa categorías de plural CLDR (zero, one, two, few, many, other) a través de .stringsdict. Un traductor inexperto tratará el archivo como uno a uno y perderá variantes de plural: su aplicación en alemán dirá entonces "1 Nachrichten". Usamos un editor consciente de plurales que muestra cada categoría CLDR según sea necesario para el locale de destino y rechaza la exportación si falta alguna categoría.

.resx acepta comentarios XML y referencias de código incrustadas; .properties usa ISO-8859-1 por defecto (las cadenas de herramientas modernas sí admiten UTF-8, pero la combinación incorrecta aún publica escapes \uXXXX que desconciertan a los traductores). Forzamos UTF-8 en la importación y emitimos escapes nativos solo en tiempo de compilación.

Siempre que es posible, extraemos los archivos de origen a XLIFF 1.2 o 2.0, traducimos dentro de nuestro editor con contexto adjunto y volvemos a fusionar. Esto permite que los traductores vean el comentario de origen, la captura de pantalla y la restricción (límite de caracteres, forma plural ICU, indicador de reflejo RTL) sin tocar nunca el archivo de origen. El pipeline de compilación se fusiona de vuelta al formato que confirmaron sus desarrolladores.

{count, plural,
 one {# friend}
 few {# friends}
 many {# friends}
 other {# friends}
}

Esto funciona bien en inglés, francés y alemán. En árabe se necesitan zero, one, two, few, many, other. En polaco few cubre 2-4 solo cuando el último dígito es 2-4 y el número no es 12-14: el polaco tiene aproximadamente 5 categorías de plural. El galés tiene las suyas propias. Traducimos según el conjunto de reglas de plural CLDR para cada locale, no según la plantilla inglesa.

Español, italiano y pashto necesitan saber si el sujeto es masculino, femenino o neutro para conjugar el verbo. Una traducción ingenua de "You are invited" se establece por defecto en masculino; una usuaria ve gramática incorrecta en el 50 % de los locales. El select de ICU gestiona esto:

{gender, select,
 female {Estás invitada}
 male {Estás invitado}
 other {Te han invitado}
}

Si su modelo de datos no registra el género, el camino seguro es la rama neutra other. Señalamos las cadenas con género en la revisión de origen para que su equipo pueda decidir si capturar el género, establecer por defecto neutro o publicar variantes, antes de que se comprometa el presupuesto de traducción.

Las reseñas de App Store y Google Play señalan rutinariamente plurales incorrectos: "La app tiene errores, dice '1 mensajes'". Las reseñas de una estrella se acumulan y degradan el posicionamiento. Corregir plurales después del lanzamiento cuesta más que una traducción consciente de ICU desde el principio.

El error de producción más común: los desarrolladores escriben margin-left: 16px en lugar de margin-inline-start: 16px. En un locale de izquierda a derecha son idénticos. En árabe, el primero fija el margen a la izquierda de la pantalla; el segundo se invierte correctamente a la derecha. Auditamos su hoja de estilos en busca de propiedades físicas (left, right, padding-left, border-right) antes de tocar las cadenas.

Un párrafo en árabe que menciona un nombre de marca inglés, una URL o un numeral se convierte en una cadena de dirección mixta. Los navegadores gestionan esto con el algoritmo bidireccional Unicode, pero el algoritmo es heurístico y se equivoca en casos predecibles, más a menudo cuando una oración termina con un número latino o puntuación. Insertamos marcas U+202A/U+202C (LRE/PDF) o usamos etiquetas <bdi> alrededor de tokens opacos como nombres de usuario e identificadores de producto.

Iconos de flecha, el símbolo de "atrás", deshacer y rehacer, direcciones de deslizadores, barras de progreso: cada icono direccional necesita una variante RTL o una transformación CSS. Lucide y Heroicons tienen variantes conscientes de RTL; el conjunto de iconos de Material requiere una clase de espejo. Catalogamos cada icono direccional en su sistema de diseño y señalamos cualquiera que no esté reflejado en la auditoría.

Las pilas de fuentes occidentales carecen rutinariamente de glifos árabes: Helvetica Neue, Inter y Roboto necesitan un respaldo árabe. El predeterminado del sistema (Geeza Pro en iOS, Noto Naskh Arabic en Android) renderiza, pero la altura de línea es incorrecta y el kerning es pobre. Probamos la renderización en los dispositivos reales que tienen sus usuarios (no solo Chrome en macOS) y señalamos correcciones de pila de fuentes como parte de la revisión con pseudo-locale.

El árabe es nuestro par lingüístico individual más grande. Nuestra marca hermana arabictranslation.co.uk ha publicado localización árabe desde 2012. Los recargos RTL que añaden la mayoría de las agencias del Reino Unido (20-30 %) reflejan que este es trabajo inusual para ellas; es el trabajo que hacemos más. No cobramos recargo por RTL.

Adecuado para la mayoría de equipos SaaS. Un webhook de GitHub se activa en cada push a main. Nuestro servicio inspecciona el diff en busca de cadenas nuevas o modificadas, redacta los locales, los envía a un lingüista para revisión y abre un PR de retorno. La protección de rama garantiza que el PR no pueda fusionarse antes de la revisión. Tiempo típico de extremo a extremo: 18-24 horas para 35 idiomas en un commit de 200 cadenas.

Si su equipo prefiere que los cambios de locale fluyan a través de su sistema de compilación (CircleCI, GitHub Actions, GitLab Runners), exponemos una CLI: lingosecure pull extrae las últimas traducciones a su repositorio como paso de compilación, lingosecure push carga cualquier cambio de cadena de origen para traducción. Lo usan equipos que ejecutan trenes de lanzamiento y no quieren PR de traducción en su flujo.

Si ya tiene un TMS, estaremos encantados de actuar como capa de lingüistas dentro de él: sus desarrolladores continúan enviando cadenas al TMS, nuestros lingüistas traducen dentro del TMS y la sincronización del TMS se ejecuta como siempre. Cero cambios de flujo de trabajo para sus ingenieros. El beneficio: un único proveedor en lugar de unir una suscripción TMS, una lista de autónomos y un proveedor para el material regulado.

Los tres patrones comparten un principio: su memoria de traducción es suya. Cada segmento traducido se registra en su TM, que alojamos dentro de LingoSecure o exportamos a su TMS bajo demanda. Si cambia de proveedor el año que viene, la TM va con usted. No hay dependencia del proveedor.

Fijamos por versión la memoria de traducción al lanzamiento del producto. Su v4.2 nunca se publicará accidentalmente con las cadenas traducidas de v4.1. Si su equipo necesita revertir un lanzamiento, la TM se revierte con él. Esto importa para productos regulados donde una divulgación traducida debe coincidir con la versión de inglés contra la que fue aprobada.

• Truncamiento: botones que encajan "OK" pero no "Aceptar"
• Cadenas codificadas de forma fija: cualquier cosa que no esté envuelta en t
• Errores de concatenación: "Hello " + username fallará en idiomas con diferente orden de palabras
• Suposiciones de ancho fijo: selectores de fecha, desplegables, pestañas de navegación
• Respaldos de fuente: texto que se convierte en rectángulos porque la fuente no cubre Latin Extended-A
• Errores de inversión RTL: cada icono direccional y maquetación se invierte en pseudo-RTL

Entregamos la compilación de pseudo-locale como un despliegue de Storybook o una rama de funcionalidad que su equipo de QA puede probar. El registro de defectos va directamente a su Linear, Jira o GitHub Issues. Nosotros corregimos los problemas del lado del locale; su equipo corrige los del lado del producto, antes de pagar por una sola palabra de traducción humana.

Para productos maduros ejecutamos una pasada adicional: cada pantalla se captura en inglés, pseudo-EN, alemán, árabe y chino, y se comparan las diferencias. Las regresiones de maquetación aparecen inmediatamente. El mismo flujo de trabajo se ejecuta contra cada PR si lo desea como GitHub Action.

Cada cadena pasa por un lingüista cualificado antes de salir del portal. Usamos lingüistas especializados para acelerar el primer borrador, pero ninguna cadena se publica sin aprobación humana. Si desea MT sin procesar por razones de coste, AWS Translate y nuestro pipeline API son excelentes: le ayudaremos a configurarlos, pero no pondremos nuestro nombre en el resultado.

Una corrección de emergencia de 50 cadenas en 4 horas es realista en la mayoría de los locales principales. Un lanzamiento de producto de 5000 cadenas en 24 horas no es realista y no nos comprometeremos con ello. Programamos hacia atrás desde su fecha de lanzamiento con búfer de QA incorporado; si su cronograma es más corto, le diremos qué es realmente alcanzable.

La mayoría de agencias del Reino Unido enrutan el árabe a un estudio en El Cairo o Beirut. Traducimos internamente con lingüistas designados. La misma persona que tradujo sus cadenas v1 es la persona que traduce v4.7. La coherencia terminológica es función de la continuidad; la continuidad requiere no subcontratar.