Bonjour tout le monde,

J'ai un probleme avec les locales de jelix.

Voila la situation :

J'ai une application localisee en anglais us (en_US). J'apprend que l'on va devoir localiser notre application pour un autre pays anglophone qui a simplement quelques particularites, en particulier le format de la date. Il se trouve que je gere le format de la date pas les fameuses locales de jelix.

Je me suis dit, pas de probleme, je vais ajouter simplement une locale pour cet autre pays, mettre defaultLocale (je suis en jelix beta3) a la valeur de ce pays et si jelix ne trouve pas la cle correspondante pour ce pays, il va retourner en anglais US... sauf que pas moyen apparement de definir une locale par defaut par defaut.

Je vois 5 possiblites :

• Je duplique completement mes locales pour les 2 pays et je maintient les 2 (ca me plais pas beaucoup)

• Je fais une surcouche de jLocale et j'ajoute une cle dans un fichier de config qui defini la locale "courante a utiliser" et qui fait passer a jLocale si elle ne trouve pas. Tout ca pour ne pas modifier le code de jelix. J'appelle cette surcouche seulement lorsque j'en ai besoin (pour les dates par exemple) et je fais le plugin de template qui va avec (mes dates sont souvent affichee pas les templates)

• Je fais a peut pres la meme chose qu'au dessus mais je defini plutot une locale par defaut par defaut(2x) utiliser si on ne trouve pas dans la locale par defaut(1x)

• J'ai aussi remarque que si on donne des parametres supplementaires a la methode jLocale::get(), celle-ci tente une premiere fois de trouver la cle dans la locale specifiee et ensuite, tente de trouver cette cle dans la locale par defaut. Seulement, le plugin de template de jLocale ne parmet apparement pas d'utiliser ces parametres. Il faut donc dans ce cas que je fasse un nouveau plugin de template.

• Jelix possede un merveilleux mecanisme secret qui m'aurais echape, ou il y a une meilleure facon d'utiliser les mecanismes dont je viens de parler.

Pour le moment je pense que la solution la moins chere est de faire un petit plugin de template mais peut-etre avez-vous des suggestions ?

(Desole pour ce long post)

J'ai aussi remarque que si on donne des parametres supplementaires a la methode jLocale::get(), celle-ci tente une premiere fois de trouver la cle dans la locale specifiee et ensuite, tente de trouver cette cle dans la locale par defaut

Non, ça ne fait pas ça du tout. Si tu n'indiques pas de locale/charset, ça utilise le locale/charset par défaut, c'est tout.

La seule solution la plus simple est de dupliquer tout tes fichiers de locales dans tes nouveaux répertoires de langues. Ça fonctionne très bien. Et ça restera compatible avec les futures évolutions de Jelix. D'ailleurs ton problème est déjà indiqué dans le ticket 95.

Maintenant effectivement, tu peux aussi te faire un plugin spécifique.. Sinon je trouve tes autres pistes acrobatiques.

À noter que les formats sont dans un fichier de locales spécifiques dans le module jelix. Et ces locales sont utilisées entre autre par jDateTime.

Effectivement, j'ai mal lu le code de jLocale, et j'ai pas pense a regarder les tickets.

Dans ce cas je vais surement dupliquer completement les locales et reflechir a une meilleure solution pour plus tard.

Merci pour les infos!

EDIT : une solution + efficace, basée sur celle-ci, est expliquée dans le message suivant.

Salut,

une solution pourrait-être de modifiler la méthode qui compile les fichiers locales (j'ai déja commencé pour tester).

L'idée, c'est d'avoir une arbo du type :

• moduleX
  • locales
    • en
    • en_EN
    • en_US
    • fr
    • fr_CA
    • fr_FR

au moment de la compilation, on regarde d'abord le fichier dans /locales/xx/ (xx étant les 2 premiers caractères de la locale à compiler).

ensuite, les éléments qui sont dans /locales/xx_YY/ viennent s'ajouter (et remplacer, s'il y a lieu) les éléments spécifiques à cette variante de la locale xx.

Bien entendu, si /locales/xx/ n'existe pas, ou est vide, etc... le fonctionnement actuel est conservé, du coup on n'a pas à changer les applis existantes.

On conserve aussi 1 seul cache par fichier locale, donc on ne pénalise pas les performances (sauf à la compilation, mais sur une appli en production, c'est négligeable comme il n'y a que très peu de changements).

Bref, je suis en train d'écrire un patch en ce sens (en rapport avec le ticket 95 que je découvert avec ce post).

Ce process règle également le problème de la localisation qui n'existe pas. Par exemple, en_UK utilisera ce qui se trouve dans /locales/en/. (Il faudrait peut-être déclencher une erreur quand même ? un warning ? notice ?)

Si on ne déclenche pas d'erreur sur le système précédent, alors je pense qu'on aura pas trop de problème à faire passer "en" au lieu de "en_EN" comme paramètre à jLocale. Suffit de dire que si la locale fait 2 caractères, alors locale = xx_XX (même si ça n'existe pas), et voilà.

Sur le principe, tu en penses quoi Laurent ?

Euh, je laisse le message au dessus pour conserver l'idée, mais tout de suite une idée d'amélioration :

si le répertoire par défaut était justement xx_XX au lieu de xx (donc fr_FR au lieu de fr par exemple) ?

L'avantage, c'est de ne pas créer un répertoire en plus.

On dit que xx_XX c'est la locale complète par défaut, et que xx_YY peut surcharger xx_XX.

Comme la fusion/surcharge se fait à la compilation, on a les 2 locales complètes en cache, et le système ne change pas du tout.

Ca me semble mieux, car on économise une étape. Tout le reste du process reste le même (fallback vers la locale xx_XX si xx_YY n'existe pas, ou si on demande juste la locale xx avec 2 caractères seulement).

Finalement, je crois qu'il est possible de le faire encore plus facilement, sans modifier le process de compilation, etc...

je vous tiens au courant

Salut,

Patch envoyé

doubleface : je pense qu'il résoud ton problème, tu peux par exemple surcharger uniquement 1 terme dans la locale "secondaire" (en_XX). S'il ne trouve rien pour cette locale, alors il va chercher dans le locale générique en_EN.

NB : pour l'instant, les fichiers .properties doivent quand même exister (sinon exception, il faut peut-être voir pour améliorer celà dans le patch, mais on aura plus la cause de l'erreur) dans chaque locale "secondaire", mais peuvent être vides.

Pour ton cas, il suffirait de déplacer tes locales en_US dans en_EN. Du coup, dans en_US et en_XX, tu surcharges juste les termes dont tu as besoin, les autres fichiers restent vides.

Il est possible que je modifie encore le patch, parce qu'il faudrait éventuellement que on ne soit pas obligé de créer des fichiers vides pour les variantes de locales.

Il faudrait donc ne pas lancer d'exception, et juste émettre un warning ou notice (ou rien ?)

si la locale est fr_CA et le fichier est pas trouvé, je pense qu'on a peut-être pas besoin de lancer d'exception.

par contre, si la locale est fr_FR, donc générique, et que le fichier n'existe pas, alors il faut lancer l'exception.

Enfin, même si j'ai pas vérifié, je pense qu'il peut y avoir un problème avec la locale par défaut : les erreurs de jelix ne sont que en fr_FR et en_EN. Si par exemple on définit de_DE en locale par défaut, il y a des chances que les erreurs de jelix ne s'affichent plus.

Il faut peut-être imaginer une espèce de "locale de la dernière chance" qui ramène toujours vers en_EN (coté international).

donc le schéma serait plutôt, si tout échoue :

de_AT (autriche) > de_DE (allemagne) > en_EN > exception

bref, je dois encore un peu y penser.

Salut,

comme je le pensais, il y a des problèmes pour gérer les fichiers non existants.

Je regarde pour modifier le patch en conséquence.

Voilà, le bon patch a été posté sur le ticket 95.

Ca fonctionne bien et ça apporte une vraie souplesse dans la gestion des variantes de localisation (fr_CA par rapport à fr_FR par exemple).

doubleface : si jamais tu testes et que tu vois quelque chose qui ne roule pas, n'hésite surtout pas à me remonter l'info.