méthodes _() avec la locale forcée pour une utilisation en mode web.
Dans un contexte web, on peut être ammené à vouloir traduire des messages côtés serveur, les utilisateurs peuvent avoir des locales différentes et faire des appels simultanés, l'idée c'est donc d'avoir les méthodes _(String locale, String message) et _(String locale, String message, String... args). Ces méthodes, au lieu de faire un getCurrentLanguage pour trouver la langue, rechargeraient la langue correspondant à la locale passée en paramètre. Pour ça faudrait modifier légèrement le i18nStore pour que l'ajout d'un langage soit fait au get et non au set. Bonne idée ?
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 ? Ensuite plutôt que String locale, je préférerais Locale locale (donc utilisation de l'objet) -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
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 ?
Ensuite plutôt que String locale, je préférerais Locale locale (donc utilisation de l'objet)
+1 pas d'utilisation de locale en String. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
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 ?
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). 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 :() -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
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
On Wed, 19 Jan 2011 22:51:38 +0100 chemit <chemit@codelutin.com> wrote: ...
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 ?
moi, un peu :). Mais pas trop :) (pas le courage d'expliquer par mail :() Sinon j'attendrais peut-être que ApplicationConfig sache retourner un objet Locale
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.
ticket créé pour la version 3 (changement d'api): http://www.nuiton.org/issues/show/1214 ...
- j'ai mis aussi un petit @since 2.1 sur tes nouvelles méthodes Ben car c'est assez important je pense.
Oui c'est une bonne pratique, j'essaie de le faire, mais j'y pense pas encore toujours :( -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Thu, 20 Jan 2011 20:24:05 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Wed, 19 Jan 2011 22:51:38 +0100 chemit <chemit@codelutin.com> wrote:
...
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 ?
moi, un peu :). Mais pas trop :) (pas le courage d'expliquer par mail :() ca aide pô cette réponse, je vois pas en quoi tu peut-être contre le fait de remplacer des povre string par un object typé Locale :)
Sinon j'attendrais peut-être que ApplicationConfig sache retourner un objet Locale
ba il sait déjà faire ça :) On a un LocaleConverter offert par nuiton-i18n donc pas de soucis pour moi. Issue de ObserveConfig : @Override public Locale getLocale() { Locale result = getOption(Locale.class, LOCALE.key); return result; } Je rajoute au passage la méthode dans applicationConfig : getOptionAsLocale comme ça tout le monde est content. Pour aller plus loin je verrais bien aussi une méthode I18n.init(Initializer, Locale) Comme ça tout est fait en une seule méthode et est type safe; que demande de plus le peuple ? -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Wed, 19 Jan 2011 15:54:20 +0100 Jean Couteau <couteau@codelutin.com> wrote:
Dans un contexte web, on peut être ammené à vouloir traduire des messages côtés serveur, les utilisateurs peuvent avoir des locales différentes et faire des appels simultanés, l'idée c'est donc d'avoir les méthodes _(String locale, String message) et _(String locale, String message, String... args).
Ces méthodes, au lieu de faire un getCurrentLanguage pour trouver la langue, rechargeraient la langue correspondant à la locale passée en paramètre.
Pour ça faudrait modifier légèrement le i18nStore pour que l'ajout d'un langage soit fait au get et non au set.
Bonne idée ?
et pas une idée neuve si on regarde cette évolution [1] qui date d'il y a 315 jours :) Certes y'a aucune description mais bon je pensais que le titre voulait dire ça : "Make I18n multi-language", J'aurais mieux fait d'écrire : Make I18n multi-langaguage at runtime :) [1] http://www.nuiton.org/issues/show/372
_______________________________________________ I18n-devel mailing list I18n-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/i18n-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
participants (3)
-
Benjamin POUSSIN -
chemit -
Jean Couteau