Nuiton I18n

Le projet Nuiton I18n fournit des classes Java pour l'internationalisation (i18n) des applications.

Cette librairie très légère combine les très utilisés ResourceBundles Java, une API simple d'utilisation et très puissante ainsi qu'un procédé d'extension très utile. De nombreux autre avantages existent à utiliser Nuiton I18n :

- Extraction des clés de traduction

- Integration au process de build au travers de Maven ou Ant

Petit exemple qui démontre la simplicité d'utilisation de Nuiton I18n :

I18n.init(new DefaultI18nInitializer("myBundle"), Locale.FRANCE);
System.out.println(I18n._("This text will be translated"));

Les deux modules du projet Nuiton I18n :

- I18n Api

- I18n Maven Plugin

Quoi de neuf dans la version 3.0

Compatibilité 1.8

Pour être compatible avec java 1.8, des méthodes de la classe I18n ont été renommées (Guide de migration).

Suppression de mojos obsolètes

Les mojo jsp et tapestry ont été supprimés.

Quoi de neuf dans la version 2.5

Renommage du plugin en i18n-maven-plugin.

Le plugin a été renommé de maven-i18n-plugin en i18n-maven-plugin.

Pensez à mettre à jour vos pom.

Ajout d'un parseur pour les jsp de struts2

Ce nouveau parseur scan les fichier jsp et extrait toutes les clefs contenues dans des attributs text name='xxx' ou label='xxx' ou %{getText("xxx".

Malheureusement il n'est pas possible de faire mieux que ça et il se peut alors de récupérer trop de clefs. Pour limiter cet effet indésirable il est possible d'utiliser le nouveau paramètre acceptKeyformat qui permet de limiter les clefs remontées.

De toute manière il ne faut pas oublier qu'une bnne pratique est de toujours utiliser un prefixe commun à toutes les clefs de traduction (donc le pattern doit rester simple à écrire).

Ajout d'un paramètre acceptKeyFormat sur les goals de type parser

Cela permet de limiter les clefs entrantes (ce qui est nécessaire pour le parseur struts2...)

Permettre de générer un fichier csv avec toutes les traductions d'un bundle

Cela peut aider grandement à compléter les traduction à partir des traductions complètes d'une langue.

Pour utiliser cette fonctionnalité, il suffit d'ajouter à la ligne de commande -Di18n.generateCsvFile lors de l'execution du mojo bundle.

See Evolution #2291: Generate a csv file with all translations for all locales in a csv file in bundle mojo.

Quoi de neuf dans la version 2.4

Meilleure utilisation des encodings

Depuis la JDK 1.6, il est possible de charger et écrire des fichiers de propriétés en spécifiant son propre encoding, il n'y a donc plus de raison de rester sur un encoding ISO-8859-1 ou US/ASCII.

I18n a intégré ces changements, et il devient donc désormais raisonnable d'utiliser comme encoding par défaut UTF-8. Cet encoding par défaut peut toujours être modifié à différents niveaux :

- lors de la génération des fichiers i18n (via le plugin i18n) - lors de l'initialisation de I18n au runtime via l'initializer (I18nInitializer).

Gestion d'autre formats pour les traductions

Par défaut, I18n utilise un String.format et sa syntaxe pour les traductions.

Cependant, on peut vouloir utiliser le plugin i18n sans utiliser le runtime I18n et utiliser à la place un système de traduction basé notamment sur MessageFormat (comme le fait struts2 ou GWT par exemple).

La version 2.4 permet d'utiliser désormais de changer de syntaxe et ceci à différents niveaux :

- au niveau de la génération d'un bundle via le paramètre bundleFormatConverter du goal bundle - au niveau du runtime en spécifiant à l'initializer le bon messageFormatter à utiliser. (voir l'interface I18nMessageFormatter).

A noter qu'au runtime, les syntaxes de traductions ne peuvent pas être changées. Utiliser un formatter qui ne correspond pas à la syntaxe des traductions ne fonctionnera pas correctement.

Quoi de neuf dans la version 2.3

La version 2.3 améliore de façon considérable les temps de détection des clefs i18n pour les fichiers java (mojo parserJava).

Voir Evolution #1275: Improve parserJava performance.

On passe à des temps très raisonnable (en dessous de 5 millisecondes par fichier!) comme montré ci-dessous :

mvn package -Pnotests -Di18n.strictMode -DnuitonI18nVersion=2.2

[INFO] --- maven-i18n-plugin:2.2:parserJava (default) @ observe-business ---
[INFO] Parsing is done. [treated file(s) : 76/187](total time:19.852s) ( ~ 106.158ms / file)
[INFO] --- maven-i18n-plugin:2.2:parserJava (scan-sources) @ observe-swing ---
[INFO] Parsing is done. [treated file(s) : 151/206](total time:38.732s) ( ~ 188.021ms / file)

mvn package -Pnotests -Di18n.strictMode -DnuitonI18nVersion=2.3-SNAPSHOT

[INFO] --- maven-i18n-plugin:2.3-SNAPSHOT:parserJava (default) @ observe-business ---
[INFO] Parsing is done. [treated file(s) : 76/187](total time:640.602ms) ( ~ 3.426ms / file)
[INFO] --- maven-i18n-plugin:2.3-SNAPSHOT:parserJava (scan-sources) @ observe-swing ---
[INFO] Parsing is done. [treated file(s) : 151/206](total time:450.823ms) ( ~ 2.188ms / file)

Quoi de neuf dans la version 2.2

La version 2.2 supprimer juste des deux méthodes dépréciées en 2.1 :

I18n._(String)
I18n.n_(String)

Il est conseillé d'utiliser dans vos applications directement cette version et non pas la version 2.1, pour vous éviter des problèmes ensuite... (si par exemple vous utiliser à plus haut niveau la version 2.2).

Quoi de neuf dans la version 2.1

Nouveautés dans le module maven

Il est maintenant possible de générer une locale par défaut (par exemple mesTraductions.properties) en utilisant l'option generateDefaultLocale dans votre pom.

Un parserTapestry et un parserGWTJava ont été ajoutés. Le parseur GWT récupère toutes les clés identifiées par l'annotation @Key. En le couplant avec le parseurXML, vous pouvez gérer complètement vos traductions avec nuiton-i18n.

Nouveautés dans l'api

Il est possible désormais de spécifier la locale à utiliser pour la traduction en utilisant la nouvelle méthode

I18n.l_(Locale.FRANCE, "To translate");

Ainsi on peut désormais utiliser I18n pour des applications de type web dans les couches de services en passant la locale de l'utilisateur.

Ce nouveau mode de traduction a nécessité de revoir le design d'initialisation de la librarie qui s'en trouve simplifié et renforcé. Un certain nombre de méthodes sont dépréciées et seront supprimées en version 3.0.

Globalement une seule méthode devrait rester dans la version 3.0 :

I18n.init(I18nInitializer, Locale);

Les méthodes n_(String), _(String) ont été dépréciées et seront supprimées en version 3.0.

Quoi de nouveau dans la version 2.0

Depuis la version 2.0, les bundles i18n générés (dans src/main/resources/i18n) sont compatibles avec l'api java de ResourceBundle, à savoir qu'on a remplacé les - par des _.

Avant on avait

malib-fr_FR.properties

Et maintenant c'est :

malib_fr_FR.properties
  • Migration vers la version 2.0

    Pour utiliser la version 2.0, il faut avant tout renommer dans votre projet les bundles avant les bons noms (sinon ils seront générés lors de la première exécution et il est toujours mieux de renommer des fichiers existants pour conserver l'historique des fichiers dans le gestionnaire de versions).

    Pour ce qui est du mode bundle (mojo bundle), aucune modification n'est nécessaire et il restera compatible avec des librairies packagées avec I18n non en 2.0.

  • Ajout d'un parseur JSP

    Un nouveau parseur JSP a été introduit pour pouvoir intégrer le système de détection I18n dans des développement web (struts par exemple).

    Jettez un oeil aux tutoriaux pour voir comment enrichir votre application avec Nuiton I18n.

  • Amélioration des parser xml

    Les parseurs de type xml (actuellement on avait que le parserValidation) ont été améliorés dans leur design. Certain paramètres sont devenus communs à tous les parseurs. Regarder la page de détails de goal pour voir ce qui a changé.

    On a pu introduire un nouveau parseur parserXml qui ne contient aucune règle de détection de clefs (via xpath), l'utilisateur doit les spécifier par lui même; ce nouveau mojo permet ainsi d'utiliser la détection de clef dans du xml non pris en charge par le projet.

  • Suppression du module I18n ant tasks

    Ce module n'est plus maintenu depuis bien longtemps, il est donc désactivé du build par défaut, il reste cependant dans le projet et est activitable dans un profile nommé ant-task-profile.

    Donc pour construire le projet I18n avec ce module il suffit de lancer :

    mvn install -Pextra-modules