Reducir la complejidad de la internalización

[acuevas-dgtic]

Dentro de la carpeta i18 del commons veo multitud de clases que añaden demasiada complejidad a la internalización. Con tener los ficheros messages_ca.properties, messages_es.properties,... y algo tipo "messagesProp = ResourceBundle.getBundle(MESSAGES_FILE, FacesContext.getCurrentInstance().getViewRoot().getLocale());" es suficiente

[anadal-fundaciobit]

He eliminat 5 classes innecessàries. La resta de classe, per exemple pensant per PortaFIB 3.0 i en un projecte normal són necessàries. Sobre el tema de la complexitat, el projecte EJB té la classe I18NTranslatorEjb i el back té la classe I18NTranslatorBack que simplifiquen el procés de traduccions i de formateig de missatges: I18NTranslatorEjb.translate(loca, "codi_traducc"); I18NTranslatorBack.translate("codi_traducc");

[acuevas-dgtic]

Sigo pensando que hay demasiadas clases para este aspecto. No es urgente, pero se debería intentar simplicar

[antonireus]

S'han reduït el nombre de classes a 3, que són bàsicament:

• MultipleResourceBundle, una classe d'utilitat que és per permetre tenir un únic ResourcBundle que delega amb varis sub ResourceBundle. D'aquesta manera, si un mòdul necessita traduïr etiquetes que poden estar a dos fitxers de properties diferents ho pot fer amb un únic ResourceBundle.
• I18NTranslator. És una classe que permet passar un nom d'etiqueta i una sèrie de paràmetres, així com l'idioma, i retorna l'etiqueta traduïda i formatejada amb els paràmetres. Els paràmetres poden ser també etiquetes traduïdes si estan entre {}. Es pot instanciar amb un o varis noms de ResourceBundle (si són varis crearà un MultipleResourceBundle).
• I18NException. És una excepció que es crea a partir d'una etiqueta i un conjunt de paràmetres, per obtenir un missatge traduït. Per davall empra un I18NTranslator.

Dins el javadoc he intentat posar documentació abundant. També, i en relació a la issue #51 dins aquestes classes estan fetes emprant streams i expressions lambda.