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

[Rodolphe Quiedeville]

Eldy wrote:
> Rodolphe Quiedeville wrote:
>
> > Benoit Mortier wrote:
> >
> > > Le dimanche 12 Septembre 2004 20:30, Benoit Mortier a écrit :
> > >
> > > [..]
> > >
> > >
> > > > > > > Oui mais je ne vois pas pourquoi tu voulais mettre le rowid à 2 pour
> > > > > > > les 2 valeurs.
> > > > > >
> > > > > >
> > > > > >
> > > > > > c'est une erreur qui traine depuis longtemps ;-)
> > > > > >
> > > > > >
> > > > > > > Utilises plutot le système de traduction plutot que de mettre toutes
> > > > > > > les langues dans la table.
> > > > > >
> > > > > >
> > > > > >
> > > > > > malheureusement en blegique nous avons trois langues officielles
> > > > > >
> > > > > > Français, Neerlandais, Allemand ;-)
> > > > > >
> > > > > > donc fr_BE, nl_BE et pour le troisieme je ne sais pas je dois donc
> > > > > > permettre au neerlandophones d'avoir le programme dans leur langue
> > > > > > d'ou la neccessite de nl_BE
> > > > >
> > > > >
> > > > >
> > > > > Oui je comprends bien cela mais je ne comprends pas pourquoi tu veux
> > > > > mettre dans la table des pays les traductions des noms de pays ?
> > > > > La table des pays doit contenir la liste des pays uniquement après on
> > > > > choisit arbitrairement les libellés incluts dans la table et
> > > > > l'affichage se fait par les méthodes d'internationalisation.
> > > >
> > > >
> > > >
> > > > ok je viens de comprendre ;-) je vais donc revenir en arriere et 
> > > > regarder
> > > > du cote de l'internationalisation pour mon cas complexe ;-)
> > >
> > >
> > >
> > >
> > > comme promis je suis revenu en arriere et remis les fichiers en etat ;-)
> >
> >
> >
> > Merci à toi
> >
> >
> >
> > _______________________________________________
> > Dolibarr-dev mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
> 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.
>
> Je sais pas si il faut acter pour une ou l'autre des solutions 
> définitivement. Que ce soit la 1 ou la 2, dans les 2 cas, il faut 
> ajouter un code universel au pays. Ce qui a déjà été fait par l'ajout du 
> champ "code" dans llx_c_pays. Par contre, pour l'étape suivante, il faut 
> trancher. J'ai mis en oeuvre la solution 2 pour les civilités et je 
> partait dessus pour les autres dictionnaires mais je peut m'orienter sur 
> la 1 si il faut.
>
> Qu'en penses-tu Rodolphe ?

Je n'ai pas de préférence particulière seulement le fait que tout code 
tout garder à l'esprit la compatibilité ascendante.

Je pensais aussi à une solution de 2 tables, une avec les codes sur 
lesquels on fait les liens et une deuxième avec les libellés indéxés sur 
le code, lors de la recherche du libellé il suffit d'indiquer au SELECT 
un WHERE contenant le code langue utilisé.

Mais je te laisse seul juge de la meilleure solution étant donné que tu 
as pris en charge l'internationalisation.

Il serait bien que la solution retenue soit dans le wiki ;-)

A++