¿Cuáles son las restricciones más comunes a la hora de traducir el texto de la interfaz de usuario?

Última revisión: 1 de septiembre de 2026

¿Cómo gestiona la traducción de textos de la interfaz de usuario las normas de pluralización en todos los 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 plurales basadas en CLDR: el soporte plural de Smartling sigue el estándar CLDR Unicode, que define categorías como uno, pocos, muchos y otros; algunos idiomas (el árabe, por ejemplo) utilizan hasta seis formas distintas, mientras que el inglés usa dos.
• Análisis de ICU MessageFormat — las cadenas pueden analizarse 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 plurales a nivel API — La API Translations de Smartling normaliza cadenas con marcadores de posición y plurales en un formato interno que utiliza un campo pluralTag para transportar cada forma plural (uno, otro, pocos, muchos, cero, dos) a través de la cadena de traducción.
• Límites conocidos — se admiten argumentos estándar de selección y plural, pero las construcciones anidadas select/plural y selectordinal no, lo cual merece la pena confirmarlo contra tu estructura específica de cadenas antes de asumir una cobertura completa de 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 subirse" 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. Vuelva a montarlo en el formato de archivo original: la traducción acabada se vuelve a escribir en el archivo JSON, YAML, XLIFF u otro archivo fuente original con las marcas y los marcadores de posición intactos, por lo que no es necesario ningún paso de reinserción manual antes del despliegue.

¿Qué formatos de archivo de cadenas debe admitir la traducción de textos de la interfaz de usuario?

• JSON: admite el análisis de MessageFormat de la UCI mediante una directiva string_format, que incluye los marcadores de posición, los plurales y las sentencias de selección en un solo archivo.
• YAML — captura formas plurales directamente a través de claves anidadas (por ejemplo, entradas "uno:" y "otro:") además del soporte de directivas de la 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.
• Android XML, iOS Strings y ARB (Flutter): formatos móviles nativos de la plataforma, cada uno de los cuales admite directivas de límite de caracteres por cadena junto con el análisis plural de la UCI.

Cuando estas restricciones pueden no ser la máxima prioridad

• Interfaces de un solo lugar que aún no se han localizado — 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 carga útil y memoria de traducción: qué más afecta a la traducción de textos de la interfaz de usuario

¿Cómo afecta el soporte lingüístico de derecha a izquierda (RTL) a la traducción de la interfaz de usuario?
El árabe y el hebreo son alfabetos bidireccionales, no simplemente idiomas invertidos. Una sola frase puede contener texto de derecha a izquierda y de izquierda a derecha, como un número incrustado o una marca en alfabeto latino, por lo que una plataforma de traducción tiene que preservar esa direccionalidad mixta en lugar de invertir toda la cadena. Smartling ajusta automáticamente el formato de las secuencias de comandos RTL de los archivos de Adobe InDesign (INDD e IDML), lo que reduce la reconstrucción del diseño necesaria para cada configuración regional RTL; los archivos de Microsoft Visio son compatibles con la traducción, pero la dirección y el diseño de los diagramas pueden seguir necesitando ajustes manuales después.

¿Cómo influyen el tamaño de la carga útil y el rendimiento en la traducción de las cadenas de interfaz de usuario?
La API de Entrega de Traducción de Smartling desacopla una cadena traducida del contenedor que originalmente la solicitó — una cadena previamente ingerida se devuelve en la respuesta independientemente de lo que haya en la solicitud actual — de modo que el contenido ya traducido puede servirse y almacenarse en caché de forma independiente de nuevas actualizaciones. Para las aplicaciones que lanzan actualizaciones frecuentes de cadenas, 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 cadenas que aún no se han enviado en la sesión actual, manteniendo las cargas útiles de actualización más pequeñas para compilaciones sensibles al rendimiento.

¿Cómo reduce la memoria de traducción la repetición de cadenas de 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 guardada 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 retraducirse desde cero.

¿Cómo gestiona Smartling estas limitaciones de traducción de texto en la interfaz?

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 empresas 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 potentes para cómo se superpone la QA lingüística automatizada además de las mecánicas que aquí se cubren.

Preguntas relacionadas

• ¿Qué herramientas utilizan las empresas 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 potentes?