On Tue, 17 Apr 2012 11:31:50 +0200 Florian Desbois <fdesbois@codelutin.com> wrote: ...
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.
Cette solution me parait la mieux, mais je pense qu'elle ne marche pas trop, surtout lorsqu'une librairie/application crée de nouveau thread (ex: isis (oui je sais c pas du web :), mais j'ai pas d'autre exemple, là, maintenant, tout de suite :)) ...
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 ?).
oui tu te trompes, les arguements sont utilisés dans le message, voir meme formaté (date, nombre). ex: LaJolieCle=Vous venez de copier %s fichier(s) et: i18n._("LaJolieCle", 10) ...
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 ?
De plus en plus, je pense que les messages d'exception ne devraient pas être traduit. Ca n'apporte pas grand chose (Exception == Exceptionnel) donc ne devrait jamais arriver. Et si ca arrive l'application devrait l'intercepter pour mettre son propre message. Par contre, la problématique de traduction reste pour d'autres messages/textes, par exemple lorsqu'on écrit des widgets swings. Mais dans ce cas, nous ne sommes pas dans une appli web, avec des utilisateurs qui souhaite l'utiliser dans plusieurs langues. Il reste les taglibs web que l'on pourrait avoir besoin d'écrire. Dans ce cas comment gérer i18n. Peut-être tout simplement en ayant un attribut pour tous les taglibs <w:edit i18n='fr_FR' .../> La valeur de l'attribut pourrait être positionné par une variable dans la JSP. Il reste le cas d'"application" que l'on réutilise dans d'autre (exemple: intégration d'application de forum, utilisation d'extension webmotion, ...). Dans le premier type d'exemple, on ne peut pas y faire grand chose, car on a pas écrit le code. Pour le deuxième type d'exemple si c'est nous qui écrivons le code, il faut peut-être y réfléchir. Si le framework ne nous oblige pas à utiliser son mécanisme
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...
-- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com