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