[spip-dev] script de gestion de traductions

Dev
1

Bonjour,

Je commence à travailler sur un script qui permet de gérer les
traductions. Les "spécifications" sont les suivantes :

- 1ere page : saisie de la langue origine + langue cible + charsets
associés à chacune des langues

- 2e page : affichage de la liste des identifiants _T ; les identifiants
peuvent avoir les status suivants :
  * non traduit : l'id est présent dans le fichier langue origine et pas
dans le fichier langue cible.
  * traduit : l'id est présent dans les deux fichiers langues
  * conflit : l'id est présent dans le fichier langue cible mais pas dans
le fichier langue origine.

- 3e page, traduction pour un identifiant _T sélectionné en page 2.
Deux frames, chaque frame a le charset correspondant à celui de la langue :
  * frame du haut = message dans la langue origine (peut être vide)
  * frame du bas = message dans la langue cible (peut être vide)

Questions :
- êtes-vous d'accord avec ce fonctionnement ? ce script est-il utile ?
- est-il utile de faire la manip sur les charsets ?
- pour avoir le fonctionnement ci-dessus, il faut modifier le script
"gen_lang" de telle sorte qu'il n'écrive que dans le fichier langue de la
langue origine (et non pas dans tous les fichiers langues comme c'est le
cas actuellement)
- par ailleurs, je propose de mettre tout ce qui concerne la langue dans
le répertoire 'lang' : fichiers langues + scripts associés ('gen_lang' +
nouveau script 'trad_lang').

Florent

2

- 1ere page : saisie de la langue origine + langue cible + charsets
associés à chacune des langues

Pour le charset, il faut que tout soit en 7bits, l'arabe, le russe ou le
japonais seront donc codés avec des ֜ etc., ce qui sera illisible...
sauf à travers le browser et ton script de traduction :wink:

Déjà le français est codé en é ou è (cas de "Nouvelle brève")

- 2e page : affichage de la liste des identifiants _T ; les identifiants
peuvent avoir les status suivants :
  * non traduit : l'id est présent dans le fichier langue origine et pas
dans le fichier langue cible.
  * traduit : l'id est présent dans les deux fichiers langues
  * conflit : l'id est présent dans le fichier langue cible mais pas dans
le fichier langue origine.

Me paraît bien

- 3e page, traduction pour un identifiant _T sélectionné en page 2.
Deux frames, chaque frame a le charset correspondant à celui de la langue :
  * frame du haut = message dans la langue origine (peut être vide)
  * frame du bas = message dans la langue cible (peut être vide)

OK

Questions :
- êtes-vous d'accord avec ce fonctionnement ? ce script est-il utile ?
- est-il utile de faire la manip sur les charsets ?

Non

- pour avoir le fonctionnement ci-dessus, il faut modifier le script
"gen_lang" de telle sorte qu'il n'écrive que dans le fichier langue de la
langue origine (et non pas dans tous les fichiers langues comme c'est le
cas actuellement)

Le gen_lang actuel marque <NEW> en début des chaînes nontraduites, il suffit
donc que ton script repère <NEW>... c'est plus facile à détecter si on
traduit sans ton interface.

- par ailleurs, je propose de mettre tout ce qui concerne la langue dans
le répertoire 'lang' : fichiers langues + scripts associés ('gen_lang' +
nouveau script 'trad_lang').

C'est actuellement dans le répertoire CVS spip_gen , car on n'a pas besoin
de le distribuer avec SPIP (d'autant que, comme ça nécessite des droits
particuliers sur les fichiers à traduire, il vaut mieux ne pas l'utiliser
sur son site de prod). A mon avis, et sauf argument contraire, il vaut mieux
laisser en l'état.

-- Fil

3

Pour le charset, il faut que tout soit en 7bits, l'arabe, le russe ou le
japonais seront donc codés avec des &#1436; etc., ce qui sera
illisible... sauf à travers le browser et ton script de traduction :wink:

ok, le 7bits, c'est l'UTF-8 ?

- 3e page, traduction pour un identifiant _T sélectionné en page 2.
Deux frames, chaque frame a le charset correspondant à celui de la
langue :
  * frame du haut = message dans la langue origine (peut être vide) *
  frame du bas = message dans la langue cible (peut être vide)

OK

si pas de manipulation du charset, ce n'est pas la peine de faire cela
sous forme de frame HTML alors.

Le gen_lang actuel marque <NEW> en début des chaînes nontraduites, il
suffit donc que ton script repère <NEW>... c'est plus facile à détecter
si on traduit sans ton interface.

ok, j'avais pas vu cette caractéristique.

C'est actuellement dans le répertoire CVS spip_gen , car on n'a pas
besoin de le distribuer avec SPIP (d'autant que, comme ça nécessite des
droits particuliers sur les fichiers à traduire, il vaut mieux ne pas
l'utiliser sur son site de prod). A mon avis, et sauf argument
contraire, il vaut mieux laisser en l'état.

d'accord, c'est plus prudent.

Florent

4

> japonais seront donc codés avec des &#1436; etc., ce qui sera
> illisible... sauf à travers le browser et ton script de traduction :wink:
ok, le 7bits, c'est l'UTF-8 ?

Non. Quelques explications là:
http://www.uzine.net/article1785.html

si pas de manipulation du charset, ce n'est pas la peine de faire cela
sous forme de frame HTML alors.

Si, justement : à l'écran s'affichent les caractères cyrilliques, mais dans
le fichier tu répcupères &#1254; (à condition que tu indiques au browser que
ta page a pour charset iso-8859-1, et pas utf-8).

-- Fil

5

Si, justement : à l'écran s'affichent les caractères cyrilliques, mais
dans
le fichier tu répcupères &#1254; (à condition que tu indiques au browser
que
ta page a pour charset iso-8859-1, et pas utf-8).

Ben non : tu mets la page en UTF-8, et tu convertis les caractères > 127
en entités numériques.

Ceci dit, je trouve ça franchement moyen de tout coder avec des entités
numériques, ce serait beaucoup plus propre en utilisant des charset.
Sinon il faut aussi prévoir une interface pour _modifier_ (pas traduire)
les textes. De plus il y aura des problèmes pour les textes des mails
(tous les mailers n'acceptent pas l'UTF-8, et on ne veut pas faire de
mails HTML).

6

Ben non : tu mets la page en UTF-8, et tu convertis les caractères > 127
en entités numériques.

Ca revient au même.

Ceci dit, je trouve ça franchement moyen de tout coder avec des entités
numériques, ce serait beaucoup plus propre en utilisant des charset.

Pas sûr, car si le charset du site et le charset de la langue demandée ne
sont pas les mêmes comment fait-on ? L'avantage du codage unicode &#xxx;
c'est de passer dans tous les charsets justement. A moins de traduire à la
volée dans _T(), ce qui est une autre possibilité. A ce moment-là on fait les
fichiers spip_xx.php3 en utf-8... mais on casse notre fonctionnement
présent, qui justement n'a pas d'accents pour éviter les problèmes de ftp
Macintosh. Bref, je maintiens mon idée des &#xxx; sauf si vous trouvez des
arguments plus convaincants...

Sinon il faut aussi prévoir une interface pour _modifier_ (pas traduire)

ouaip

les textes. De plus il y aura des problèmes pour les textes des mails
(tous les mailers n'acceptent pas l'UTF-8, et on ne veut pas faire de
mails HTML).

Il faudra peut-être changer notre fusil d'épaule pour les écritures
non-isolatines.

-- Fil

7

si je comprends bien, la possibilité de modifier le charset n'est utilisée que
pour effectuer un contrôle sur le contenu réel des fichiers langues.
C'est ça ?

8

Ben non : tu mets la page en UTF-8, et tu convertis les caractères > 127
en entités numériques.

Ca revient au même.

Oui mais ça évite les frames, c'est toujours ça de pris.

Il faudra peut-être changer notre fusil d'épaule pour les écritures
non-isolatines.

Ou forcer en UTF-8, faute d'une solution plus satisfaisante.
Surtout que même un mail en HTML est censé avoir un équivalent
"texte" encapsulé en MIME.

9

Oui mais ça évite les frames, c'est toujours ça de pris.

Ah, OK,... c'est qu'un outil de trad, hein, ça peut avoir des frames...

> Il faudra peut-être changer notre fusil d'épaule pour les écritures
> non-isolatines.

Ou forcer en UTF-8, faute d'une solution plus satisfaisante.
Surtout que même un mail en HTML est censé avoir un équivalent
"texte" encapsulé en MIME.

Si ton mailer sait lire l'utf-8, il serait fort étonnant qu'il ne sache pas
lire le HTML. La question se pose pour les autres charsets, souvent lus par
de vieux mailers japonais ou quoi... m'enfin, sur cette question je suis
agnostique, après avoir été longtemps pratiquant du mail TXT maintenant ça
m'est égal.

-- Fil

10

si je comprends bien, la possibilité de modifier le charset n'est utilisée
que pour effectuer un contrôle sur le contenu réel des fichiers langues.

Je n'ai pas compris la question :wink:

En gros, si tu précises dans ta page de formulaire un codage, le navigateur
lit ta page dans ce codage et renvoie des données dans ce codage. Donc, si
tu indiques "iso-8851-1", et que tu tapes du japonais, le navigateur va
passer le japonais en iso-8859-1, via le système de &#xxx;

Si, au contraire, tu lui passes le codage utf-8, le navigateur va t'envoyer
de l'utf-8.

-- Fil

11

.. je ne vois pas où est le problème alors ? Si tout est affiché dans un
seul frame, que tout est codé en &#xxx, tout s'affichera correctement et
le traducteur pourra aussi saisir des traductions qui seront correctement
envoyés (en &#xxx) vers le script. Il y a un truc que j'ai loupé là.

12

.. je ne vois pas où est le problème alors ? Si tout est affiché dans un
seul frame, que tout est codé en &#xxx, tout s'affichera correctement et
le traducteur pourra aussi saisir des traductions qui seront correctement
envoyés (en &#xxx) vers le script. Il y a un truc que j'ai loupé là.

Euh, non, c'est bon, je crois qu'on se comprend et que nous sommes d'accord
:wink: En gros, le débat avec Antoine porte plus sur le charset de référence des
fichiers de langue (utf-8 ou 7bits) que sur la manière de faire le script de
trad.

A mon sens il faut continuer à ce que le code de SPIP soit crit en 7 bits (à
l'exception des images, bien entendu), quitte à faire que les fichiers de
langues non iso-latines ne soient pas directement lisibles en mode texte
(ie, il faudra un script qui les affiche via un brouteur HTML).

-- Fil

13

tant qu'on ne travaille que sur des fichiers livrés avec SPIP,
il sera toujours possible de faire les conversions si c'est un jour
nécessaire.