- comment s'agit-il de proposer pour inclusion dans "public_xx.php3" des
chaînes qu'on pense peuvent être intéressantes ?
--Fil écrivait:
Nous allons commencer par intégrer les chaînes des squelettes par défaut,
mais pour la suite il faudrait qu'on en discute (sur la liste spip-trad,
de
préférence). Pour éviter que ce soit le bazar, il faudra qu'on se donne
une
méthode, mais je n'ai aucune idée de la bonne méthode ...
On y réfléchissant, je me demande si la relation entre "local_xx.php3" et
"public_xx.php3" ne pourrait pas être que celui-ci est comme un seau dans
lequel on puise pour trouver les chaînes qu'on veut pour son site et qu'on
transférera à son "local_xx.php3".
Probablement la façon de faire la plus facile au début sera de copier des
fichiers "public_xx.php3", les renommer "local_xx.php3". Ensuite effacer les
chaînes qu'on ne va pas utiliser, et en ajouter d'autres.
Pas très propre tout cela... Et chaque langue dans un autre fichier. Si
jamais j'arrive à mettre notre site sous Spip, cela fera 26 fichiers avec
peut-être une quinzaine de chaînes dans chacun.
Est-ce que il y a une raison pour ne pas mettre ces chaînes multilingues
dans la base MySQL?
Le mardi, 21 oct 2003, à 00:27 Europe/Paris, Paolo a écrit :
On y réfléchissant, je me demande si la relation entre "local_xx.php3" et
"public_xx.php3" ne pourrait pas être que celui-ci est comme un seau dans
lequel on puise pour trouver les chaînes qu'on veut pour son site et qu'on
transférera à son "local_xx.php3".
C'est plutôt à l'autre sens que je pense : on bosse chez soi en "local", et
puis on propose de donner ses chaînes et leurs traduction à "public", ce qui
augmente le "bien commun", avec comme avantage pour celui qui "donne" ses
chaînes de s'assurer la contribution en retour des traducteurs de SPIP dans
les langues qu'il n'a pas faites.
Pas très propre tout cela... Et chaque langue dans un autre fichier. Si
jamais j'arrive à mettre notre site sous Spip, cela fera 26 fichiers avec
peut-être une quinzaine de chaînes dans chacun.
Tu gères 26 langues ?
Est-ce que il y a une raison pour ne pas mettre ces chaînes multilingues
dans la base MySQL?
1) c'est plus facile à éditer, transférer, modifier, etc.
2) quand la base est absente (création du site) ou tombée (erreur), il faut qu'on puisse quand même aller chercher certaines chaînes...
C'est plutôt à l'autre sens que je pense : on bosse chez soi en "local",
et
puis on propose de donner ses chaînes et leurs traduction à "public",
ce qui augmente le "bien commun", avec comme avantage pour celui qui
"donne"
ses chaînes de s'assurer la contribution en retour des
traducteurs de SPIP dans les langues qu'il n'a pas faites.
Oui. C'est tres bien. Est-ce que par la suite on transfère les chaînes qui
nous intéressent de nouveau dans nos fichiers "local" - pour ne pas avoir à
réferencier les "public"?
Tu gères 26 langues ?
Pour l'instant oui (mais dans certaines langues, il n'y a qu'une quinzaine
de pages): www.taize.fr
> Est-ce que il y a une raison pour ne pas mettre ces chaînes
> multilingues
> dans la base MySQL?
1) c'est plus facile à éditer, transférer, modifier, etc.
A propos de ces fichiers, Thierry Gagnon a écrit (spip-dev, le 21.10.03):
"Il faut utiliser le code HTML pour les caractères spéciaux comme les
accents."
Est-ce vraiment nécessaire ? Cela devient vraiment difficile à editer (au
moins directement) en ce cas.
Pour d'autres fichiers de traduction PHP, j'ai pu utiliser des chaînes UTF-8
contenant le russe, coréen, etc. tapé en clair, et cela marche.
Oui. C'est tres bien. Est-ce que par la suite on transfère les chaînes qui
nous intéressent de nouveau dans nos fichiers "local" - pour ne pas avoir à
réferencier les "public"?
Non, a priori on va faire la chose suivante : le code <:toto:> ira chercher
toto dans "local" puis, s'il ne l'a pas trouvée là, dans "public". (Mais ça
n'est pas encore programmé).
A propos de ces fichiers, Thierry Gagnon a écrit (spip-dev, le 21.10.03):
"Il faut utiliser le code HTML pour les caractères spéciaux comme les
accents."
Est-ce vraiment nécessaire ? Cela devient vraiment difficile à editer (au
moins directement) en ce cas.
Pour d'autres fichiers de traduction PHP, j'ai pu utiliser des chaînes UTF-8
contenant le russe, coréen, etc. tapé en clair, et cela marche.
Ca ne marche que parce que c'est aussi le charset de ton site. Mais ne
t'inquiète pas, la conversion est aisée.
Pour éditer les modules de langues, tu peux aussi, maintenant, travailler
avec le système de traduction de SPIP.net, qui est téléchargeable là : http://www.eledo.com/download/
Pour éditer les modules de langues, tu peux aussi,
maintenant, travailler
avec le système de traduction de SPIP.net, qui est téléchargeable là : http://www.eledo.com/download/
(Je sais que hier soir par une fausse maneouvre j'ai envoyé une demande
d'aide à spip-dev au lieu d'à spip-user... en réparation je vais essayer de
traduire l'Histoire minuscule de Spip...)
