Cómo planteé el soporte multilenguaje para no acoplar texto y lógica
Introducción breve
Al publicar Multilingual Support busqué una pieza pequeña: mensajes fuera del código y resolución por clave en runtime, sin arrastrar un i18n de producto grande.
Problema o decisión
Literales mezclados en la lógica encarecen cambio de idioma y mantenimiento; cada cadena duplicada es un posible desajuste. Para utilidades acotadas no compensaba enganchar un framework pesado: hacía falta decidir un punto intermedio con límites explícitos.
Qué hice o cómo lo planteé
Ficheros properties (key-value) por idioma, carga al arranque o bajo demanda según el módulo, y una API mínima: clave → texto. Los tests fijan claves presentes y ausentes para que un refactor no rompa en silencio. Con ello desacoplo copia de ramas de lógica y mantengo diffs legibles en Git; dejo fuera, de forma consciente, pluralización rica, género gramatical complejo o formatos regionales avanzados.
Qué aprendí
Acotar la API pública de una utilidad pequeña reduce variantes que el siguiente desarrollador debe entender. Cuando el producto exige i18n enterprise, otro stack; aquí el valor está en el alcance declarado, no en cubrir todos los casos lingüísticos.
Proyecto relacionado
El código y el contrato concreto están en el caso Multilingual Support.