...
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 :))
+0 Il me semblait qu'on avait dit que c'était dangeureux à terme d'être en ThreadLocal (surtout pour du web ?).
...
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. +1 on arrive à des systèmes délirants :( Ce n'est pas de la responsabilité pour moi des
Ben il a dit n_ pas _ donc où ça ne sert à rien Flo d'utiliser des paramètre sur cette méthode son unique but étant de marquer des clefs de traductions. libs de traduire les erreurs. Exemple : topia et c'est le bon example vu que tout devrait être en runtime...
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... +1 on doit supprimer ça de Topia dès que possible :)
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com