J'aime bien aussi.
Quelques remarques:
- Pour moi, la séparation en deux modules, un pour l'espace privé, un pour l'espace public, je ne vois pas ça comme un service aux webmestres, mais uniquement comme une facilitation des traductions pour des sites multilingues, même sans avoir "tout" traduit:
- je publie sur mon site des informations en hébreux; l'interface complÚte pour l'hébreux, je ne l'ai pas; mais j'ai quand même un site avec des articles en hébreux (je bosse avec SPIP en anglais, bicoz je cause anglais);
- à l'heure actuelle, mon interface publique sera bancale, avec des articles hébreux et des dates et des formulaires en anglais (tiens, pour le coup, je crois bien qu'en plus j'ai un putain de problÚme de texte de droite à gauche partout, même les parties en anglais);
- seule solution pour l'instant: j'attends (ou je m'y mets) que quelqu'un traduire _toute_ l'interface en hébreux. C'est pas forcément demain la veille;
- avec deux modules séparés, je peux espérer en revanche avoir trÚs rapidement la partie publique traduite, parce qu'il y a beaucoup moins de chaînes à faire; du coup je continue à bosser en anglais, mais je peux publier en hébreux;
- autre avantage (peut-être): les chaînes du site public ne changent que trÚs peu d'une version à l'autre. Du coup, une fois un corpus de traductions faites de ce cÎté-là , elles sont à peu de chose prÚs toujours "complÚtes" et fonctionnelles. Alors qu'actuellement, si une nouvelle langue "complÚte" est terminée, c'est un fichier pour la 1.7a5, pas forcément entiÚrement compatible avec la 1.6 de mon site. La partie publique seulement, à l'inverse, je peux y aller relativement sans risque.
- Les textes de la gestion de l'interface (spip_fr.php3 par exemple), franchement vaut mieux pas les utiliser directement dans les squelettes de son site public. Et donc ne surtout pas encourager les webmestres à le faire. Parce que ces chaînes sont susceptibles de changer d'une version à l'autre, une chaîne étant renommée sans préavis.
- Livrer un module "par défaut", excellente idée. Mais est-ce qu'on ne peut pas décider que son fonctionnement est transparent. Par exemple, ce module propose une chaîne pour "Télécharger ce fichier" (code: "telecharger_fichier"). Bon ben on l'appelle directement par <<telecharger_fichier>>.
Si la personne décide que ça doit changer, elle fabrique une nouvelle chaîne (éventuellement, "telecharger_fichier") dans l'interface ad hoc, qu'elle traduit si elle veut. Et elle l'appelle de la même façon: <<telecharger_fichier>>.
Du coup: quand on cherche "telecharger_fichier", on commence par chercher dans "public" (fichier perso), puis dans "spip" (fichier fournit avec SPIP, mais ne concernant pas l'interface du systÚme lui-même). Du coup, la notion de "module" existe, mais elle est totalement transparente.
(On peut prévoir, pour les furieux qui voudraient gérer plusieurs modules, la possibilité de forcer par <<monmachin:telecharger_fichier>>. Mais uniquement pour les furieux.)
- Pour le module "standart" (réalisé par les traducteurs de SPIP), volontairement se limiter. Dans l'interface privée, on s'est lâchés (Article, Articles, article, articles, les articles...) parce que le produit existait avant la traduction et parce que l'interface est trÚs descriptive, mais pour un package standart, faut se limiter absolument. Non seulement pour ne pas tuer les traducteurs à la tâche, mais aussi pour faciliter le travail des webmestres, auxquels il ne faut pas balancer un liste de 1000 termes impossibles à retrouver.
ARNO*
