Re: [Galette-devel] Re: [Galette-cvs] ended with gettext i18n

[Deelight <deelight@xxxxxxxxxx>]

Georges Khaznadar a écrit :
> > Est-ce qu'on pourrait envisager de conserver les deux méthodes de 
> > localisation : gettext() et une autre qui extrairait les messages des 
> > .po pour les déclarer en global (ou autre méthode) ? Je pense surtout 
> > aux personnes qui n'ont pas compilé php avec le support gettext et 
> > notamment aux hébergeurs (qui n'auront en plus pas forcément les bonnes 
> > locales). Ce pourrait etre un parametre dans l'interface d'admin 
> > (localisation method : gettext / oldschool). Qu'en pensez-vous (et 
> > surtout toi Georges vu le boulot que tu as effectué a dessus !).
>
> Il y a peu de différence dans le code entre les deux approches : faut
> voir si on peut redéfinir la fonction _() dans une source PHP.

Salut,

En fait, c'est un peu pour cette raison que j'avais defini une fonction 
_T() pour la traduction. On peut tout à fait se débrouiller pour que 
_T() fasse appel à _() pour la traduction gettext. De plus, il était 
assez simple d'indiquer à xgettext qu'il devait isoler les chaines 
encapsulées dans _T() plutot que _().

> Chacune des méthodes a ses avantages :
>
> - la méthode du tableau des traductions est portable même sans gettext
>
> - la méthode avec gettext hérite des fonctionnalités de cette suite gnu :
>   facilité de générer automatiquement la table des chaînes à traduire à
>   chaque évolution du code, répartition automatique dans les fichiers
>   .po, mode po d'emacs qui permet d'aller droit à l'essentiel, et de
>   visualiser les sources en regard des traductions en cas de doute,
>   récupération de dictionnaire flous.

En effet, je suis tout à fait d'accord avec toi concernant les avantages 
de gettext et c'est pour cette raison que je comptais éventuellement 
utiliser les fichier .po meme lorsque l'on n'utilise pas gettext. Ca 
permettrait surtout de faire un traduction unique, sans aucune redondance.

> Pour moi l'inconvénient principal de gettext c'est le pivot en anglais
> obligatoire (l'algorithme actuel de gettext refuse de prendre en
> considération un pivot qui n'est pas en ascii).

Personellement ça ne me dérange pas de coder directement en anglais, 
mais il est vrai qu'il vaut mieux etre sur du terme dés le départ car il 
me semble que si l'on fait une modif sur une chaine en anglais, il faut 
recreer tous les .po et .mo. Ceci dit, ce n'est pas vraiment genant.

> Ce que nous pouvons faire, c'est une fourche dans le développement (cvs
> tab -b), mais à mon avis pour que les développements ne soient pas trop
> incompatibles, il faudra conserver des messages en anglais dans la
> source. Je peux recoder les tables lang[] pour que la référence soit en
> anglais plutôt qu'en français de façon automatique.
>
> Qu'en penses-tu ?

Je pense qu'il faut laisser les messages en anglais dans le source et 
peut etre ramplacer les appels à _() par _T() et redéfinir la fonction 
_T() (lang.inc.php) pour que dans un premier temps, elle passe 
simplement le relai à _().

Je vais ensuite étudier la possibilité de déclarer les tables lang[] par 
lecture directe du .po. Si j'arrive a quelquechose de fonctionnel, il 
suffira de rajouter le choix de la methode de localisation dans la page 
de préférences, et tenir compte de ce reglage dans la fonction _T().

A ton tour, qu'en penses-tu ? ;)

Frédéric