[spip-dev] i18n, suite des événements

bonjour,

après l'intégration de l'utilisation de la fonction _T pour la partie
privée de l'interface, quelles sont les étapes suivantes en vue de
l'internationalisation de SPIP ?

- intégration du charset dans le fichier langue ? (spip_fr.php3)

- développement d'un script php permettant de faciliter les traductions ?
(affichant par exemple le texte à traduire en haut en charset français, et un
un champ saisie en bas dans le charset cible - on peut faire ça avec des
frames.

- commencer le travail de traduction

- utilisation de la fonction _T dans la partie publique (à ce propos,
spip_fr ne devrait-il pas s'appeler spip_priv_fr ?)

- possibilité d'internationaliser les squelettes (le script gen_lang.php3
doit alors être rendu utilisable par tous)

Voilà quelques idées, est-ce que je m'égare, qu'est-ce qui est
prioritaire ?

Florent

après l'intégration de l'utilisation de la fonction _T pour la partie
privée de l'interface, quelles sont les étapes suivantes en vue de
l'internationalisation de SPIP ?

- intégration du charset dans le fichier langue ? (spip_fr.php3)

Non, par principe le fichier langue doit être en 7bits : d'une part, pour
qu'il soit comme le reste de SPIP ; d'autre part, pour pouvoir éditer un
texte en persan dans une interface en russe :wink:

- développement d'un script php permettant de faciliter les traductions ?
(affichant par exemple le texte à traduire en haut en charset français, et un
un champ saisie en bas dans le charset cible - on peut faire ça avec des
frames.

Oh oui, ce serait super !

- commencer le travail de traduction

Laissons cela aux traducteurs ? Pour l'anglais, l'espagnol, l'allemand, je
crois que le travail de trad a déjà été fait, il faudrait intégrer les
fichiers de langue.

- utilisation de la fonction _T dans la partie publique (à ce propos,
spip_fr ne devrait-il pas s'appeler spip_priv_fr ?)

Oups, là tu vas trop vite à mon avis...

- possibilité d'internationaliser les squelettes (le script gen_lang.php3
doit alors être rendu utilisable par tous)

Là le travail à faire est de l'ordre de la recherche théorique

J'ajouterais :

* invention d'une interface de sélection de la langue, qui serait valable
  dans l'espace privé, mais évenutellement réutilisable dans la partie
  publique..

* rédaction d'une feuille d'"instructions aux traducteurs"

* vérifier si on a tout ce qu'il faut : par exemple, il me semble que dans
  le fichier inc_langues.php3 il faudrait avoir, pour chaque langue dispo,
  son nom exprimé en elle-même ('français', 'english', 'deutsch',
  'español', 'õȳ......', etc.)

* Par ailleurs, je pense qu'on devrait pouvoir jouer avec quatre ou cinq
  langues avant d'avancer plus, sinon on risque de prendre une mauvaise
  direction. Donc il est pê prioritaire de récupérer des fichiers de langue
  pour les quelques langues déjà traduites ? Le zorglub dispose d'un
  vocabulaire assez limité -- si tu veux t'amuser 10 minutes, tu peux
  utiliser un filtre de traduction auto, et voir ce que ça donne ?

-- Fil

Non, par principe le fichier langue doit être en 7bits : d'une part, pour
qu'il soit comme le reste de SPIP ; d'autre part, pour pouvoir éditer un
texte en persan dans une interface en russe :wink:

Je suis allé un peu vite : j'ajoute que rien n'interdit, par contre, de
passer les textes issus de _T à la moulinette 7bits -> charset du site.

Un bon exemple est l'espéranto, où certains utilisateurs préfèrent la
translittération dite "cx" à l'utf-8, et inversement.

Cf. http://eo.mondediplo.com/ pour une maquette (le bloc KODO)

-- Fil