Re: [Dolibarr-dev] Dolibarr multi-langues

[Christophe Combelles]

Je pense que le plus important pour un système multilingue est de faciliter la 
vie des traducteurs. Un traducteur n'a pas forcément de compétence informatique, 
et doit pouvoir travailler le plus facilement possible.

Un autre élément important est que le système doit assurer au maximum la 
cohésion entre les traductions, et il doit faciliter la répercussion des 
modifications de la langue de référence sur les traductions.

Pour ces deux points gettext n'est-il pas plus approprié ?

Par exemple tout va plus vite avec des outils comme kbabel,
et j'aime bien le principe des "fuzzy" lorsqu'une traduction doit être revue.


Christophe

Eldy a écrit :
> Dolibarr multi-langues
>
> J'ai commencé le système de traduction dolibarr en autres langues. Avant 
> d'aller plus loin, j'aimerais qu'on statut sur le procédé.
>
> Il y avait 3 solutions pour gérer les langues:
>
> - Solution 1: Utilisation de gettext. Fonction incluse dans php mais : 
> Pas en standard, ne fonctionne pas toujours et même très mal sur windows,
> est surtout oriénté 1 fichier de traduction par appli donc destiné à des 
> petites applis textes en général. Le fichier de traduction doit etre du 
> type /usr/share/locale/LC_MESSAGE_fr/monfichier.mo, qui n'est pas texte 
> mais binaire, ce qui rend la maintenance peu pratique. Pour ces raisons 
> j'ai exclus le principe de gettext pas génial pour une appli web
>
> - Solution 2: Celle en vigueur actuellement. Une classe de traduction 
> charge le fichier de traduction selon la langue choisit dans la 
> configuration IHM. La traduction est prise par rapport au texte en 
> français. Dans une page on a $lang->trans("Ma chaine a traduire") 
> Avantage, pas de fichier français a maintenir, inconvénient les 
> correspondances des autres langues se font par rapport à un texte en 
> français
> en dur dans le code et reporté dans le fichiers des autres langues. Si 
> on change le texte en francais, il faut changer les fichiers de traduction.
>
> - Solution 3: Et j'hésite à partir sur celle la en remplacement de la 2, 
> on utilise la meme classe mais au lieu de mettre en paramètres à la 
> methode trans la chaine en français ("Ma chaine a traduire") au sein des 
> pages, on mettrait cette meme methode mais avec un code texte par 
> exemple $lang->trans("MYSTRING1"). On aurait alors dans le fichier 
> anglais la correspondance de
> MYSTRING1 <-> Chaine en anglais
> et dans le fichier francais
> MYSTRING1 <-> Chaine en francais
>
> L'inconvénient est qu'il faut compléter le fichier francais en meme 
> temps que les autres au fur et a mesure que l'on remplace le chaine en 
> dur dans le pages php par la methode de traduction 
> trans("CHAINEGENERIQUE"), mais toute traduction meme français peut 
> évoluer sans impact sur le code ni sur les autres langues.
>
> Cette solution 3 a ma préférence car elle est plus propre. La question 
> est, si on part sur la 3, faut-il mettre des codes génériques aux 
> chaines à traduire qui sont des termes anglais (exemple "CONFIRMDELETE") 
> ou en francais (exemple "CONFIRMATIONSUPPR").