Textos, traducciones y encoding: el idioma también es código
Un texto escrito directo en la pantalla, una traducción que falta y aparece la clave cruda, un acento que se ve como dos símbolos raros. Tres problemas distintos que se comentan igual en una review y se arreglan en lugares distintos.
En un producto en varios idiomas, el texto no es contenido: es código con reglas propias. Y hay tres fallas que aparecen una y otra vez en las revisiones, parecidas en la superficie y con causas distintas: el texto escrito a mano, la traducción que falta y la codificación rota.
El texto escrito directo en la pantalla
Es el más frecuente y el más fácil de justificar: “es un cartel de error que nadie va a ver”. Se ve, y se ve en el idioma equivocado.
Dónde se cuelan más seguido
- Mensajes de error y estados vacíos, que se escriben rápido y no aparecen en el diseño.
- Textos de accesibilidad: etiquetas de botones sin texto visible, descripciones alternativas. Se olvidan porque no se ven en la pantalla.
- Formatos armados a mano, del tipo “quedan 3 días”: la frase cambia de estructura según el idioma, y concatenar partes traducidas produce oraciones incorrectas.
- Valores que parecen texto de usuario y no lo son: un estado interno, una clave de evento. Ésos no se traducen nunca, y confundirlos es el error opuesto.
La traducción que falta
El segundo problema aparece en el despliegue: la clave existe en el idioma principal y no en los otros. Qué se ve entonces depende de una decisión que casi nunca se toma a conciencia.
| Estrategia | Qué ve el usuario | Cuándo conviene |
|---|---|---|
| Mostrar la clave cruda | Algo como `checkout.error.timeout` | Nunca en producción; útil en desarrollo para detectarlas |
| Caer al idioma principal | El texto en otro idioma | Cuando la pantalla sin ese texto no se entiende |
| No mostrar el elemento | Una sección menos | Cuando es un agregado y el resto sigue siendo usable |
Lo que sí conviene siempre es que la falta se registre. Una traducción faltante que nadie ve en un tablero se va a descubrir por un reclamo, meses después.
Los acentos que se rompen
El tercer problema es más viejo y sigue vivo: el texto que se ve con símbolos raros donde iba una eñe o un acento. Casi siempre es la misma causa: alguien escribió el texto en una codificación y alguien lo leyó suponiendo otra.
Dónde se rompe la cadena
- El archivo fuente, si se guardó con una codificación distinta a la que espera el proyecto.
- La respuesta del servicio, si el encabezado declara una cosa y el contenido es otra.
- La base de datos, si la columna o la conexión usan una codificación que no cubre todos los caracteres. Ahí el dato se guarda mal y ya no hay forma de recuperarlo desde el cliente.
- Un archivo exportado, donde la herramienta que lo abre supone la codificación local.
Antes de seguir, predecí
La regla que evita casi todo esto es declarar la misma codificación en todos los puntos de la cadena —archivos, base, conexión, encabezados de respuesta— y no dejar ninguno al valor por defecto del sistema, que cambia de máquina a máquina.
Un detalle que rompe el diseño
Hay un efecto de la traducción que no es técnico y aparece igual en las reviews: el mismo texto ocupa distinto en cada idioma. Una palabra que entra justo en un botón puede necesitar bastante más espacio traducida.
Por eso los diseños que asumen un largo fijo se rompen en la mitad de los idiomas, y por eso conviene probar la interfaz con el idioma más largo del conjunto antes de darla por terminada.
Más a fondo · nivel seniorLos textos también son datos del producto
Cuando el producto crece, los textos dejan de ser un archivo del repositorio y pasan a ser algo que edita gente que no programa. Ahí valen dos cosas: que las claves tengan una estructura predecible —por pantalla y por función, no por orden de aparición— y que un cambio de texto no requiera desplegar. Si cada corrección de una coma necesita un despliegue, los textos se corrigen menos de lo que deberían.
Las tres fallas en un diff
Hay 4 problemas en este cambio. Tocá la línea donde creas que está.
| 3 | 3 | ||
| 4 | 4 | ||
| 5 | 5 | ||
| 6 | |||
| 7 | |||
| 8 | |||
| 9 | |||
| 10 | |||
BloqueaLa clave se arma concatenando, así que ninguna herramienta la puede encontrar Ningún analizador estático va a ver que existen order.status.pending y order.status.shipped: lo único que hay en el código es un prefijo. Cuando falte una traducción, no lo va a avisar nadie y en pantalla va a aparecer la clave cruda. Con un mapa explícito de estado a clave, la herramienta las ve y el compilador exige que estén todas. | |||
| 11 | |||
| 12 | |||
| 13 | |||
| 14 | |||
SugerenciaY el mismo problema, más escondido Poner el número de pedido después de la etiqueta supone que en todos los idiomas va en ese orden. Es la misma falla que la de arriba y casi nunca se detecta, porque el texto traducido existe y se ve bien: lo que está mal es el armado. | |||
| 15 | |||
BloqueaLa cantidad concatenada con el sustantivo no se puede traducir bien En castellano funciona por casualidad. En otros idiomas el orden cambia, y además hay idiomas con más de dos formas de plural: uno, dos, pocos, muchos. El número tiene que ir como variable adentro del mensaje, con la regla de plural que provea la biblioteca, no pegado con un espacio. | |||
| 16 | |||
| 17 | |||
| 18 | |||
| 6 | 19 | ||
Tres fallas parecidas en la superficie y con causas distintas: una no está traducida, otra no se puede verificar y otra no se puede traducir bien.
Lo que hace que no se acumulen
Cierre
Autoevaluación
¿Lo entendiste?
Práctica
BloqueaEl mensaje del estado vacío quedó escrito a mano
Es el lugar donde más se cuela, por el mismo motivo de siempre: se escribió rápido, no estaba en el diseño y «total nadie lo va a ver». Se ve, y se ve en castellano en medio de una pantalla en portugués. Los estados vacíos y los mensajes de error son la mitad de los textos sin traducir de cualquier producto.