évolution interface de traduction

Monde Trad
1

Bonjour,

Voilà le résultat de quelques élucubrations sur une évolution possible
de l'interface de traduction qui tienne compte des nouveaux besoins.

L'interface prend en compte les sources suivantes:
* fichiers interface SPIP (comme actuellement)
* fichiers aide
* fichiers squelettes
* spip_loader

A chacune de ces sources, correspond un fichier de chaines,
respectivement:
* spip_<langue>.php3 pour l'interface (idem actuellement)
* spip_aide_<langue>.php3
* spip_sq_<langue>_id.php3 pour squelette d'identifiant "sq"
* spip_loader_<langue>.php3

Le script "spip_gen.php3" tient compte des nouvelles sources. Le type
de source est entré par l'utilisateur au moment de l'exécution du
script.

Développements d'une fonction spécifique identique à "_T" par type de
source (respectivement _A, _S, _L) pour la récupération des chaines.

Modifications sur l'interface de traductions :
- rendre l'interface directement accessible depuis la page "ecrire" du
site "trad_spip" (ça facilitera grandement l'accès à la page).
- possibilité d'appeler "spip_gen" depuis la page de garde de la
traduction (ne le rendre utilisable qu'aux admins ?).
- choix du type de source dans la page "Traductions"
- prise en compte des nouvelles sources dans la page "Bilan"

Difficultés:

1 - source aide: ce fichier peut-être traité de manière
quasi-automatique (à condition d'accepter que les champs HTML soient
laissés dans les chaines à traduire, et qu'ils soient correctement
traités par les traducteurs). Dans ce cas, il faut aussi admettre qu'on
ne manipule plus le fichier aide à la main (car il deviendra un un truc
du genre succession de tags _A("a_1"), _A("a_2"), ...). Humm, pas
fameux.

2 - squelettes: où localiser les fichiers de traduction ? Comment
définir des identifiants de squelettes ? (une instance SPIP
d'attribution des identifiants ? :slight_smile:

3 - localisation des chaines à partir de l'interface de traduction
(demandé par Klaus) : difficle.

Voilà.. Qu'en pensez-vouz ?
Florent

2

Voilà le résultat de quelques élucubrations sur une évolution possible
de l'interface de traduction qui tienne compte des nouveaux besoins.

L'interface prend en compte les sources suivantes:
* fichiers interface SPIP (comme actuellement)
* fichiers aide
* fichiers squelettes
* spip_loader

Je crois que tu oublies les autres sources à venir : modules, le script de
trad lui-même, et d'autres projets en php qui, rapidement, vont vouloir
utiliser ton script et la librairie inc_lang.php3... :wink:

Le script "spip_gen.php3" tient compte des nouvelles sources. Le type
de source est entré par l'utilisateur au moment de l'exécution du
script.

spip_gen était utile au début, mais maintenant ?? personnellement quand je
code une nouvelle fonctionnalité, s'il y a une ou deux chaînes je les mets à
la main dans spip_fr.php3 et hop.

Développements d'une fonction spécifique identique à "_T" par type de
source (respectivement _A, _S, _L) pour la récupération des chaines.

Est-ce que ces sources sont fondamentalement différentes ? Pour moi il
existe deux types différents : les scripts php, d'un côté, les pages HTML de
l'autre. Comment dire qu'on est dans tel ou tel fichier de langue... ça peut
passer par une globale, par exemple, plutôt que par l'accumulation de
fonctions au fond pas si différentes.

Modifications sur l'interface de traductions :
- rendre l'interface directement accessible depuis la page "ecrire" du
site "trad_spip" (ça facilitera grandement l'accès à la page).

Oui

- possibilité d'appeler "spip_gen" depuis la page de garde de la
traduction (ne le rendre utilisable qu'aux admins ?).
- choix du type de source dans la page "Traductions"
- prise en compte des nouvelles sources dans la page "Bilan"

Difficultés:

1 - source aide: ce fichier peut-être traité de manière
quasi-automatique (à condition d'accepter que les champs HTML soient
laissés dans les chaines à traduire, et qu'ils soient correctement
traités par les traducteurs). Dans ce cas, il faut aussi admettre qu'on
ne manipule plus le fichier aide à la main (car il deviendra un un truc
du genre succession de tags _A("a_1"), _A("a_2"), ...). Humm, pas
fameux.

Oui, c'est un peu le problème ; en même temps le "fichier d'aide" n'existe
plus vraiment, il est simplement remplacé par un "fichier de langue d'aide",
dans lequel chaque chaîne correpond à une rubrique de l'aide. Et ce fichier
là est éditable exactement comme l'est actuellement le fichier "aide".
Simplement il faut mettre des \ devant les '.

2 - squelettes: où localiser les fichiers de traduction ? Comment
définir des identifiants de squelettes ? (une instance SPIP
d'attribution des identifiants ? :slight_smile:

La grosse difficulté, c'est qu'on va avoir un niveau d'abstraction de plus
sur ce que le webmestre spipiste débutant est censé prendre en mains. Et ça,
c'est vraiment pas la philosophie SPIP. Il faudra peut-être se résoudre à
faire des squelettes sans texte - ou au contraire générer des squelettes
dans chaque langue à partir d'une base commune et de fichiers de langue...
mais alors le poids de l'archive va encore exploser :wink:

3 - localisation des chaines à partir de l'interface de traduction
(demandé par Klaus) : difficle.

Une solution serait de hacker ça vite-fait en shell : `grep -l "machaine" *3
ecrire/*3` ; en faisant bien attention aux problèmes de sécurité.

-- Fil

3

Salut,

Mon avis aussi...

A chacune de ces sources, correspond un fichier de chaines,
respectivement:
* spip_<langue>.php3 pour l'interface (idem actuellement)
* spip_aide_<langue>.php3

Je trouve que le fichier d'aide devrait rester tel qu'il est,
c'est beaucoup plus facile à étendre. Je me vois mal écrire
deux pages de texte dans une chaîne PHP...

* spip_sq_<langue>_id.php3 pour squelette d'identifiant "sq"

Pour l'instant on ne sait pas quoi faire pour la traduction
des squelettes. Le mieux serait que chaque équipe de traduction
fasse son propre jeu de squelettes, soit en reprenant les
squelettes français, soit en faisant jouer leur créativité.
Le code est du HTML, je ne pense pas qu'une interface soit
nécessaire. Enfin on ne sait pas comment les distribuer.

* spip_loader_<langue>.php3

A priori je serais plutôt pour un spip_loader contenant toutes
les langues, mais c'est à discuter.

3 - localisation des chaines à partir de l'interface de traduction
(demandé par Klaus) : difficle.

Heu, je ne comprends pas de quoi tu parles...

a+

Antoine.

4

Le jeu 05/06/2003 à 23:25, Fil a écrit :

Je crois que tu oublies les autres sources à venir : modules, le script de
trad lui-même, et d'autres projets en php qui, rapidement, vont vouloir
utiliser ton script et la librairie inc_lang.php3... :wink:

Il me semble que pour faire un truc vraiment générique et utilisable par
d'autres, il faudrait utiliser les fonctions liées à 'gettext', quitte à
redévelopper la fonction 'gettext' en php pour la rendre utilisable sur
les plateformes où elle n'est pas dans l'environnement. Bon, ça me
semble un peu compliqué, et à partir de là, il vaut mieux coller de près
aux besoins propres à SPIP sans se poser de questions sur une
réutilisation éventuelle. C'était un peu comme ça que j'envisageais les
choses.

Le ven 06/06/2003 à 00:34, Antoine a écrit :

Je trouve que le fichier d'aide devrait rester tel qu'il est,
c'est beaucoup plus facile à étendre. Je me vois mal écrire
deux pages de texte dans une chaîne PHP...

A mon sens, et participant à la traduction, le fichier 'aide' est ce qui
reste de plus ennuyeux à gérer pour les traducteurs (surtout maintenant
où il ne faudra plus gérer ça que de manière ponctuelle). Par exemple,
le dernier ajout que tu as fait dans le fichier n'a pas encore, à ma
connaissance, été intégré dans la traduction en esperanto, car j'ai eu
la flemme d'aller extraire la partie en question du fichier. S'il
y'avait eu une interface comme pour les chaines, j'aurais pu récupérer
directement la partie, travailler dessus et elle aurait été intégrée
directement dans la traduction.. et ça deviendra de plus en plus vrai au
fur et à mesure que les traducteurs ne suivront plus les évolutions au
jour le jour.

N'est-il pas envisageable de transformer le fichier 'aide' en un truc du
genre :

--------------------------
Array ...

00100_section="<erreur_mysql>",

00200_titre = "{{{CXu grava eraro pri skeleto?}}}",

00300_par = "Kiam SPIP alfrontas eraron en sia komunikado kun la
MySQL-datenbazo, gxi afisxas sur la ekrano la malsukcesan
operacion kaj ankaux la erarmesagxon elsenditan de la datenbazo
(rugxe).",

00400_par = "La problemo povas deveni:
- aux de eraro en la difino de via skeleto, se vi estas modifanta vian
retpagxon;
- aux de paneo de la datenbazo.",

00500_par = "Ekzemple, mesagxo de la tipo <font color='red'><b>
_ <code>> Unknown column 'articles.chapi' in 'where clause'</code>
</b></font>
signas ke la masxo alvokas selekto-kriterion (<code>chapi</code>) ne
antauxviditan.",

...
--------------------------

... cela resterait assez facilement extensible pour le programmeur, et
en même temps, cela permettrait de traiter le fichier avec l'interface
de traduction.

Florent

5

Salut Florent,

A mon sens, et participant à la traduction, le fichier 'aide' est ce qui
reste de plus ennuyeux à gérer pour les traducteurs (surtout maintenant
où il ne faudra plus gérer ça que de manière ponctuelle). Par exemple,
le dernier ajout que tu as fait dans le fichier n'a pas encore, à ma
connaissance, été intégré dans la traduction en esperanto, car j'ai eu
la flemme d'aller extraire la partie en question du fichier. S'il
y'avait eu une interface comme pour les chaines, j'aurais pu récupérer
directement la partie, travailler dessus et elle aurait été intégrée
directement dans la traduction.. et ça deviendra de plus en plus vrai au
fur et à mesure que les traducteurs ne suivront plus les évolutions au
jour le jour.

N'est-il pas envisageable de transformer le fichier 'aide' en un truc du
genre :

[snip]

Je ne comprends même pas comment fonctionne ta proposition.
Désolé, mais le pseudo-XML est ce qu'on a trouvé de mieux
pour éditer la doc. Il faut peut-être un système de diff
pour comparer avec les anciennes versions (*), afin que les
traducteurs trouvent les nouveautés et changements plus
facilement (en ajoutant des tags <NEW> et <CHANGED> par
exemple). Mais remplacer le XML par un gloubiboulga en PHP
avec une structure cryptique, non :wink: Ce serait passer du
Moyen-Age à la préhistoire.

En outre je ne crois pas que traduire la doc comme un
ensemble de paragraphes indépendants soit très commode
(il faut sans cesse reconstruire le contexte).

(*) Note : des diffs "bruts" sont dispos sur spip-commit,
et consultables sur le cvs-web... pas très commode je sais.

a+

Antoine.

6

Salut Antoine,

Je ne comprends même pas comment fonctionne ta proposition.

?? Exactement comme les fichiers langues actuels. Lorsque tu ajoutes un
paragraphe, il est automatiquement marqué en <NEW> dans l'interface de
traduction.

Désolé, mais le pseudo-XML est ce qu'on a trouvé de mieux
pour éditer la doc. Il faut peut-être un système de diff
pour comparer avec les anciennes versions (*), afin que les
traducteurs trouvent les nouveautés et changements plus
facilement (en ajoutant des tags <NEW> et <CHANGED> par
exemple). Mais remplacer le XML par un gloubiboulga en PHP
avec une structure cryptique, non :wink: Ce serait passer du
Moyen-Age à la préhistoire.

Le fichier d'aide actuel n'est pas pratique pour les traducteurs. Aller
éditer le fichier à la main, on fait mieux, surtout si plusieurs
personnes travaillent ensemble sur le fichier. Personnellement, je sais
que les efforts que j'ai fait pour fabriquer le fichier aide en eo, à
partir de 3 sources différentes, ont été assez intenses (j'ai bien dû
passer une demi journée rien que pour la mise en forme du fichier). Et
je ne sais pas si dans 3 mois, s'il y a des nouveaux paragraphes à
traduire, je serais prêt à passer 1/2 journée encore pour récupérer le
fichier, faire les diffs, éditer, traduire, renvoyer le fichier pour
contrôle aux autres traducteurs, etc. D'autre part, l'interface de
traduction permet de savoir exactement où on en est par rapport aux
traductions.

Bon, je faisais juste une proposition pour essayer d'automatiser le
machin, en partant de mon expérience personnelle de traducteur, mais tu
as sûrement plus de retour que moi sur la pertinence de passer du temps
à ça. La solution "gloubiboudesque" que je proposais avait l'avantage de
fonctionner exactement comme ce qui existe actuellement pour les autres
chaines, dont facilement intégrable.

Florent

7

?? Exactement comme les fichiers langues actuels. Lorsque tu ajoutes un
paragraphe, il est automatiquement marqué en <NEW> dans l'interface de
traduction.

Non, je parlais de tes 00100_section, etc. C'est quoi ce bazar ? :o

Le fichier d'aide actuel n'est pas pratique pour les traducteurs. Aller
éditer le fichier à la main, on fait mieux, surtout si plusieurs
personnes travaillent ensemble sur le fichier.

C'est pour ça qu'une passerelle XML -> trad_spip serait souhaitable.
Mais, pitié, laissons le fichier original au format XML....

8

Le mar 10/06/2003 à 14:36, Antoine a écrit :

> ?? Exactement comme les fichiers langues actuels. Lorsque tu ajoutes un
> paragraphe, il est automatiquement marqué en <NEW> dans l'interface de
> traduction.

Non, je parlais de tes 00100_section, etc. C'est quoi ce bazar ? :o

C'est pour laisser les chaines dans l'ordre du fichier (je ne sais pas
si on peut sauvegarder une array non triée en php ?).

> Le fichier d'aide actuel n'est pas pratique pour les traducteurs. Aller
> éditer le fichier à la main, on fait mieux, surtout si plusieurs
> personnes travaillent ensemble sur le fichier.

C'est pour ça qu'une passerelle XML -> trad_spip serait souhaitable.
Mais, pitié, laissons le fichier original au format XML....

Ok, il me semble qu'il y a deux options :

- soit le fichier est interprété à chaque clic de souris dans
l'interface. Ca risque d'être un peu lourd.

- soit le fichier est traduit en un bloc, au début du travail, mais
dans ce cas, il faut penser à le repasser au format "XML" à la fin du
travail.

Florent