voici un nouveau patch à tester pour l'internationalisation : elle
fonctionne sans gettext parce que c'est plus pratique, supporte les même
fichier binaires que gettext. On reste compatible à 100% avec gettext,
tout en supportant les apaches qui ne supportent pas gettext.
Sont fournis:
. l'include inc_gettext.php3 qui contient la routine d'initialisation et
la fonction de traduction _T(...
. l'arbo qui permet de stocker les fichiers gettext
. un version modifée de inc_presentation qui permet de voir l'admin, un
peu en Anglais.
le TAR.GZ est à dézipper dans spip/ et pas dans ecrire/ !!!
Je suis en train de travailler à la substitution des variables dans _T
et la seule chose à peu près potable que j'ai trouvé consiste à faire
une solution à la printf:
_T("Bienvenue %1 %2,",$civilite, $nom);
Sinon, je ne vois pas trop comment faire simplement... Si vous avez des
idées, je suis preneur, bien évidemment...
Pas très parlant pour un traducteur qui ne saura pas forcément ce qui
doit remplacer %1 et %2. La solution d'Antoine est un peu plus complexe
mais donne des phrases à traduire plus claires :
_T("@nom a @age@ ans", array('nom' => "Antoine",'age' => "5"));
En terme de rapidité d'execution ça ne doit pas trop ralentir imho.
En terme de programmation c'est peut-être plus facile à coder, et y'aura
pas l'effet de bord d'un improbable mais éventuel "%10" avec la première
solution.
Système retenu dans PEAR, même si je ne veux pas vous laisser croire
que je suis un évangéliste de PEAR ...
Pas très parlant pour un traducteur qui ne saura pas forcément ce
qui doit remplacer %1 et %2.
En effet.
La solution d'Antoine est un peu plus complexe mais donne des
phrases à traduire plus claires :
_T("@nom a @age@ ans", array('nom' => "Antoine",'age' => "5"));
Et bien non, justement, ce n'est pas plus simple, car comment un
traducteur qui ne parle pas français saura t'il mieux ce que signifie
ce @nom@ ?
Le %1 a le "mérite" d'être obscur de la même façon pour tout le
monde !
Je suis en train de travailler à la substitution des variables dans _T
et la seule chose à peu près potable que j'ai trouvé consiste à faire
une solution à la printf:
Sont fournis:
. l'include inc_gettext.php3 qui contient la routine d'initialisation et
la fonction de traduction _T(...
. l'arbo qui permet de stocker les fichiers gettext
. un version modifée de inc_presentation qui permet de voir l'admin, un
peu en Anglais.
Excellent : voilà déjà une première correction pour que ça fonctionne dans
l'espace public (page de login)...
function lire_i18n($lang)
{
+ global $dir_ecrire;
global $tstring;
// opens a mo file
- $fd = fopen( "locale/$lang/spip.mo", "r" );
+ $fd = fopen( $dir_ecrire."locale/$lang/spip.mo", "r" );
> La solution d'Antoine est un peu plus complexe mais donne des
> phrases à traduire plus claires :
> _T("@nom a @age@ ans", array('nom' => "Antoine",'age' => "5"));
Et bien non, justement, ce n'est pas plus simple, car comment un
traducteur qui ne parle pas français saura t'il mieux ce que signifie
ce @nom@ ?
Parce que, patate, ce sera @name@ et non pas @nom@ (et n'importe
quel traducteur digne de ce nom comprend suffisamment d'anglais
pour ne pas être perdu !).
voici un nouveau patch à tester pour l'internationalisation : elle
fonctionne sans gettext parce que c'est plus pratique, supporte les même
fichier binaires que gettext. On reste compatible à 100% avec gettext,
tout en supportant les apaches qui ne supportent pas gettext.
Sont fournis:
. l'include inc_gettext.php3 qui contient la routine d'initialisation et
la fonction de traduction _T(...
. l'arbo qui permet de stocker les fichiers gettext
Heu, c'est idiot d'utiliser gettext si c'est pour réécrire
les routines à la main. Autant utiliser un format adapté.
J'ajoute que ce serait bien que les traducteurs puissent tester leur
traduction sans avoir à lancer un Makefile ou un machin en ligne de
commande Unix
Heu, c'est idiot d'utiliser gettext si c'est pour réécrire
les routines à la main. Autant utiliser un format adapté.
Ca se discute.
J'ajoute que ce serait bien que les traducteurs puissent tester leur
traduction sans avoir à lancer un Makefile ou un machin en ligne de
commande Unix
Il suffirait de comparer la date des deux fichiers, et de prendre le compilé
s'il est plus récent que l'autre ? (Bon, usine à gaz, mais puisque c'est
Pierre qui code... ouf !)
> Désolé d'être idiot, mais le format gettext est à mon avis pas loin
> d'être optimal : il est binaire (c'est son point fort et faible)
Optimal pour quoi ? On est en PHP, pas en C/C++.
Ce qui est optimal pour PHP, c'est le code PHP, qu'on peut
inclure dynamiquement par include("...").
Bien. il n'y a plus qu'a écrire un outil d'extraction des chaines du
code php, puis écrire une norme pour les noms des symboles et puis on
pourra commencer à traduire SPIP.
> Sinon, il faut soit réécrire xgettext, soit parser les .po à la main
> (c'est ce que fait Squirrellmail par exemple, je trouve ça immonde),
Parser les .mo à la main en PHP, c'est pas immonde peut-être ?
Personnellement, je trouve cette solution plutot élégante. Mais je ne
suis pas un bon développeur PHP de toute façons En plus, tu
conviendras surement que faire des ereg_machins sur les lignes du .po
pour construire les tableaux associatifs est au moins aussi pire.
Bien. il n'y a plus qu'a écrire un outil d'extraction des chaines du
code php, puis écrire une norme pour les noms des symboles et puis on
pourra commencer à traduire SPIP.
Pour l'extraction, on doit pouvoir s'appuyer sur xgettext, quitte à en
parser le résultat pour le mettre à notre sauce ?
> Bien. il n'y a plus qu'a écrire un outil d'extraction des chaines du
> code php, puis écrire une norme pour les noms des symboles et puis on
> pourra commencer à traduire SPIP.
Pour l'extraction, on doit pouvoir s'appuyer sur xgettext, quitte à en
parser le résultat pour le mettre à notre sauce ?
Cela me paraît la meilleure solution. Quelques bémol cependant: xgettext
ne supporte pas les chaines multi-ligne, ce qui impose:
. soit de regrouper les longs textes en une seule et même ligne :
solution plus sympathique pour les traducteurs (il n'y a qu'une seule
longue chaine à traduire)
. soit couper ces chaines en morceaux et accepter d'avoir plusieurs
morceaux de phrases en vrac dans le .po généré (xgettext retrie les
chaines par ordre alphabétique avant d'écrire le .po sur le disque).
Qu'en pensez-vous ?
Je suis plutot partisan de la première méthode, même si elle "salit" un
peu certaines parties du code.
Quant à la nomenclature que l'on pourrait employer pour nommer les
chaînes, je n'ai aucune point de départ.
En plus, tu