- I18n-devel - mailman.cloud.codelutin.com

Fwd: Nuiton I18n included in the Softpedia Mac OS software database
by Kevin Morin 24 May '13

24 May '13

-------- Original Message -------- Subject: Nuiton I18n included in the Softpedia Mac OS software database Date: Thu, 23 May 2013 21:09:05 -0400 (EDT) From: Softpedia Editorial Team <maceditor(a)softpedia.com> To: info(a)codelutin.com Congratulations, Nuiton I18n, one of your products, has been added to Softpedia's database of software programs for Mac OS. It is featured with a description text, screenshots, download links and technical details on this page: http://mac.softpedia.com/get/Development/Libraries/Nuiton-I18n.shtml The description text was created by our editors, using sources such as text from your product's homepage, information from its help system, the PAD file (if available) and the editor's own opinions on the program itself. If you feel that having your product listed on Softpedia is not a benefit for you or simply need something changed or updated, please contact us via email at webmaster(a)softpedia.com and we will work with you to fix any problem you may have found with the product's listing. -- Sincerely, The Softpedia Team ----------------------------------------------------------------------- Softpedia is a library of over 1 million free and free-to-try software programs for Windows, Mac OS and Linux, games and gaming tools, Windows device drivers, mobile devices and IT-related articles. ----------------------------------------------------------------------- Softpedia - the encyclopedia of free software downloads http://www.softpedia.com/

1 0

[ANN] - I18n 2.5.1 released
by nuiton.org Release Notification 16 May '13

16 May '13

The I18n team is pleased to announce the i18n-2.5.1 release! Nuiton i18n tools Documentation of the project can be found here: http://maven-site.nuiton.org/i18n Changes ------- Changes in this version include: New features: o Add more xpath expression for parserValidation Issue: 2304. Thanks to Tony Chemit. Resolved by tchemit. Fixed Bugs: o Test are not well isolated Issue: 2653. Thanks to Tony Chemit. Resolved by tchemit. o Unable to build when using tapestry Issue: 2654. Resolved by tchemit. Changes: o Updates to helper-m-p 2.0 Issue: 2418. Thanks to Tony Chemit. Resolved by tchemit. o Updates to commons-lang3 Issue: 2420. Thanks to Tony Chemit. Resolved by tchemit. o Updates to xwork-core 2.3.4.1 Issue: 2421. Thanks to Tony Chemit. Resolved by tchemit. o Updates to mavenpom 3.4.4 Issue: 2425. Thanks to Tony Chemit. Resolved by tchemit. Downloads --------- For a manual installation, you can download files here: http://nuiton.org/projects/i18n/files * nuiton-i18n-2.5.1-deps.zip - http://nuiton.org/attachments/download/923 * nuiton-i18n-2.5.1-full.zip - http://nuiton.org/attachments/download/924 Maven artifacts --------------- Artifacts are deployed in Maven Central Repository http://repo1.maven.org/maven2/ Find us at * http://search.maven.org/#artifactdetails|org.nuiton|i18n|2.5.1|jar Have fun! -I18n team

1 0

2.5.1 release ?
by Brendan Le Ny 15 May '13

15 May '13

Hi, I need a stable version of i18n. Can I release it ? Everything in the roadmap is fixed. -- Brendan Le Ny, Code Lutin bleny(a)codelutin.com (+33) 02 40 50 29 28

2 1

Améliorer le mécanisme des parseurs
by Tony Chemit 05 Sep '12

05 Sep '12

Hello, Supprimer les clefs i18n vides déjà connues ------------------------------------------- j'aimerais bien faire quelques modifications sur le mécanisme de conservation des clefs i18n dans chaque module. A l'heure actuelle, quand une clef est détecté dans un module, elle est conservée dans le bundle du module, même si cette clef provien d'un autre module. Je voudrais changer ça en ajoutant une option qui permettre en fait de supprimer toutes ces clefs qui n'aurait pas été surchargées dans le module, ainsi ça éviterait d'avoir des clefs vides dans chaque modules qui n'apporte pas grand chose. Nouveau goal de cache des artifact i18n --------------------------------------- Je voudrais aussi un peu améliorer l'aggrégation des bundles en ajoutant un nouveau goal qui permet de récupérer une fois pour toute (enfin à chaque fois que cela est nécessaire... (cache vide dans target)) les artifacts intervenants dans l'aggregations i18n, ça c'est déjà fait partiellement par les goals de type BundleXXX. La première fonctionnalité en aurait aussi besoin, donc je crois qu'il est temps de le mettre en place de manière plus générale (sans notion de bundle) A vos avis ;) tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

1 0

[ANN] - I18n 2.5 released
by nuiton.org Release Notification 04 Sep '12

04 Sep '12

The I18n team is pleased to announce the i18n-2.5 release! Nuiton i18n tools Documentation of the project can be found here: http://maven-site.nuiton.org/i18n Important Note -------------- The artifactId of the maven pluign has changed from maven-ii18n-plugin to i18n-maven-pluign, do not forget to change your poms. Changes ------- Changes in this version include: New features: o Generate a csv file with all translations for all locales in a csv file in bundle mojo Issue: 2291. Thanks to Tony Chemit. Resolved by tchemit. o Add a acceptKeyFormat in parsers mojo to filter which incoming keys can be kept Issue: 2288. Thanks to Tony Chemit. Resolved by tchemit. o Introduce a simple struts2 jsp parser Issue: 2290. Thanks to Tony Chemit. Resolved by tchemit. Fixed Bugs: o Error on validation compilation using nuiton-validator when no internet connection Issue: 2242. Thanks to Florian DESBOIS. Resolved by tchemit. Changes: o Updates to helper-m-p 1.5 Issue: 2296. Thanks to Tony Chemit. Resolved by tchemit. o remove ant module from svn Issue: 2297. Thanks to Tony Chemit. Resolved by tchemit. o Use maven-plugin-plugin 3 api Issue: 928. Thanks to Tony Chemit. Resolved by tchemit. o Updates to mavenpom 3.3.7 Issue: 2175. Thanks to Tony Chemit. Resolved by tchemit. o Deprecate some parser (jsp, tapestry) : there are not enough efficient :( Issue: 2289. Thanks to Tony Chemit. Resolved by tchemit. o Rename mojo module to i18n-maven-plugin Issue: 2176. Thanks to Tony Chemit. Resolved by tchemit. Downloads --------- For a manual installation, you can download files here: http://nuiton.org/projects/i18n/files * nuiton-i18n-2.5-deps.zip - http://nuiton.org/attachments/download/758 * nuiton-i18n-2.5-full.zip - http://nuiton.org/attachments/download/759 Maven artifacts --------------- Artifacts are deployed in Maven Central Repository http://repo1.maven.org/maven2/ Find us at * http://search.maven.org/#artifactdetails|org.nuiton|i18n|2.5|jar Have fun! -I18n team

1 0

Messages exception en mode web
by Florian Desbois 02 May '12

02 May '12

Contexte ====== La plupart des librairies nuiton utilisent i18n pour les messages des exceptions. Certaines d'entre elles sont intéressantes d'un point de vue fonctionnelle et les messages pourraient directement être retournés à l'utilisateur. Par exemple lors d'un import CSV (nuiton-csv), les messages d'erreurs définissent le numéro de ligne, le type d'erreur, etc... Problématique ========= Les messages d'exceptions sont directement traduit avec i18n avec l'utilisation de la méthode _(). Cependant dans un contexte web, la locale dynamique modifiée depuis l'interface, ne change pas l'état d'I18n qui garde sa locale par défaut à l'initialisation. Comment récupérer alors la clé i18n ou trouver un système permettant de traduire l'exception en fonction de la locale du contexte web ? Solution 1 (la plus simple) ================ L'API de la JDK propose une méthode getLocalizedMessage() mais la locale n'est stipulé nul part. Il faudrait potentiellement la pousser soit via constructeur (trop intrusif), soit via getter/setter (plus souple, car la locale peut être mise au moment du catch par exemple). Ainsi la méthode getLocalizedMessage() renverrais une traduction localisé (si la locale est mise) en fonction des paramètres de l'exception. Quelque chose comme : @Override public String getLocalizedMessage() { String result; if (locale == null) { result = getMessage(); } else { result = l_(locale, i18nKey, getMessageArgs()); } return result; } Le paramètre i18nKey pourrait être le message de l'exception en utilisant n_("i18n.key") au moment de l'instanciation. Les "messageArgs" dépendent de l'exception. Plus ou moins dynamique suivant les besoins. Variante: ------------ Quitte à avoir une api avec les getter/setter sur la Locale, autant ajouter directement une méthode getLocalizedMessage(Locale locale). => Cela implique un ajout et une gestion de la locale dans toutes les exceptions que nous utilisons dans les librairies, ou à minima les plus pertinentes comme la validation ou l'import/export CSV. Solution 2 (la moins coûteuse en refactoring) ============================ Avoir une option pour traduire en utilisant un ThreadLocal permettant de stocker la locale. Ainsi toutes les méthodes _() seront contextualisés par rapport à ce ThreadLocal. Solution 3 (l'autre) =========== Laisser le loisir de traduire le message à l'interface cliente. Dans ce cas toutes les instanciations d'exception devront utiliser n_() plutôt que _() pour garder la clé i18n en tant que message. Libre à l'interface cliente de le traduire ou non. Les traductions des librairies seront toujours présentes grâce aux bundles. Variante (plus compliqué): ----------------------------------- Une autre idée serait de garder la clé i18n mais aussi ses paramètres. Je me suis toujours demandé l'intérêt d'avoir n_("i18n.key", arg1, arg2) alors que finalement arg1 et arg2 ne seront jamais gardé ni utilisé (a moins que je me trompe ?). On pourrait avoir une autre méthode qui sérialise les paramètres (vu que de toute façon on veut des string). s_("i18n.key", arg1, arg2) = "i18n.key|toto|18" qui serait le message de l'exception. Ensuite _() doit être capable d'interpréter ce parsing avec le séparateur | (ou n'importe quel caractère qui ferait l'affaire). => Les solutions 3 et 4 posent le problème du logging ou des catch automatique des framework. En effet, la méthode getMessage() sera généralement appelé sur les stackTrace, mais ici on aura pas de traduction, à moins encore une fois de surchargé la méthode getMessage() de toutes les exceptions (pour appeler _() ) et d'ajouter une autre méthode getOriginalMessage() pour avoir la clé sérialisé. Conclusion ======= Cela reste une problématique qui a ses limites. A t-on la réelle nécessité de devoir traduire tous les messages d'exceptions ? Ne faudrait-il pas tout laisser en anglais et laisser faire les interfaces ? De mon point de vue, je ne sais pas encore quelle est la meilleure solution. Mais je trouve dommage d'avoir toute la gestion i18n de faites dans les messages d'exceptions alors qu'elle est inutilisable dans un contexte web...

6 5

[ANN] - I18n 2.4.1 released
by nuiton.org Release Notification 04 Aug '11

04 Aug '11

1 0

[ANN] - I18n 2.4 released
by nuiton.org Release Notification 13 May '11

13 May '11

1 0

Properties encoding UTF-8
by fdesbois 04 May '11

04 May '11

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

3 5

[ANN] - I18n 2.3.2 released
by nuiton.org Release Notification 24 Mar '11

24 Mar '11

1 0