Le 30/04/2012 00:26, Benjamin POUSSIN a écrit :
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
Comme tu dis. Pour moi, c'est la pire solution.
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 :))
C'est le soucis, on ne doit pas faire de supposition sur l'aspect multi-thread de l'appli.
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.
Je pense que c'est la bonne façon de faire. Quand tu te prends un IOException dans ton UI, bah le message est pas traduit donc on a pas le choix, c'est à l'UI de gérer.
Ne faudrait-il pas tout laisser en anglais et laisser faire les interfaces ?
Je ne vois pas d'autres façon de faire bien. -- Brendan Le Ny, Code Lutin bleny@codelutin.com (+33) 02 40 50 29 28