Deelight a écrit : > Salut, > > 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. 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. 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). 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 ? amitiés, Georges.
Attachment:
signature.asc
Description: Digital signature
Generated by mhonarc 2.6.10, Sun Aug 08 20:00:04 2004