Salut,
J'ai réécrit des bouts du cache langues de l'espace public,
car cela ne marchait pas du tout (fichier réécrit plusieurs
fois, chaînes oubliées d'une fois sur l'autre...).
A part ça, je ne sais pas ce que ça donne avec des "modules"
mais je ne vois pas trop l'intérêt de ces "modules"...
a+
Antoine.
J'ai réécrit des bouts du cache langues de l'espace public,
car cela ne marchait pas du tout (fichier réécrit plusieurs
fois, chaînes oubliées d'une fois sur l'autre...).
Le systeme n'ajoutait qu'une langue à chaque tour, oui, je pensais à
améliorer ça ; mais il perdait des chaines ??
A part ça, je ne sais pas ce que ça donne avec des "modules"
mais je ne vois pas trop l'intérêt de ces "modules"...
Les modules de langues sont bien pratiques pour traduire l'aide et
l'interface de la ngue elle-même ; ils peuvent aussi éventuellement
permettre à cette interface (géniale) de servir à d'autres projets.
L'idée aussi, pour SPIP, était de séparer à terme les chaines publiques et
privées ; mais le cache est finalement plus simple et plus efficace (?).
-- Fil
Evidemment je suis partant pour le cache.
Mais à terme, si on pouvait arriver à extraire les chaînes qui apparaissent sur le site public dans un autre fichier de langue, on aurait un énorme avantage: permettre aux traducteurs de commencer par de "petites" traductions (dates, formulaires de forums...). Ce qui facilitera la mise en place d'un trÚs large multilinguisme (la question de la langue de l'interface privée étant un autre problÚme).
Je signale une autre difficulté, d'ailleurs, du multilinguisme actuel: pour les langues non "traduites", on ne dispose pas de deux données essentielles et pourtant extrêmement faciles à récupérer (on pourrait le faire nous- même): l'orientation du texte et le charset (encore que...). Par exemple, si je veux indiquer qu'une version du Manifeste du Web indépendant est en hébreux, sans avoir besoin d'une interface entiÚrement en hébreux (et même l'affichage de la date n'est pas essentiel à la publication de l'article), SPIP ne saura pas gérer l'écriture de droite à gauche, parce que l'info n'est pas disponible (or, c'est facile à savoir, même sans parler l'hébreux).
A*
Mais à terme, si on pouvait arriver à extraire les chaînes qui apparaissent
sur le site public dans un autre fichier de langue, on aurait un énorme
avantage: permettre aux traducteurs de commencer par de "petites"
traductions (dates, formulaires de forums...). Ce qui facilitera la mise en
place d'un très large multilinguisme (la question de la langue de
l'interface privée étant un autre problème).
OK. Si quelqu'un veut se lancer...
Je signale une autre difficulté, d'ailleurs, du multilinguisme actuel: pour
les langues non "traduites", on ne dispose pas de deux données essentielles
et pourtant extrêmement faciles à récupérer (on pourrait le faire nous-
même): l'orientation du texte et le charset (encore que...). Par exemple,
L'orientation du texte est définie dans inc_lang et dans inc_filtres, et
c'est trivial d'ajouter es langues manquantes : je crois me rappeler que
j'ai prévu l'hébreu (à vérifier)...
Pour le charset, ça n'a rien à voir ; d'ailleurs, je pense que le charset
par défaut de la 1.7 devrait être l'utf-8, car oça commence à être éprouvé
(n a de plus en plus de sites en utf-8 qui ne posent pas de soucis), et
c'est quand même ce qu'il y a de mieux pour l'avenir...
-- Fil