Multilingual Support

Contexto

En muchas aplicaciones Java hace falta evitar literales embebidos: cambiar idioma o revisar copy no debería obligar a recompilar cadenas repartidas por la lógica. A la vez, no siempre compensa montar un stack de localización grande para un problema pequeño. Este tipo de utilidad encaja cuando necesitas cambiar de idioma sin complicar demasiado la estructura del proyecto: ficheros por locale, carga explícita y un consumo simple desde código.

Problema

Con el texto mezclado con la interfaz o con la lógica, cada ajuste de idioma es un barrido manual y propenso a errores. El mantenimiento empeora: cambios ruidosos en el código, riesgo de mezclar idiomas y revisiones que no distinguen bien cambio funcional de cambio de texto. Si el idioma vive junto a las reglas de negocio, cuesta añadir locales o un flujo de traducción mínimo: sin un criterio claro, cada pantalla inventa su forma de pedir texto.

Qué resolvía el sistema o proyecto

Un enfoque acotado: archivos de texto por idioma (clave y traducción), búsqueda por clave desde el código y carga al vuelo cuando el usuario elige el idioma (en el ejemplo de GitHub, con un cuadro de diálogo sencillo). El componente que entrega textos tiene una interfaz mínima; si falta una clave, el comportamiento queda definido y visible en el código público, no como fallo silencioso. El objetivo es el caso “mensajes fuera del código + varios idiomas + interfaz pequeña”, sin prometer más.

Mi rol

Autor del proyecto en GitHub: carga de traducciones, lectura de archivos por idioma, componente de mensajes y resolución por clave. Pruebas automatizadas (JUnit 5) fijan el comportamiento con claves presentes y ausentes. Compilación y empaquetado con Maven. Código abierto bajo licencia MIT.

Stack

Java 17, Maven para el proyecto, JUnit 5 para las pruebas y archivos de texto por idioma como fuente de las cadenas traducidas.

Decisiones importantes

Flujo al elegir idioma

Tras seleccionar idioma, un cargador lee los archivos de traducción correspondientes y deja el mapa en memoria. Sobre eso se construye el MessageProvider; la consulta es por clave (findMessage u equivalente en el código publicado).

String language = new LanguageSelectionJOptionPane().selectLanguage();
TranslationLoader loader = new TranslationLoader(language);
loader.loadTranslations();

MessageProvider provider = new MessageProvider(loader.getTranslations());
String text = provider.findMessage("APP_BACK");
System.out.println(text);

Ejemplo adaptado del README en GitHub; nombres alineados con el código.

• Solución ligera: pocas clases y un flujo lineal; nada de capas innecesarias.
• Legibilidad: quien integra la utilidad entiende en poco tiempo qué carga y qué resuelve.
• Facilidad de uso: cargar traducciones, instanciar el proveedor y pedir mensaje por clave.
• Reglas simples: claves estables; pruebas que documentan el comportamiento esperado, incluida la ausencia de clave.

Restricciones o NDA

Proyecto público (MIT). No es un framework de i18n de producto grande: no cubre por sí mismo pluralización rica, reglas gramaticales complejas, catálogos externos ni todo lo que exige un programa de localización serio. Encaja cuando el problema es simple y acotado: varios idiomas, mensajes en ficheros y una API mínima. Si el producto exige más, otro stack; aquí el valor está en la honestidad del alcance.

Resultado o aprendizaje

Para el caso “properties + clave + runtime”, el resultado es código fácil de leer, copia centralizada y tests que evitan regresiones silenciosas. Aprendizaje que aplico en otros sitios: acotar la API pública y documentar límites evita que un utilitario crezca sin control ni expectativas claras para quien lo reutiliza.