Salut, Comme vous le savez historiquement les Properties sont en ISO-8859-1 (Latin1), mais la JDK1.6 permet de sauver les Properties en UTF-8. Le souci dans i18n et maven-helper-plugin (SortedProperties), c'est que l'encoding est passé mais n'est pas interprété correctement par le Properties final qui finalement sauve toujours les fichiers en ISO avec les fameux remplacement de caractères \uXXX. L'ano a été créé http://nuiton.org/issues/show/1494 Pour résumé, le plugin i18n prenait bien de l'encoding UTF-8 mais il n'était jamais utilisé sur les sorties de fichier. Embêtant car les fichiers dans les sources étaient écrasé et avaient de joli \uXXX ce qui peut compliquer la vie d'un traducteur. L'idée c'est de permettre de garder les fichier utilisateurs dans l'encodage désiré (goal generate). Le reste pouvant rester en ISO normalement il n'y a pas trop d'impact. Reste ensuite la possibilité de configurer l'encoding de sortie pour les ressources bundle utilisé au runtime. Pour le moment ce n'est pas indispensable, l'ISO est utilisé par défaut dans l'api, mais ca pourrait être une evol intéressante. Je n'ai pas commité pour le moment, mais j'ai résolu les problèmes (et vive les tests it maven ;) C'est une impact importante je pense d'ou les versions moyennes (deuxième chiffre), les projets qui migreront auront directement les fichiers utilisateurs passé en UTF-8 (en fait l'encodage du projet), sauf si l'option srcEncoding du plugin maven est mise en iso-8859-1. Il me faudrait quelques tests pour checker cette migration. Je pense faire une branche en beta pour commiter et tester, et faire rapidement une release car j'en ai besoin pour un autre projet. Cordialement, Flo
Le 30/04/2011 18:17, fdesbois a écrit :
Salut,
Comme vous le savez historiquement les Properties sont en ISO-8859-1 (Latin1), mais la JDK1.6 permet de sauver les Properties en UTF-8. Je pense qu'il y a confusion entre la norme, et "comment il est possible de les lire".
Selon wikipedia [1] les fichiers de properties répondent à une norme. J'ai peur que cela pose plus de problèmes que ca en résolve. [1] : http://fr.wikipedia.org/wiki/.properties -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Le Mon, 02 May 2011 14:34:14 +0200, Eric Chatellier <chatellier@codelutin.com> a écrit :
Le 30/04/2011 18:17, fdesbois a écrit :
Salut,
Comme vous le savez historiquement les Properties sont en ISO-8859-1 (Latin1), mais la JDK1.6 permet de sauver les Properties en UTF-8. Je pense qu'il y a confusion entre la norme, et "comment il est possible de les lire".
Selon wikipedia [1] les fichiers de properties répondent à une norme.
En fait avant la JDK6, il n'y avait pas moyen de lire autrement qu'en ISO-8859-1, ce qui est devenu la norme, mais désormais les méthodes avec Writer/Reader le permettent. Vu que l'on contrôle le chargement dans i18n rien n'empêcherait de gérer d'autres encoding. Je pense que se prendre la tête avec des caractères unicode n'a plus raison d'être, il est possible de faire marcher des Properties en UTF-8, vu qu'on est en 1.6 !! D'autres framework le font comme Spring, Tapestry, GWT...
En passant sur la 2.4 les fichiers sources i18n vont devenir automatiquement en UTF-8, les échappement unicode (\uXXX) seront remplacé par les vrais caractères UTF-8. Du coup, on se demandait avec Tony, si l'UTF-8 pouvait devenir aussi la valeur par défaut d'encoding de sortie (donc des fichiers bundle et de l'api runtime). Il n'y aura pas d'impact, cela se fera de manière transparente. Il sera toujours possible au besoin de revenir sur de l'iso-8859-1 (via le plugin ou l'I18nInitializer de l'api runtime). A vos avis Les releases de libs avec traduction espagnole étant nécessaire, une release d'I18n se fera donc également pour tout passer en UTF-8.
Moi je suis pour passer par défaut les fichiers i18n en UTF-8. D'autant plus que les projets sont déjà en UTF-8. Julien Le Wed, 4 May 2011 17:46:20 +0200, fdesbois <fdesbois@codelutin.com> a écrit :
En passant sur la 2.4 les fichiers sources i18n vont devenir automatiquement en UTF-8, les échappement unicode (\uXXX) seront remplacé par les vrais caractères UTF-8.
Du coup, on se demandait avec Tony, si l'UTF-8 pouvait devenir aussi la valeur par défaut d'encoding de sortie (donc des fichiers bundle et de l'api runtime).
Il n'y aura pas d'impact, cela se fera de manière transparente.
Il sera toujours possible au besoin de revenir sur de l'iso-8859-1 (via le plugin ou l'I18nInitializer de l'api runtime).
A vos avis
Les releases de libs avec traduction espagnole étant nécessaire, une release d'I18n se fera donc également pour tout passer en UTF-8. _______________________________________________ I18n-devel mailing list I18n-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/i18n-devel
Le Wed, 4 May 2011 20:48:37 +0200, Julien Ruchaud <julien.ruchaud@codelutin.com> a écrit :
Moi je suis pour passer par défaut les fichiers i18n en UTF-8. D'autant plus que les projets sont déjà en UTF-8.
Julien
Ok cela simplifiera finalement, il n'y aura plus qu'un paramètre encoding dans le plugin et il sera possible de customiser l'initialisation de l'api runtime pour lui donner l'encoding. Meme si d'ancienne version des libs avec i18n non UTF-8 sont utilisés cela marchera car l'UTF-8 li correctement les fichiers ASCII avec les caractères échappés. Le mieux pour une application finale sera toujours d'utiliser le goal bundle pour regrouper tous les messages du projet et des libs dans un seul fichier properties. L'encoding sera défini par le plugin (par défaut celui du projet donc) et sera disponible dans le fichier de définition utiliser par le DefaultI18nInitializer pour l'api runtime.
participants (3)
-
Eric Chatellier -
fdesbois -
Julien Ruchaud