On Wed, 19 Jan 2011 19:22:32 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Wed, 19 Jan 2011 16:12:50 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Wed, 19 Jan 2011 15:54:20 +0100 Jean Couteau <couteau@codelutin.com> wrote:
les méthodes _(String locale, String message) et _(String locale, String message, String... args).
Je m'interroge sur la pertinence de la présence de ces deux méthodes ?
On peut très bien appeler cette méthode sans args:
_(String locale, String message, String... args)
ce qui devient comme appel:
_(String locale, String message)
D'ailleurs dans ce cas si les deux existes laquelle est utilisée ? Donc mon idée serait de supprimer les méthodes sans args ? Est-ce une bonne idée ? +1 La locale c'est un objet, pas un string donc faut vraiment pas mettre ce genre de méthode.
De même je suis assez pour qu'on supprime les méthodes historiques : I18n.init(String) I18n.init(String, String) On sait quand même écrire une locale ou la convertire lorsque ça vient par exemple d'ApplicationConfig. Qui s'oppose à la dépréciation de ces deux méthodes init ?
Quelqu'un voit une objection a virer _(String) du code puisque _(String, Object...) la remplace.
Le seul probleme, peut-etre, serait dans des programmes qui ne comprennent pas la syntaxe ... et qui attende toujours un Array (ca arrive aussi dans certain langage de script avec lequel on utilise les methodes java).
+1 Cela serait très bien de supprimer ces méthodes car c'est un peu agaçant d'avoir toujours la complétion sur les deux méthodes dès qu'on veut traduire.
sinon l'exepression rationnelle pour le parsing du header serait pour l'instant:
header = "^_\\(\\s*\\\"|[^l]_\\(\\s*\\\"|l_\\([^,]+\\s*,\\s*\\\""
Mais ca ne supporte pas le l_(new Locale("fr", "FR"), "message")
pour cela il faudrait utiliser
header = "^_\\(\\s*\\\"|[^l]_\\(\\s*\\\"|l_\\([^,(]+(\\([^)]*\\))?\\s*,\\s*\""
mais qui ne supporte pas les trucs encore plus complique comme l_(new Locale(getLang(), getPays()), "message")
Mais comme ecrire tout ca sur une seul ligne va a l'encontre des bonnes pratiques :). Je me creuse plus la tete pour trouver une meilleur regexp ;)
en gros en regexp on peut pas compter (ici le nombre de parenthese ouverte qu'il faut refermer :()
+1 On ne pourra jamais avec une regex avoir le pouvoir d'expression d'un parseur java et c'est pas trop le but :) Mieux vaut rester au plus simple (diction de mon maître à penser :)). Pour finaliser l'évolution 1028 : J'ai ajouté les tests unitaires pour vérifier que ça marche bien : - test d'intégration au niveau maven pour vérifier la bonne détection - test unitaire au niveau de l'api pour vérifier que les système fonctionne bien. - j'ai mis aussi un petit @since 2.1 sur tes nouvelles méthodes Ben car c'est assez important je pense. Reste à finir un peu de doc car cette évolution est très bien et va nous permettre d'utiliser I18n en contexte multi-langue (et ça va bien me sauver sur t3 par exemple dans mes services). La seule chose que je déplore c'est que ça arrive sur devel un an après que j'ai posé l'évolution sur redmine (regrettable tout ça :)). J'aurais besoin d'une release d'ici lundi je pense donc si quelqu'un veut bien faire la doc demain c'est cool. PS: Tout est déployé sur Maven donc Jean tu peux t'en servir si tu veux :) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com