root/_dev_/salvatore/documentation.txt

Les outils fournis :

* tireur :
        - va chercher les fichiers de langue (décrits dans traduction.txt)
        et les dépose dans sa copie locale
* lecteur :
        - prend les fichiers de référence dans sa copie locale (des SVN),
        et met à jour la base de données (table trad_lang)
* écriveur :
        - exporte les traductions (à partir de la table trad_lang) sous
        forme de fichiers traduits, dans une copie locale (idem export SVN)
* pousseur :
        - commit SVN les différents fichiers de langue

== librairie commune inc_tradlang.php

--
-- Structure de la table `trad_lang`
--

CREATE TABLE IF NOT EXISTS `trad_lang` (
  `id` varchar(128) NOT NULL default '',
  `module` varchar(128) NOT NULL default '',
  `lang` varchar(16) NOT NULL default '',
  `str` text NOT NULL,
  `comm` text NOT NULL,
  `ts` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  `status` varchar(16) default NULL,
  `traducteur` varchar(32) default NULL,
  `md5` varchar(32) default NULL,
  `orig` tinyint(4) NOT NULL default '0',
  `date_modif` datetime default NULL,
  KEY `idx_tl` (`id`),
  KEY `idx_t2` (`module`),
  KEY `idx_t3` (`id`,`module`,`lang`),
  KEY `idx_t4` (`module`,`lang`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


Description des champs :
id :
        identifiant de la chaine (commun à toutes les langues)
        exemple 'accueil_site'
module :
        nom du module
        exemple : cfg
lang :
        code ISO de la langue
        exemple : fr
str :
        contenu de la chaine (id) dans la langue donnée (lang) pour le
        module concerne
comm :
        champ de commentaires
ts :
        timestamp mis à jour lors des modifications
status :
        ?
traducteur :
        login du traducteur dans l'interface de traduction
md5 :
        md5(str_lang_reference) champ renseigné uniquement pour les
        langues qui ne sont pas la langue de référence du module,
        calculé à partir la valeur de str pour le meme id dans la langue
        de référence
orig :
        0/1 : 1 si c'est la langue de référence, 0 sinon
date_modif :
        ?



En rediscutant un peu (sur irc) de notre problématique de traduction
des plugins, il semble qu'une des difficultés, c'est que ce sont les
codeurs qui sont à l'origine des chaines de langue, mais que ce sont
les admins de spip.net (en l'occurrence moi pour SPIP et George pour
les plugins) qui doivent (c'est-à-dire, sont autorisés à) ajouter des
éléments dans la base de données des traductions.

Ce système crée un goulot d'étranglement (il faut passer par un tiers,
qui n'est pas forcément disponible immédiatement), et par conséquent
un décalage frustrant, qui fait que le passage en traduction est
souvent pesant, alors que ça devrait être une fête.


Une solution envisageable serait de programmer un système
d'aller-retour entièrement automatique entre le SVN et trad-lang :

1) Chaque "module" prêt à traduire serait défini par un fichier de
référence ; par exemple :
'ecrire' => svn://trac.rezo.net/spip/spip/ecrire/lang/ecrire_fr.php
on note la liste de ces fichiers dans un fichier texte
traductions.txt, un peu comme archivelist.txt décrit les zip à
produire

2) Pour ajouter, modifier ou supprimer une chaîne dans le module
'ecrire', il suffirait de modifier ce fichier dans le SVN. (A noter :
il faudra dès lors supprimer de l'interface trad-lang la possibilité
d'administrer le fichier de langue "source").

3) périodiquement, trad-lang irait récupérer la liste des modules
décrits dans traductions.txt, puis récupérerait chacun des fichiers de
référence et insèrerait les chaines en question dans sa base de
données.

4) les traducteurs traduiraient, comme d'habitude, dans l'interface
web de trad-lang (mais elle aurait beaucoup plus de modules)

5) trad-lang exporterait les fichiers traduits à côté des fichiers de
référence, et les commiterait directement dans SVN.


La seule conséquence négative que je vois à ce système, c'est au
niveau du contrôle de "ce qui entre en traduction" ; notamment, on
avait l'idée d'essayer d'éviter les doublons, de surtout éviter de
faire entrer des fautes d'orthographe, etc. Mais ce contrôle peut se
faire à postériori, sans être bloquant : il faudra collectivement
qu'on surveille les fichiers de langue commités par les uns et par les
autres, comme on le fait déjà pour les autres trucs (plugin.xml etc).

A priori, ça me paraît jouable comme ça. Mais si vous avez
l'expérience de traduction d'autres logiciels, notamment avec un site
comme translation project ou les outils de gestion de .po, ça serait
intéressant de voir comment on pourrait améliorer ce qu'on fait.

http://translationproject.org/html/software.html

-- Fil


Je viens de faire un script pour exporter automatiquement les chaines
de langues traduites dans le module "contrib", en direction de
SPIP-Zone.

Il y a plusieurs conséquences :

1) Pour les plugins concernés, il devient INTERDIT de créer des
chaines de langue autrement qu'en passant par l'interface de spip.net
; c'est ennuyeux, mais indispensable. Il faut qu'on améliore cette
interface pour assouplir sa gestion.

Pour l'instant on a mis dans ce système les plugins suivants :

        'cfg' => 'svn://zone.spip.org/spip-zone/_plugins_/_stable_/cfg/lang/',
        'couteau' => 'svn://zone.spip.org/spip-zone/_plugins_/_stable_/couteau_suisse/lang/',
        'crayons' => 'svn://zone.spip.org/spip-zone/_plugins_/_stable_/crayons/lang/',
        'listes' => 'svn://zone.spip.org/spip-zone/_plugins_/_dev_/mailman_popup/lang/',
        'sedna' => 'svn://zone.spip.org/spip-zone/_plugins_/_test_/sedna/lang/',
        'spipbb' => 'svn://zone.spip.org/spip-zone/_plugins_/_dev_/spipBB/lang/',

A noter : on considère qu'un plugin est "traduit" dans une langue x si
cette langue comporte plus de 50% de chaines qui ne sont pas marquées
"<NEW>"

2)  Il faudrait s'il vous plait vérifier que les envois que j'ai faits
ne comportent pas d'oubli (chaine ajoutée ou traduction améliorée sur
la zone, mais pas dans le module sur spip.net). J'ai regardé autant
que j'ai pu mais il y a tellement de lignes, j'ai pu laisser passer
une coquille.

3) Dernier point, ça reste un script assez complexe qu'on ne peut pas
facilement jouer de chez soi (puisqu'il faut l'accès à la base de
données des traductions de spip.net) ; là aussi la solution passerait
plutôt par un travail d'amélioration/réécriture de trad-lang. En
attendant ça en restreint l'usage à une seule personne (moi), donc ça
fait goulet d'étranglement... On peut cependant partager cet accès à
deux ou trois personnes, pour faciliter les mises à jour.

-- Fil


En fait il faudrait plusieurs scripts :

* tireur : il va chercher les fichiers dans le svn
* lecteur : il prend les fichiers de référence dans sa copie locale
des SVN, et met à jour la base de données
* écriveur : il exporte les traductions sous forme de fichiers
traduits, dans sa version locale
* pousseur : il commit svn