Re: [Dolibarr-dev] Decalage dans table de constante

[Benoit Mortier]

Le mardi 14 Septembre 2004 20:20, Eldy a écrit :

[..]
> Pour ce qui est de l'internationnalisation des tables de dictionnaires,
> le cas est un peu particulier car ces tables ne sont pas 100% statiques
> mais éditables
> par l'utilisateur. La solution, et qui a été appliquée pour le
> dictionnaire des "titres de civilités" par exemple est de rajouter la
> langue en colonne pour pouvoir dupliquer les différentes déclinaisont.
> Ainsi le code "MR" existe en version francaise ou anglaise, ce qui
> permet d'avoir une liste déroulante dans la langue de l'utilisateur et
> l'id stockée dans la base est universel. Mais comme pour les pays, le
> code n'utilise pas encore d'id universel mais le rowid de ligne, cela
> n'est pas encore possible
> de gérer l'internationalisation pour la table des pays. Je pense
> fonctionner sur ce même principe que les civilités mais comme il faut
> rester compatible avec l'existent
> j'avance petit à petit (dictionnaire par dictionnaire) afin de mieux
> maitriser les effets des changements.
> J'ai donc d'abord ajouté la notion de code universel pour le pays dans
> le dictionnaire des pays (FR, IT, ES, ...), mais il faut encore modifier
> le source pour utiliser ce code dans les clés étrangères des pays plutot
> que l'id de ligne et faire le script de migration qui accompagne le
> changement. Une fois cela fait alors seulement, il sera possible de
> mettre des déclinaisons par langues des différents noms de pays. Il y a
> alors 2 solutions:
>
> 1) Soit, comme le suggère Rodolphe, on utilise les fichiers
> d'internationalisation qui auront un équivalent dans chaque langue par
> rapport à ce code, de manière à générer la liste déroulante des pays par
> rapport à la langue utilisateur. Pour le fichier langue français on aura
> IT=Italie et pour le fichier langue anglais on aura IT=Italy  (le
> libellé stocké dans le dictionnaire ne serait alors plus utilisé).
>
> 2) Soit, on applique le même modèle que celui fait pour le dictionnaire
> des civilités qui est lui fontionnel à 100% d'un point de vue
> internationnalisation. Il montre l'exemple de ce que peut être le
> résultat final pour les pays (et autres) si on prend l'option de mettre
> les déclianisons par langue dans la base directement: l'administrateur
> peut editer le dictionnaire de données pour compléter par des éléments
> non standard de dolibarr, et ce dans les langues qui l'intéresse. La
> différence dans cette solution est que les lignes sont déclinées en
> différentes version, une par langue voulue, ce qui permet à
> l'administrateur d'editer les dictionnaires entièrement par les écrans
> sans avoir à rentrer dans les sources ou fichiers langues alors que dans
> la solution 1, l'ajout d'un pays non prévu dans le dictionnaire ne peut
> pas se faire par l'interface d'administration car il faut aussi
> compléter tous les fichiers langues.

moi je suis pour la deuxieme solution qui permettrait a l'utiliseur ou 
administrateur de rajouter directement les donnees dans la database par 
l'interface d'administration, c'est plus "user friendly"

Je vote donc pour la solution 2 ;-)

a+  
-- 
Benoit Mortier
OpenSides sprl
Linux Engineer