[spip-dev] Internationalisation du systeme de boucles et balises

B'jour tout le monde,

Tout d'abord: mes felicitations pour SPIP qui n'arrete pas de m'impressioner.
Vraiment, un bon boulot. Et je le dis tout a fait honnetement et pas pour
pouvoir m'autoriser a raler ensuite ;+)

Afin d'arriver a l'etape de l'"absolute world domination", je voudrais proposer
une fonctionnalite dans spip: des boucles multilingues. En effet, je pense
que le systeme de boucles est un de derniers points ou l'on pourrait pousser
encore l'internationalisation du spip, qui est deja pas mal evoluee, certes.
Je pense a une option de configuration a l'installation du systeme qui permettrait
d'utiliser un ensemble different de mots cles dans le systeme de boucles (et
balises). Ainsi, les anglophones pourraient utiliser les "LOOPS",
les polonais les "PETLAS" etc sans que cela pose un quelconque probleme
au niveau de la compatibilite avec les sites existants qui restent
bien evidemment en francais, avec les "BOUCLES" que l'on aime
tous tant. Le but de la manoeuvre est d'ajouter une fonctionnalite en plus
et non de changer quelque chose dans le systeme existent.

Si vous trouvez que cette idee n'est pas entierement stupide, je pourrai
meme me porter volontaire pour la coder (pas pour tout de suite, bien sur :+).
Sinon, bon, je vais m'y faire... ;+)

Cordialement,
Maciek Borowka

Salut Maciek,

on a déjà discuté de ça, et *si on fait quelque chose*, ce ne sera
certainement pas très flexible, mais au contraire bien cadré car :
- il faut qu'un squelette tapé en anglais soit utilisable dans un site
  polonais
- il faut que la documentation fonctionne partout, indépendamment de
  la langue que tu utilises pour la lire / écrire ton site

Une piste est de faire un pré-processeur disposant d'une liste de termes à
traduire dans le squelette *avant* de l'envoyer au compilateur. Si ce
préprocesseur voit <LOOP_toto(SECTIONS)>, il le transformera en
<BOUCLE_toto(RUBRIQUES)>. Etc.

Ce pré-processeur devrait donc fonctionner dans toutes les langues, ce qui
oblige à limiter un peu le nombre de formes à chercher/remplacer ; et,
surtout, interdit que chacun compose son langage : ça ne tolérera absolument
aucun "faux-ami". Par ailleurs il faut réfléchir au problème des langues
non-ascii.

Cela dit, la plupart des langages ne font pas cet effort de "traduire" leurs
commandes de base, les seuls exemples que je connais sont calamiteux (MS
Excel, Visual Basic...)

-- Fil

- il faut qu'un squelette tapé en anglais soit utilisable dans un site
  polonais

Justement. En reflechissant, je ne pense pas que cette fonctionnalite
soit si importante que cela. En tout cas, pas pour moi.

- il faut que la documentation fonctionne partout, indépendamment de
  la langue que tu utilises pour la lire / écrire ton site

C'est vrai que la documentation pose un enorme probleme. Mais, comme
j'ai dit, la possibilite d'avoir les boucles en une autre langue
n'est qu'une option, donc l'utilisateur devrait etre averti qu'il
risque d'y avoir quelque soucis.
Ce qui ne change pas du tout le fait, que ca risque de provoquer
un bazaar...

Une piste est de faire un pré-processeur disposant d'une liste de termes à
traduire dans le squelette *avant* de l'envoyer au compilateur. Si ce
préprocesseur voit <LOOP_toto(SECTIONS)>, il le transformera en
<BOUCLE_toto(RUBRIQUES)>. Etc.

Effectivement, cette possibilite est pas mal. Je pensais plutot a
remplacer les occurences de tous les mots cles "en dur" par des
references vers un dictionnaire qui est initialise a l'installation.

[snip]
et, surtout, interdit que chacun compose son langage : ça ne tolérera absolument
aucun "faux-ami". [snip]

Mais en fait, je viens de penser a une autre chose: il suffit de prefixer
les mots cles qui ne sont pas en francais. Par exemple "PL_PETLA" pour
boucle. Ainsi, le probleme de faux-amis est resolu. Il en reste un
autre, cependant, celui de la traduction de mots cles au moment
d'introduction de la nouvelle version. Cf. mes remarques a la fin.

Cela dit, la plupart des langages ne font pas cet effort de "traduire" leurs
commandes de base, les seuls exemples que je connais sont calamiteux (MS
Excel, Visual Basic...)

Effectivement. J'ai essaye un jour d'ouvrir un fichier Access en polonais
sous l'Access FR. J'ai essaye... ;+)

Bref. La conclusion est que ce que je propose a l'air d'une usine a gaz.
Effectivement, c'est un peu cela. Mais, comme avec chaque idee (et
surtout dans le cas des usines a gaz) il faut peser les enjeux. Ici,
il y en a un: d'elargir l'utilisation de SPIP qui, pour la plupart
de cas, est simplement capable de mettre les autres CMS hors de
competition en 2 secondes. Il nous faut donc (si on considere
que l'on veut conquerir le monde, bien sur) attirer les developeurs
interesses par son utilisation. Pour certains de ces developeurs,
l'argument que "la programation spip" est en francais sera un argument
tres positif ("parce que c'est pas en anglais"), pour les autres
cependant, ce sera un point presque bloquant. Ce que je propose,
c'est une possibilite a donner aux communautes nationnales de spip
d'avoir leur propre ensemble de mots cles. Je ne veux pas du tout
integrer cela dans l'arbre spip - ce serait stupide de point de vue
de la maintenabilite.
La solution avec le prefixes semble etre la plus simple : si le
moteur de squelettes trouve un mot-cle normal, il continue. Dans le
cas de mot prefixe, il cherche dans le dictionnaire la traduction.
En cas de moindre erreur (mot pas trouve, dictionnaire pas trouve),
il insulte le developeur en polonais et arrete le traitement. La
maintenance
de ces dictionnaires restait sous la responsabilite de chaque "nation"
interesse par la fonctionnalite. Et de preference, pour ne pas avoir
a s'embetter avec tout cela, la distrib de spip de base ne devrait
inclure aucun langue. Comme ca, la situation est nette et claire.

C'etait un peu long, desole ;+) J'espere que je suis quand meme
comprehensible...

./Maciek

>- il faut qu'un squelette tapé en anglais soit utilisable dans un site
> polonais

Justement. En reflechissant, je ne pense pas que cette fonctionnalite
soit si importante que cela. En tout cas, pas pour moi.

Pour toi, peut-être, mais si on veut éviter que la "communauté SPIP" se
désagrège en petits groupes qui ne peuvent pas facilement communiquer, c'est
important.

la possibilite d'avoir les boucles en une autre langue
n'est qu'une option, donc l'utilisateur devrait etre averti qu'il
risque d'y avoir quelque soucis.

Ca me paraît être une très mauvaise méthode.

>[snip] et, surtout, interdit que chacun compose son langage : ça ne
>tolérera absolument aucun "faux-ami". [snip]

Mais en fait, je viens de penser a une autre chose: il suffit de prefixer
les mots cles qui ne sont pas en francais. Par exemple "PL_PETLA" pour
boucle.

Ca ne me paraît vraiment pas intuitif comme méthode :slight_smile:

Effectivement, c'est un peu cela. Mais, comme avec chaque idee (et
surtout dans le cas des usines a gaz) il faut peser les enjeux. Ici,
il y en a un: d'elargir l'utilisation de SPIP qui, pour la plupart
de cas, est simplement capable de mettre les autres CMS hors de
competition en 2 secondes.

C'est amusant, chaque personne qui a une idée pour SPIP donne le même
argument : mon idée est le dernier truc qu'il fallait pour que SPIP soit
vraiment le meilleur. Avant, c'est un potentiel, après, ce sera le truc
totalement génial.

Pour certains de ces developeurs, l'argument que "la programation spip"
est en francais sera un argument tres positif ("parce que c'est pas en
anglais"), pour les autres cependant, ce sera un point presque bloquant.

Un autre choix est possible : sélectionner quelques langues (le français,
historique, l'anglais, langue de php et de mysql, et l'espéranto, pour
l'internationalisme), et limiter le préprocesseur à ce sous-ensemble
restreint de langues. Aller au-delà me paraît problématique pour pas mal de
raisons déjà citées, et d'autres.

Ce que je propose, c'est une possibilite a donner aux communautes
nationnales de spip d'avoir leur propre ensemble de mots cles. Je ne veux
pas du tout integrer cela dans l'arbre spip - ce serait stupide de point
de vue de la maintenabilite.

Ce que tu proposes, c'est de faire un fork polonais de SPIP. Sens-toi libre
de le faire, mais n'aspire pas la communauté spipienne et polonophone (?)
dans ce qui risque d'être un trou noir.

Il y a encore une autre façon de voir les choses : contribuer à la
documentation, soit en traduisant la doc existante, soit en créant des sites
de doc plus spécifiques. Et mettre dans cette documentation un glossaire
des termes spip. C'est ce que font déjà les hispanophones, les anglophones,
etc. Plutôt que de prendre le risque de l'éclatement, on essaie de favoriser
la pédagogie, la formation, l'apprentissage et les échanges.

-- Fil

C'est amusant, chaque personne qui a une idée pour SPIP donne le même
argument : mon idée est le dernier truc qu'il fallait pour que SPIP soit
vraiment le meilleur.

Bien sur! Il parait que c'est un phenomene tres connu dans le
monde open-source. Slashdot.org avait un super article quelque
part sur le sujet "comment les gens s'y prennent pour demander
des choses sur les listes de discussion", j'arrive pas du tout a
le retrouver maintenant... Je ne fait que suivre la bonne
tradition :+) Enfin, bref, j'espere que personne ne m'en veut... ;+)

Un autre choix est possible : sélectionner quelques langues (le français,
historique, l'anglais, langue de php et de mysql, et l'espéranto, pour
l'internationalisme), et limiter le préprocesseur à ce sous-ensemble
restreint de langues.

D'accord. Le probleme est que cette solution risque certainement de devier
vers un debat "l'anglas-vs-le francais". Et c'est exactement ce que
j'essaie a tout prix eviter. Ca se voit peut etre pas, mais c'est
exactement cela. Sauf s'il y a une volonte dans le noyau des developpeurs
de le faire (et comme je ne fais pas du tout partie de ce noyau,
tu es bien d'accord que c'est pas du tout a moi de proposer
ce genre de choses).

Ce que tu proposes, c'est de faire un fork polonais de SPIP.

Oo! Ca, c'est un bon argument. Sauf que je ne propose pas du tout
un fork polonais de SPIP. Ce que je propose c'est une toute
petite fourchette d'une toute petite partie de SPIP. Et ce que je
voudrais, c'est que SPIP la rend possible sans en prendre la responsabilite.
(c.a.d spip donne la possibilite d'utiliser d'autres gramaires,
et c'est a chacun de maintenir sa grammaire).

Sens-toi libre de le faire, mais n'aspire pas la communautéspipienne et polonophone (?)dans ce qui risque d'être un trou noir.

Je ne pense pas que je vais le faire. L'idee m'est venue
a l'esprir en regardant l'etat des sites de l'administration
publique polonaise et en reflechissant sur ce qu'il faudrait
faire pour y mettre spip. Tout simplement. Et vu que pour instant
ma proposition ne semble pas "allumer la foule" sur cette liste,
il y a peu de chances que je la realise...

Il y a encore une autre façon de voir les choses : contribuer [snip]

Bien sur. Je suis d'accord. Et en plus je suis un tres mauvais
eleve, car mes contributions a la doc de SPIP sont plutot... hmm..
bref... La tentation d'ecrire a la liste etait trop grande :+)

./Maciek

Je suis desole de continuer ce sujet, mais est-ce que quelqu'un peut
me dire rapidement si cette idee a deja ete discutee ici? J'arrive
pas a trouver dans les archives. Si oui, quel etait le resultat
de la discussion? Si c'est pas le cas, est-ce quelq'un est en ce
moment interesse par cela? Parce que, dans l'ensemble, il est sur
que cette option me plait bien plus que ce que j'ai propose
dans mon dernier message...

./Maciek Borowka

Il a été question de cela sur spip-en

L'idée finale est qu'il suffit d'apprendre les quelques mots clés de spip,
comme pour tout langage, et de s'appuyer sur une doc bien traduite dans
toutes les langues.

Inscris toi à spip-trad@rezo.net (spip-trad-on@rezo.net) pour connaître
l'avancement des traductions.
Il y a aussi l'espace des traducteurs sur spip.net qui est adapté aux
interrogations relatives aux traductions....

@+

BoOz

"Maciek Borowka" <maciek@borowka.net> a écrit dans le message de
news:opr654touxaldx4q@localhost...

Un autre choix est possible : sélectionner quelques langues (le français,
historique, l'anglais, langue de php et de mysql, et l'espéranto, pour
l'internationalisme), et limiter le préprocesseur à ce sous-ensemble
restreint de langues. Aller au-delà me paraît problématique pour pas mal
de raisons déjà citées, et d'autres.

Je suis desole de continuer ce sujet, mais est-ce que quelqu'un peut
me dire rapidement si cette idee a deja ete discutee ici? J'arrive
pas a trouver dans les archives. Si oui, quel etait le resultat
de la discussion? Si c'est pas le cas, est-ce quelq'un est en ce
moment interesse par cela? Parce que, dans l'ensemble, il est sur
que cette option me plait bien plus que ce que j'ai propose
dans mon dernier message...

./Maciek Borowka