Una cadena con el género codificado en el texto inglés se rompe en cuanto llega al español. "You have 1 new message" se convierte en plural gramatical en casi todas las lenguas latinas, y un archivo de recursos mal preparado obliga al traductor a adivinar si "1" es singular o si el sistema va a mostrar realmente "1 mensajes" al usuario final. Esto no es un detalle de estilo. Es un bug de localización que llega a producción.
Este artículo cubre lo que separa un archivo de recursos listo para localizar de uno que va a generar idas y vueltas, cadenas truncadas y plurales incorrectos en producción.
Separar texto de lógica desde el principio
Un error común en equipos que localizan por primera vez es concatenar cadenas en el código. `"El usuario " + nombre + " tiene " + numero + " mensajes"` funciona en inglés y falla en cualquier idioma con un orden de palabras diferente o con concordancia de género y número. El alemán mueve el verbo al final de la frase en oraciones subordinadas. El árabe se lee de derecha a izquierda. Ninguno de estos idiomas respeta el orden fijo que el código en inglés asume.
La práctica correcta es usar cadenas completas con marcadores de posición nombrados, no posicionales: `"El usuario {userName} tiene {messageCount} mensajes"`. Esto permite al traductor reordenar los elementos según la gramática del idioma de destino, sin tocar la lógica del código. Frameworks como ICU MessageFormat, Fluent (Mozilla) o los archivos .resx de .NET ya soportan este patrón de forma nativa.
Otro punto que genera retrabajo es separar frases en fragmentos que solo tienen sentido una vez recompuestos. "Haga clic" + "aquí" + "para continuar" como tres cadenas distintas impide al traductor entender el contexto y a menudo da lugar a una frase gramaticalmente incorrecta al reconstruirla. Cada cadena debe ser una unidad de sentido completa.
Plurales: la regla del inglés no sirve para nadie más
El inglés tiene dos plurales: singular y plural. El español también, aunque con concordancia de género que el inglés no tiene. El polaco tiene cuatro formas plurales distintas según el número termine en 1, en 2-4, o en otra cifra. El árabe tiene seis categorías gramaticales de plural. Un archivo de recursos preparado solo con `one` y `other` se rompe en cuanto el proyecto necesita soportar ruso o árabe.
El estándar CLDR (Common Locale Data Repository), mantenido por el Unicode Consortium, define las categorías de plural (`zero`, `one`, `two`, `few`, `many`, `other`) que cada idioma usa realmente. La mayoría de los frameworks modernos de internacionalización (i18next, Fluent, gettext con plural forms, ICU MessageFormat) ya implementan estas categorías. La preparación correcta del archivo fuente pasa por:
- No concatenar nunca números con cadenas fijas ("1 artículo", "2 artículos" como cadenas separadas)
- Usar la sintaxis de plural del framework elegido, no condicionales manuales en el código
- Incluir siempre la categoría `other` como alternativa, incluso para idiomas que no la usan para todos los números
- Probar con valores que expongan las categorías menos obvias: 0, 1, 2, 5, 11, 21, 100
Un archivo preparado con estas categorías desde el origen ahorra al traductor el trabajo de pedir aclaraciones sobre cada cadena numérica, y evita que el equipo de ingeniería tenga que reabrir el código después de la localización.
Variables, contexto y longitud del texto
Los marcadores de posición sin contexto son la segunda causa más común de errores de localización, después de los plurales mal preparados. `{0}` o `{1}` no dicen nada al traductor sobre lo que va a ir ahí. ¿Es un nombre de usuario, una fecha, un importe monetario? Nombrar los marcadores de forma descriptiva (`{userName}`, `{orderDate}`, `{totalAmount}`) resuelve la mayor parte de la ambigüedad sin coste adicional de ingeniería.
Los comentarios de contexto en el propio archivo de recursos marcan la diferencia entre una traducción correcta a la primera y otra que vuelve a revisión. Un comentario simple como `// Botón principal de la pantalla de checkout, máximo 20 caracteres` da al traductor dos informaciones críticas: dónde aparece la cadena y qué límite de espacio tiene que respetar.
Esto importa especialmente en interfaces móviles, donde el espacio es limitado y el alemán o el finlandés pueden necesitar un 30% más de caracteres que el inglés para decir lo mismo. Los equipos que localizan aplicaciones para mercados como Angola o Mozambique se enfrentan además a la variable del soporte offline y la calidad de red, que puede exigir estrategias distintas de carga de recursos lingüísticos. El artículo sobre localización de aplicaciones móviles para Angola y Mozambique detalla estas condiciones específicas.
Formato de archivo y flujo de trabajo
El formato técnico elegido para exportar las cadenas influye directamente en la calidad y la velocidad de la localización. Los más comunes:
| Formato | Uso típico | Observación |
|---|---|---|
| JSON | Apps web, React, Vue | Fácil de automatizar, sin soporte nativo para comentarios |
| .resx | Aplicaciones .NET | Soporta comentarios y metadatos por cadena |
| .po / .pot | Proyectos gettext, WordPress | Estándar maduro, buena integración con herramientas CAT |
| XLIFF | Intercambio entre sistemas de traducción | Formato de intercambio recomendado para equipos con proveedor externo |
| ARB | Flutter | Soporta plurales ICU de forma nativa |
Para proyectos con proveedor de traducción externo, el XLIFF sigue siendo la opción más segura: conserva el contexto, los comentarios y los marcadores de posición sin exigir que el traductor edite código fuente directamente. Esto reduce el riesgo de que alguien borre por error una clave o altere un marcador que el motor de la aplicación espera encontrar intacto.
Los equipos que trabajan con plataformas SaaS y ciclos de lanzamiento continuos se benefician de automatizar esta exportación, de forma que cada cadena nueva creada por los desarrolladores entre en el flujo de localización sin intervención manual. El artículo sobre localización ISO 17100 para plataformas SaaS explica cómo estructurar ese flujo con control de calidad auditable.
Cómo trata M21Global los archivos de software
M21Global trabaja con los formatos de archivo más comunes en proyectos de localización de software, incluyendo JSON, .resx, .po y XLIFF, preservando marcadores de posición, categorías de plural CLDR y comentarios de contexto durante todo el proceso. Para interfaces y documentación técnica asociada a productos de software, la solución se adapta al volumen y a la criticidad del contenido: desde catálogos de ayuda con traducción asistida por IA hasta cadenas de interfaz que requieren revisión humana completa.
Para equipos que preparan el primer ciclo de localización o que están migrando de un flujo manual a un proceso estructurado, M21Global ayuda a definir el formato de exportación y las convenciones de nomenclatura antes del primer envío de archivos. Consulte los servicios de traducción y localización de software y solicite una evaluación técnica de su proyecto.
Servicios Relacionados
Solicite un presupuesto gratuito de localización de software
- Solicite un presupuesto gratuito de localización de software
- Localizacion Aplicacion Movil Angola Mozambique
- Localizacion De Saas Conforme A Iso 17100
- Una Cantidad Asombrosa De Contenido Disponible En Linea Es Generada Por La Inteligencia Artificial
Preguntas Frecuentes
¿Qué es el CLDR y por qué importa en la localización de software?
El CLDR (Common Locale Data Repository) es el estándar del Unicode Consortium que define las categorías de plural, formatos de fecha y número para cada idioma. Preparar el archivo de recursos con las categorías CLDR correctas evita plurales gramaticalmente incorrectos en idiomas como el polaco, el ruso o el árabe.
¿Cuál es el mejor formato de archivo para enviar cadenas a un proveedor de traducción?
El XLIFF suele ser la opción más segura para el intercambio con proveedores externos, porque conserva contexto, comentarios y marcadores de posición sin exigir edición directa de código fuente.
¿Por qué concatenar cadenas en el código es un problema de localización?
Concatenar texto fijo con variables asume un orden de palabras que no existe en todos los idiomas. Usar cadenas completas con marcadores de posición nombrados permite al traductor reordenar los elementos según la gramática del idioma de destino.
¿Cuántas formas de plural necesito soportar en un proyecto multilingüe?
Depende de los idiomas de destino: el inglés tiene dos, el español tiene dos con concordancia de género, el polaco tiene cuatro y el árabe tiene seis. El archivo de recursos debe seguir las categorías CLDR del idioma en cuestión, no asumir el patrón del inglés.
