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

Répondre à