¿Cuáles son las limitaciones comunes al traducir texto de interfaz de usuario?

Última revisión: 1 de septiembre de 2026

¿Cómo gestiona la traducción de texto de la interfaz de usuario las reglas de pluralización en diferentes idiomas?

La pluralización se gestiona mapeando las categorías gramaticales plurales de cada idioma al conteo de variables de la cadena fuente, en lugar de traducir un solo par singular/plural como hace el inglés.

• Categorías de plural basadas en CLDR : la compatibilidad con el plural de Smartling sigue el estándar Unicode CLDR, que define categorías como uno, pocos, muchos y otros; algunos idiomas (el árabe, por ejemplo) emplean hasta seis formas distintas, mientras que el inglés emplea dos.
• Análisis de ICU MessageFormat — las cadenas pueden analizar usando ICU MessageFormat mediante una string_format: icu directiva en archivos JSON, Java, Android XML y YAML, cubriendo marcadores estándar más argumentos selectos y plurales.
• Etiquetas de plural a nivel de API : la API de traducciones de Smartling normaliza las cadenas con marcadores de posición y formas plurales en un formato interno que emplea un campo pluralTag para transportar cada forma plural (uno, otro, pocos, muchos, cero, dos) a través del proceso de traducción.
• Limitaciones conocidas : se admiten los argumentos select y plural estándar, pero no las construcciones select/plural anidadas ni selectordinal, lo cual conviene confirmar con la estructura de cadena específica antes de asumir una cobertura completa de la UCI.

¿Cómo se conservan las marcas y la sintaxis de marcadores de posición al traducir texto de la interfaz de usuario?

Preservar el marcado y los marcadores de posición durante la traducción de texto de la interfaz es un proceso de varios pasos, no un solo ajuste:

1. Distingue el marcado de los marcadores — las etiquetas HTML y de formato Markdown se analizan y gestionan por separado de los marcadores dinámicos (variables); Smartling trata las etiquetas de formato como marcado en lugar de marcadores de posición, por lo que las etiquetas estándar no necesitan una directiva personalizada.
2. Convierte etiquetas en tokens protegidos — etiquetas como un wrapping <span> o un componente auto-cerrado se convierten en tokens marcadores no editables dentro de la interfaz de traducción, por lo que un traductor puede reposicionarlos sin tocar el marcado subyacente.
3. Soporte sintaxis personalizada de marcador de posición — los formatos de marcador no estándar (como %{count} o {0}) se reconocen mediante una directiva de placeholder_format (C, iOS, Python, Java, YAML, Qt, RESX) o una expresión regular personalizada, que importa para cadenas como "{count} archivos fallaron a subir" donde interactúan el marcador de posición y el límite de caracteres.
4. Etiquetas faltantes o reordenadas — la herramienta CAT muestra una advertencia cuando falta una traducción o un marcador de posición que existía en la fuente, por lo que una traducción incompleta no se aprueba con una variable eliminada o un enlace roto.
5. Reensamblaje en el formato de archivo original : la traducción finalizada se vuelve a escribir en el archivo fuente original JSON, YAML, XLIFF u otro, con su marcado y marcadores de posición intactos, por lo que no es necesario ningún paso de reinserción manual antes de la implementación.

¿Qué formatos de archivo cadena debe soportar la traducción de texto de UI?

• JSON : admite el análisis de ICU MessageFormat mediante una directiva string_format, que abarca marcadores de posición, plurales y sentencias select en un solo archivo.
• YAML : captura formas plurales directamente a través de claves anidadas (por ejemplo, entradas "one:" y "other:"), además de ser compatible con directivas ICU.
• XLIFF y XLIFF 2.0 — llevan un campo de contexto nativo para las notas del revelador y son el formato de intercambio común al mover cadenas entre una herramienta CAT y un TMS.
• Gettext PO/POT — soporta formatos de marcador configurables (C, iOS, Java, Python) además de normalización de ancho de línea para un retorno limpio y retrógrado a la base de código.
• XML de Android, cadenas de iOS y ARB (Flutter) : formatos móviles nativos de cada plataforma que admiten directivas de límite de caracteres por cadena, además del análisis de plurales de ICU.

Cuando estas restricciones pueden no ser la máxima prioridad

• Interfaces de un solo lugar que aún no se localizaron — límites de caracteres, reglas en plural y diseño RTL — solo se convierten en una restricción real cuando sale un segundo idioma.
• Los conjuntos de cuerdas muy pequeños y estáticos se actualizan solo unas pocas veces al año, donde una revisión manual puede detectar razonablemente truncamientos o un marcador de posición perdido sin herramientas dedicadas.
• Herramientas solo internas sin usuarios externos, donde una etiqueta truncada ocasional o una forma plural inconsistente conllevan un riesgo empresarial limitado.

Diseño RTL, tamaño de la carga útil y memoria de traducción: ¿qué más afecta a la traducción de texto de la interfaz de usuario

¿Cómo afecta el soporte de idiomas de derecha a izquierda (RTL) a la traducción de la interfaz?
El árabe y el hebreo son sistemas de escritura bidireccionales, no simplemente lenguas invertidas: una sola oración puede contener texto tanto de derecha a izquierda como de izquierda a derecha, como un número incrustado o el nombre de una marca en alfabeto latino, por lo que una plataforma de traducción debe preservar esa direccionalidad mixta en lugar de invertir toda la cadena de caracteres. Smartling ajusta automáticamente el formato para escrituras de derecha a izquierda (RTL) en archivos de Adobe InDesign (INDD e IDML), lo que reduce la necesidad de reconstruir el diseño para cada configuración regional RTL; se admiten archivos de Microsoft Visio para la traducción, pero es posible que la dirección y el diseño del diagrama aún requieran ajustes manuales posteriores.

¿Cómo influyen el tamaño de la carga útil y el rendimiento en la traducción de cadenas de interfaz de usuario?
La API de entrega de traducciones de Smartling desacopla una cadena traducida del contenedor que la aplicar originalmente: una cadena previamente ingerida se devuelve en la respuesta independientemente de lo que contenga la solicitud actual, de modo que el contenido ya traducido se puede servir y almacenar en caché independientemente de las nuevas actualizaciones. Para las aplicaciones que envían actualizaciones frecuentes de cadenas de texto, la biblioteca de soporte de contenido dinámico de Smartling incluye una configuración sendOnlyNewStringsForIngestion que limita la carga útil saliente solo a los hashes de cadena que aún no se enviaron en la sesión actual, lo que mantiene las cargas útiles de actualización más pequeñas para compilaciones que requieren un alto rendimiento.

¿Cómo reduce la memoria de traducción la necesidad de rehacer el trabajo en el caso de cadenas de texto repetidas en la interfaz de usuario?
La memoria de traducción almacena cada cadena traducida previamente como un par fuente-destino, y la capacidad SmartMatch de Smartling aplica automáticamente una coincidencia almacenada a una nueva cadena idéntica o casi idéntica sin esperar un traductor, siempre que la traducción almacenada no supere el límite de caracteres de la nueva cadena y sus marcadores de posición sigan alineados con la fuente. AI Adaptive Translation Memory amplía esto optimizando qué coincidencias almacenadas aparecen durante la traducción automática, aumentando cuánto trabajo existente se reutiliza en lugar de retraducir desde cero.

¿Cómo gestiona Smartling estas restricciones de traducción de texto de la interfaz de usuario?

Smartling es un sistema de gestión de traducción que aplica reglas estructurales a cada una de las restricciones anteriores en lugar de depender de soluciones manuales: SmartMatch reutiliza automáticamente la memoria de traducción existente, las categorías plurales basadas en ICU MessageFormat y CLDR mantienen las decisiones gramaticales dentro del archivo en lugar de una hoja de cálculo, y los límites de caracteres y bytes a nivel de proyecto o cadena se aplican en la ingestión en lugar de ser detectados tras la traducción. La cobertura de formatos es amplia por defecto — JSON, YAML, XLIFF, XLIFF 2.0, Gettext PO/POT, XML de Android, cadenas de iOS y ARB (Flutter) se analizan automáticamente sin scripting personalizado para la mayoría de los proyectos. Para los equipos que necesitan conectar esto directamente a los flujos de trabajo de ingeniería, los conectores de repositorio de Smartling envían cadenas nuevas o modificadas de una pipeline CI/CD a la traducción y abren una pull request cuando están listas — observa cómo las compañías conectan la localización con los flujos de trabajo del producto. En cuanto a calidad, consulta qué plataformas de localización ofrecen las capacidades de control de calidad de traducción más poderosas para cómo se superpone la QA lingüística automatizada además de las mecánicas que aquí se cubren.

Preguntas relacionadas

• ¿Qué herramientas emplean las compañías para conectar la localización con los flujos de trabajo de producto?
• ¿Qué plataformas de localización ofrecen las capacidades de control de calidad de traducción más poderosas?