Discussion :

[grunt2000]

Bonjour,


Je souhaite réaliser une application capable de sélectionner la locale la plus proche des souhaits de l'utilisateur. C'est à dire, dans un premier temps, la plus proche du contenu de sa directive HTTP Accept-Language.

Cette directive peut contenir plusieurs locales.
En général, tout se passe bien côté web. Un framework web, JSF 2 par exemple, prend convenablement les choses en main.
Mais cela se complique lorsque l'on s'adresse à la couche service puis persistance de son application.

Là, une seule locale est souvent transmise (quand on ne l'a pas oubliée...),

et l'on écrit souvent ce code:
ResourceBundle bundle = ResourceBundle.getBundle("service.DodoOffice", locale);

en ne retenant que le premier choix de l'utilisateur.

Les choix secondaires qu'il a pu faire, ceux que côté web on connaissait, sont passés à la trappe. Côté service et persistance, bien souvent, on ne les connait plus. Je pense que ça se vérifie dans de nombreuses applications.


Mon objectif, c'est de m'assurer que l'intégralité des souhaits de l'utilisateur est transmise à ces couches. C'est à dire qu'il faut que je transporte un tableau de locales ordonnées selon ses préférences et non pas seulement son premier choix.

Au moment de la négociation, celui où je mets en relation ses souhaits et ce que je possède de locales, je me pose une question:

1) Si l'utilisateur a fait ces choix: {fr_CA, de} (Français du Canada, Allemand}
mais que mon système possède {fr_BE, de} (Français de Belgique, Allemand}
dois-je choisir pour lui fr_BE ou de?

2) Toujours avec ces préférences utilisateur {fr_CA, de},
si mon système possède {fr, de}, lui reverrais-je fr ou de?

Quelle est la règle?
a) Est-ce que je considère la deuxième partie de la locale (la variante) comme un dialecte, et alors je dis que je peux pas renvoyer ce que l'utilisateur me demande si ce n'est pas précisément cela que j'ai, à la variante près?
=> Dans les cas 1 et 2 je renvoie alors: de.

b) Est-ce que je considère cette variante comme un dialecte, mais je dis que fr seul vaut tous dialectes et je le renvoie?
=> Dans le cas 1 je renvoie de, dans le cas 2 je renvoie fr.

c) Ou bien est-ce que je considère cette variante comme une région, et je dis qu'elle n'a pas d'importance en soi, et alors:
=> Dans les cas 1 et 2, je renvoie fr.


En vous remerciant,

Grunt.

[tchize_]

La logique voudrait que votre application dispose des locales suivantes:

fr, de.

Si elle a envie, elle ajoute des locales régionales (fr_CA ou fr_BE) mais uniquement après avoir pris en charge la locale de base (fr) sinon c'est la prise de tête à gérer. Donc si vous mettez dans votre application fr_CA, mettez aussi fr (quitte à faire une copie de fr_CA ).

Pour les couches inférieures, normalement vous n'y avez pas besoin de locale. En effet, tout ce qui est message à l'utilisateur doit être géré dans la couche interface utilisateur. Rien en dessous ne devrais gérer de message pour l'utilisateur. Ainsi, si une connection DB échoue, vous remontez une exception, et quand vous affichez le message à l'utilisateur (UI), utilisez à ce moment la locale.

Enfin, au dessus de ça, n'oubliez pas que vous devez laisser à l'utilisateur choisir sa langue au dela des choix du navigateur

[grunt2000]

Je suis d'accord. J'espère bien que j'aurais toujours fr aux côtés de fr_CA.
Ça semble très sain.

Mais il y a deux raisons pour lesquelles je me pose le problème:
- Je crée l'algorithme général dont je vais avoir besoin, donc même si le problème ne devrait rarement se rencontrer, il faut que je trouve un moyen de le traiter.

- Il existe des situations où cela pourrait se produire: un utilisateur U1 saisit un libellé dans une locale X. Et un autre utilisateur U2, lecteur, vient pour le lire.
X peut très bien être volontairement: fr_CA, parce que la langue de saisie souhaitée par l'utilisateur U1 est bien français dans sa variante canadienne (que l'on sait un peu différent du français de métropole).


Pour les couches inférieures, normalement vous n'y avez pas besoin de locale.
Je l'ai cru, jusqu'à manœuvrer une application dont 70% du code se trouve dans la couche service/persistance.

Une couche service finit toujours par rendre un service.
1) Parfois, c'est juste contacter des APIs tierces, en leur transmettant la bonne locale pour être sûr qu'elles font faire un travail dont elle ne sait pas avec précision ce dont il s'agit, mais qui devra être fait dans la bonne langue.

2) Parfois, elle doit lire ou écrire des données localisées.
Au moment du load depuis une table, c'est fr_CA que l'on prend pour choisir en priorité tous les libellés en fr_CA depuis nos données. Les libellés multilingues sont en tables, et non dans l'IHM alors. Oublier les locales de l'utilisateur mène à lire les mauvais.

3) Enfin, un service ne peut pas s'abstraire de composer lui-même des messages (d'exception ou autre). C'est lui qui a la meilleure connaissance au moment où il peut les créer. S'ils sont délégués à l'IHM, alors cela cause ces problèmes:
a) il faut transporter tous les messages que le service pourrait expédier dans des propriétés à destination de l'IHM. En un seul bundle? En dix bundles? En cent bundles?

b) il faut mettre des variables membres à toutes les exceptions et en avoir une par incident distinct possible, afin que l'IHM puisse composer le message d'erreur complet comprenant tous les éléments qui sont entrés en jeu durant l'anomalie constatée. Son "MessageFormat" doit aboutir à "Je faisais ceci avec {0} et {1}, et puis j'ai voulu ajouter {2} là dedans et ça a raté pour la raison {3}.". Pas évident.

c) la couche IHM doit coller plus encore qu'à l'accoutumée à la couche service. Liée jusqu'aux messages (exceptions et autres messages). C'est très rigidifiant. L'équipe qui gère les services ne peut plus ajouter un nouveau message ou en modifier un sans que l'équipe IHM l'apprenne et le prenne en compte.
Or la couche service détient souvent les règles métiers à l'échelle de l'entreprise, à disposition des applications clientes IHM A, B, C et D qui l'utilisent. Elle ne peut pas se mettre dans un mode "pattern observateur" à ce point là: "J'ajoute un message d'erreur, donc vous devez toutes vous recompiler.". Ouille, sinon.

De manière générale, l'IHM a sa logique applicative. Les services ont leur logique métier. Chacun garde son rôle et sa compréhension des problèmes. Certains faits que les services énoncent iront peut être vers l'IHM, mais peut être vers des logs, des rapports qui seront faits plus tardivement, tout ce que l'on veut. Les coupler fortement par leurs messages me semble empoisonnant.


Enfin, au dessus de ça, n'oubliez pas que vous devez laisser à l'utilisateur choisir sa langue au delà des choix du navigateur.
Absolument! Mais tant qu'il n'a pas fait de choix précis, celui qui est fait défaut, doit être celui indiqué par son navigateur.


Grunt.

[tchize_]

pour l'algorithme général, référez vous à celui utilisé par Ressource Bundle, ainsi vous serez consistant: pour fr_CA, les choix valables sont "fr_CA", "fr" et "default"



Pour les couche service qui ont besoin d'une locale, celle-ci doit être indépendante de l'interface. Autrement dit, votre interface gère la locale de l'utilisateur. La couche service effectue une service para rapport à des paramètres qu'ont lui passe. La locale peut faire partie de ces paramètres, mais elle doit être dissociée de la GUI. 5exemple, il doit pouvoir être possible d'afficher sur une même page le résultat de la requete en francais et en anglais, moyennant uniquement modificiation de l'interface .

[grunt2000]

pour l'algorithme général, référez vous à celui utilisé par Ressource Bundle, ainsi vous serez consistant: pour fr_CA, les choix valables sont "fr_CA", "fr" et "default"

Oui, mais ResourceBundle prend en considération une seule locale candidate.

Imagine la situation suivante:
Tu sais que la chine porte de nombreux dialectes, très étrangers les uns aux autres et une langue commune, que tous ne maitrisent pas systématiquement.

Si tu prends un chinois près de la frontière mongolienne qui a demandé:
{zh_monDialecte, mn} (mon dialecte chinois ou mongol) et que tu lui donnes zh (langue commune), il ne sera peut être pas satisfait.


Ce que dit ResourceBundle, c'est une chose.
Je cherche ce à quoi s'attend l'utilisateur. Ce qui lui conviendra au mieux.

Grunt.

[tchize_]

l'algorithme du ressource bundle est suffisant, pour autant que vous en retiriez le default. Ainsi, si un utilisateur a mis

zh_monDialecte, mn


et que tu dispose de
zh_AutreDialecte
zh
mn
en

dans ton application, il me semble normal de lui fournir zh, soit le premier bundle qui matche sa langue prioritaire. Et si il est pas content avec ça, il en change dans l'interface. Trouver à tous les coups ce qui est parfait est un problème à mon avis insoluble, puisque dépendant de chacun. Certains trouveront normal que si on ne connait pas le dialecte précis, on lui donne le chinois de base, d'autres non.

Donc pour moi prendre l'algo "XX_YY matche XX_YY en prirorité, puis XX" est suffisant. Ensuite t'applique l'algo sur toutes les langues demandées jusqu'à trouver le bon. Une fois que tu as trouvé la locale en question, ca deviens la seule locale de l'interface utilisateur.