[spip-dev] Re: CVS: traduction de Spip

Dev
1

Hello,

Non, non, c'est la mauvaise méthode de vouloir traduire l'interface
actuelle tel quelle.

+1

Je crois que la dernière fois qu'on en a parlé, Nicolas Hoizey a
proposé de reprendre le système utilisé par MyPhpAdmin.

En fait, c'est historiquement le système que j'ai développé pour le
site phpHeaven, que j'ai ensuite ouvert sous le nom phpLang, puis
appliqué dans phpMyChat, et qui a été appliqué par mon co-développeur
de ce dernier, Loïc Chapeau, dans phpMyAdmin ... :wink:

Donc il suffit de prendre phpLang en l'état et de l'utiliser.

Une ch'tite doc (en anglais) :
http://articles.phpheaven.net/article.php3?id_article=9

Sinon, ce que fait phpLang devrait être fourni par PEAR I18N
( http://cvs.php.net/cvs.php/pear/I18N ), pour le jour où on se
mettra à utiliser PEAR dans SPIP ... :wink:

L'externalisation de toutes les chaines de l'application est faite
dans des fichiers de constantes globales.

Les constantes sont forcément globales ... :stuck_out_tongue:

Avec un fichier par langue, le choix de la langue est effectué en
fonction des préférences du browser client.

A la première connexion, en fonction des préférences du browser, puis
selon le choix explicite du visiteur.

Avant qu'on se lance dans la traduction, je propose qu'on
1- liste toutes les chaines à traduire dans SPIP
2- établisse une convention de nommage pour les constantes de
   chaines
3- construise un fichier de langue maitre pour le français. Cela
   servira de base pour toutes les traductions.

Oui.

4- qu'on replace dans le code les chaines par des
   GLOBAL(nom_chaine).

Non, juste nom_chaine, ou plutôt NOM_CHAINE, puisque ce sont des
constantes.

5- Il faudra en outre externaliser les charsets, les familles de
   font, et paufiner les formats de dates

Voir le boulot effectué dans les projet nommé ci-dessus pour
inspiration.

L'interface de la 1.4 commence à être stabilisé, on peux peut-être
commencer et se partager les étapes 1,2 et 3.
Alors, on ouvre ce chantier ?

On commence à préparer, mais on n'attaque pas pour la 1.4

Un outil intéressant serait une interface de gestion des traductions,
avec stockage en bdd des chaines de caractères, et création
automatisée des fichiers de constantes.

-Nicolas

2

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

Un outil intéressant serait une interface de gestion des traductions,
avec stockage en bdd des chaines de caractères, et création
automatisée des fichiers de constantes.

J'avais suggéré ça quand on parlait de la traduction de Mailman.
(www.list.org) mais personne n'a eu l'envie de s'y mettre. Ca serait un
outil générique, cf.
<http://listes.rezo.net/archives/mailman-fr/2002-01/msg00002.html>

-- Fil

3

Bonjour,

4

J'avais suggéré ça quand on parlait de la traduction de Mailman.
(www.list.org) mais personne n'a eu l'envie de s'y mettre. Ca serait
un outil générique, cf.
<http://listes.rezo.net/archives/mailman-fr/2002-01/msg00002.html>

Intéressant, oui.

La réponse qui parle de TP me convient moins que ta proposition, je
n'aime pas le concept de gettext ... :wink:

-Nicolas

5

Hello,

Ce n'est pas le role de la bibliothèque gettext ?

A priori, je vois mal gettext tourner sous Windows, mais je me trompe
peut-être.

Quoi qu'il en soit, c'est plutôt crade comme solution à mon avis.

-Nicolas

6

@ Nicolas Hoizey <nhoizey@phpheaven.net> :

J'avais suggéré ça quand on parlait de la traduction de Mailman.
(www.list.org) mais personne n'a eu l'envie de s'y mettre. Ca serait un
outil générique, cf.
<http://listes.rezo.net/archives/mailman-fr/2002-01/msg00002.html>

Oui, c'est une bonne idée. Il faudrait aussi que n'importe qui, en fait,
même sans login, puisse suggérer une traduction pour tel et tel truc.

En amont, pour repérer les chaînes, il y avait le script que j'avais fait
il y a des mois et qui... n'est plus sur rezo.net/spip-dev (?).

7

Bonjour,

gettext tourne tres bien sous windows sauf erreur

OK, c'est donc un bon point, mais je signalais aussi que "c'est plutôt
crade comme solution à mon avis", donc y a-t'il une réponse à ça ? :wink:

-Nicolas

8

gettext tourne tres bien sous windows sauf erreur

OK, c'est donc un bon point, mais je signalais aussi que "c'est plutôt
crade comme solution à mon avis", donc y a-t'il une réponse à ça ? :wink:

J'ai essayé de regarder un jour mais la doc est difficilement compréhensible
et ça semble effectivement plutôt crade. Notamment, si je me souviens bien,
les chaînes sont indexées par elles-mêmes, ce qui fout un bordel pas possible
si une chaîne d'origine change même d'une lettre.

De plus c'est un module optionnel en PHP -> ciao.

9

les chaînes sont indexées par elles-mêmes, ce qui fout un bordel pas
possible si une chaîne d'origine change même d'une lettre.

C'est bien à ça que je pensais en disant que c'est crade ... :wink:

De plus c'est un module optionnel en PHP -> ciao.

Yep.

Franchement, la solution des fichiers de constantes utilisée dans
phpMyChat est la plus convaincante de celles que j'ai été amené à
pratiquer sur différents projets.

Une bonne solution est celle que j'utilise sur phpHeaven, c'est à dire
un fichier "central" pour les textes utilisés partout, et ensuite un
fichier par page pour les textes spécifiques.

On peut alors faire une interface de saisie des différentes versions,
et générer les fichiers à la demande.

-Nicolas

10

Franchement, la solution des fichiers de constantes utilisée dans
phpMyChat est la plus convaincante de celles que j'ai été amené à
pratiquer sur différents projets.

Je crois que tout le monde est d'accord.

Une bonne solution est celle que j'utilise sur phpHeaven, c'est à dire
un fichier "central" pour les textes utilisés partout, et ensuite un
fichier par page pour les textes spécifiques.

Un fichier par page ? C'est pas trop contraignant ?
Ca coûte beaucoup, en temps d'interprétation, un gros
fichier de define ?

11

Salut,

12

Un fichier par page ? C'est pas trop contraignant ?

Pas si on se fait une interface de gestion de ces contenus.

Sinon, on peut regrouper les traductions dans quelques fichiers
correspondants aux grandes fonctionnalités. Dans phpMyChat, par
exemple, il y a 3 fichiers.

Par contre, cela empêche de profiter de la gestion automatisée de
phpLang.

Ca coûte beaucoup, en temps d'interprétation, un gros fichier de
define ?

A moins d'avoir une gestion de cache mémoire genre Zend Accelerator,
ce n'est sans doute pas négligeable, vu le nombre de define() à
charger et traiter, mais on peut faire un test.

-Nicolas

13

Hello,

c'est la méthode adopté par la quasi totalité des produits libres
sous licence GPL, ca doit donc pas apparaitre si 'crade' pour tout
le monde, y compris par de très grand développeurs.

A mon avis, c'est le seul truc disponible, donc tout le monde
l'utilise (et encore, y'a pas tant de projets que ça qui sont
internationalisés), mais ça ne signifie pas forcément que c'est ce
qu'il y a de mieux à faire ... :wink:

Il me semble qu'en Java, il y a le même principe que celui que je
propose, avec des fichiers de ressources.

-Nicolas

14

Il me semble qu'en Java, il y a le même principe que celui que je
propose, avec des fichiers de ressources.

Et chez Microsoft (Visual Studio), c'est aussi des fichiers de ressources
indexés par des constantes (mappées sur des #define dans le code source).

Non, gettext, ça me semble vraiment pas terrible....

15

Perso, je voyais un système en deux (ou plus?) étapes:

- la sauvegarde et l'échange des traductions se font dans des fichiers XML;
- ces fichiers XML sont transformés en fichiers de variables PHP une fois pour toutes (enfin, recalculés en cas de modification du fichier XML).

Par exemple, le fichier XML pourrait avoir deux niveaux de hiérarchie, genre:

"français.xml"

<langue>
      <nom>Français</nom>
      <charset>isoxxxx-xx</charset>
</langue>
<navigation>
      <asuivre>À suivre</asuivre>
      <lesdocuments>Les documentes</lesdocumentes>
      <lesredacteurs>Les rédacteurs</lesredacteurs>
     ...
</navigation>
...

C'est sur ce fichier que porteraient les modifications, et qui serait installé/échangé lors de l'ajout de langues d'interface.

Ce qui serait transformé (automatiquement) dans un fichier de valeurs, genre:

"français-lang.php"

$spip_texte["langue"]["nom"] = "Français";
$spip_texte["langue"]["charset"] = "isoxxxx-xx";
$spip_texte["navigation"]["asuivre"] = "À suivre";

(Bon, je fais un tableau de variables, c'est juste pour l'explication de principe.)

16

Hello,

- la sauvegarde et l'échange des traductions se font dans des
   fichiers XML

Pourquoi pas.

Mais centraliser une unique interface web de gestion des traductions
sur uzine.net ou rezo.net serait quand même beaucoup plus simple, donc
l'utilisation de XML perd tout intérêt à mon avis.

Sinon, comment gérer :

- les traductions partielles,
- les envois de fichiers XML par des traducteurs différents
-

[...]
Ce qui serait transformé (automatiquement) dans un fichier de
valeurs, genre:

"français-lang.php"
$spip_texte["langue"]["nom"] = "Français";
$spip_texte["langue"]["charset"] = "isoxxxx-xx";
$spip_texte["navigation"]["asuivre"] = "À suivre";

(Bon, je fais un tableau de variables, c'est juste pour
l'explication de principe.)

Oui, c'est juste pour le principe, parce que c'est clair qu'il faut
mieux avoir des constantes qu'un tableau ... :wink:

L'édition se ferait uniquement sur le fichier XML, au travers d'une
interface à développer.

Franchement, éditer du XML via une interface Web, c'est pas top.

non mais par contre l'interet de la proposition c'est que ca serait
ters facile de devloper un translateur XML vers ce fichier de langage
avec XSLT de plus on peut tres bien imaginer que le fichier en
question puisse contenir plusieurs translations puisque a chaque tag
proposé on peut avoir un attribut langue. Ce qui fait qu'un
traducteur n'a juste qu'a faire un gros copier coller de blocs
entiers et se taper de traduire chaines par chaines.

17

> l'interet de la proposition c'est que ca serait ters facile de

devloper un translateur XML vers ce fichier de langage avec XSLT

En effet, mais vu les bugs récurrents de sablotron, le XSLT n'est pas
vraiment l'idéal sur PHP à moins d'utiliser php_xalan
( http://www.nttslab.de/php_xalan/ ), ce qui n'est pas franchement à
la portée de tout le monde.

comme c'est essentiellement au niveau developpement je pensais que
c'etait un outil qui pourrait etre utilise en dehors de SPIP lui
meme, generant des fichiers comme tu le proposais. J'ai pas regarder
ce qui se fait en PHP au niveau XML et XSLT j'utilise que du java.

Donc s'il faut en plus avoir du Java, c'est pas tip top.

ben quoi c'est bien java :wink:

on peut tres bien imaginer que le fichier en question puisse
contenir plusieurs translations puisque a chaque tag proposé on peut
avoir un attribut langue. Ce qui fait qu'un traducteur n'a juste
qu'a faire un gros copier coller de blocs entiers et se taper de
traduire chaines par chaines.

Là, je ne vois pas l'intérêt par rapport à des fichiers séparés ...

Ben pour le copier coller tu peux avoir ainsi des fichiers qui contiennent dans un seul source plusieurs langues. Tu pauex ainsi avoir qq chose comme :

<atome lang="fr">
  <nameEntry>
     La chaine
  </nameEntry>
</atome>

<atome lang="en">
  <nameEntry>
     The string
  </nameEntry>
</atome>

ou bien :

<atome lang="fr">
  <nameEntry lang="fr">La chaine</nameEntry>
  <nameEntry lang="en">The string</nameEntry>
</atome>

Dans un fichier indiferement et generer la meme chose avec le meme
script XSLT mais ca change tout pour les traductions puisque le
translateur a tjrs une langue source et ce qu'il fait dans le meme
fichier ce qui elimine pas mal d'erreur, permet la translation par
petits bouts et facilite le copier coller a donf.

18

Hello,

comme c'est essentiellement au niveau developpement je pensais que
c'etait un outil qui pourrait etre utilise en dehors de SPIP lui
meme, generant des fichiers comme tu le proposais. J'ai pas regarder ce
qui se fait en PHP au niveau XML et XSLT j'utilise que du java.

XSL, c'est un peu usine à gaz, non ? On n'a pas besoin de customiser
du XML dans tous les sens.

oui les regles de transformation s'ecrivent en XML et meme si XSLT est turing complete c'est vrai que c'est assez cossu :wink: Mais ca se fait qu'une fois et c'est pas si dur que ca.

ben quoi c'est bien java :wink:

Il y a au moins un développeur qui déteste Java ;))
(et je pense que les deux autres ne mettraient pas
longtemps à détester aussi :-)))

ben y a des developpeurs qui n'aiment pas PHP non plus :wink:
Et on doit bien pouvoir faire du XSLT en php si besoin est.

Mais chaque outil est bien adapte a qq utilisations.

19

ben quoi c'est bien java :wink:

Il y a au moins un développeur qui déteste Java ;))

ben y a des developpeurs qui n'aiment pas PHP non plus :wink:

Je rappelle à toutes fins utiles que SPIP est développé en PHP ... :wink:

-Nicolas