[spip-dev] spip multilingue

Dev
1

Bonjour,

À (At) 22:19 +0200 1/09/2001, Antoine Pitrou écrivait (wrote) :

Un draft pour SPIP multilingue :
http://rezo.net/spip-dev/devel/multilang.txt

Si j'ai bien lu (?), il n'y aura pas de possibilité de dire « tel
article est la traduction de tel autre » : ça me semble pourtant
nécessaire dans le cadre d'un site multilingue où tous les articles
n'ont pas de traductions dans telle langue ou quand la mise en ligne
s'effectue petit à petit. Si c'était possible, on pourrait afficher
grâce à une <BOUCLEn{LANGUES}> -- ou autre -- la liste des articles
correspondants dans d'autres langues.

Si ce que je dis est spécifié dans le document d'Antoine, merci de me
le dire : j'irai me reposer...

Merci,

Gilles.

2

Salut,

Je viens d'ajouter des commentaires =E0 la feuille de route du
multilingue d'Antoine:
http://rezo.net/spip-dev/devel/multilang.txt

Ce sont des points qui me semble tr=E8s importants, mais qui sont tr=E8s
lourdes =E0 g=E9rer (sauf =E0 transformer le bidule en usine =E0 gaz avec un=
e
programmation de louf et une interface de kamikaze):

(1) Comme l'indique Gilles (et comme on me l'a rappel=E9 dans diverses
conversations de webmestres qui attendent une telle fonction), les
fonctions multilingues impliquent qu'on puisse indiquer d'un article
est la traduction d'un autre, afin de pouvoir proposer un lien direct
vers les autres versions. De plus, il faut pr=E9voir un nombre
potentiellement infini de traductions diff=E9rentes d'un m=EAme article,
donc on ne peut pas se contenter de liens r=E9ciproques entre deux
articles, mais g=E9rer des "groupes" d'article. Certainement chiant =E0
programmer (notamment pour qu'on puisse fabriquer des boucles simples
dans les squelettes), surtout groooossse difficult=E9 d'interface dans
l'espace priv=E9.

Sans cette fonctionnalit=E9, le multilingue pourrait d=E9j=E0 tr=E8s bien se=

g=E9rer avec les mots-cl=E9s (il suffit pour l'heure de cr=E9er un groupe
de mots "langues", puis des mots-cl=E9s pour chaque langue dans ce
groupe - "fran=E7ais", "anglais"... - ensuite on peut directement
s=E9lectionner dans les squelettes en fonction des mots-cl=E9s de langue,
et/ou afficher la langue de chaque article; avec les logos de
mots-cl=E9s introduits dans la derni=E8re version beta, on peut m=EAme
ajouter un petit drapeau apr=E8s le titre de chaque article!).
Evidemment, on n'a pas alors le traitement typographique diff=E9renci=E9
pour chaque langue, mais =E7a me semble pas tr=E8s grave pour l'heure.

(2) Si on introduit des fonctionnalit=E9s multilingue dans SPIP, plut=F4t
que de se contenter d'une utilisation des mots-cl=E9s, c'est donc
notamment parce qu'on veut (en plus des correspondances entre les
traductions d'un m=EAme article) modifier les comportements
typographiques et des dates. "1er janvier 2001" devenant "January
1st, 2001" en anglais. L=E0 aussi, gros bordel en perspective. Comment
configurer pour toutes les langues? Ca implique d=E9finition des r=E8gles
typographiques (et le chinois, l'h=E9breu et l'arabe?), la traduction
des noms des jours et des mois, la d=E9finition de l'ordre des mots, la
fa=E7on dont on "compte" les jours (en fran=E7ais: "22 janvier"; en
anglais, "january 22th" si je ne me trompe)...

=46aut-il faire une fichier inc_texte diff=E9rent pour chaque langue? Ou
peut-on r=E9ussir (ce serait beaucoup mieux) =E0 cr=E9er des fichiers de
configuration (relativement simples =E0 modifier), par exemple en XML,
d=E9crivant ces diff=E9rents comportements pour chaque langue? Et en
fonction du contexte, inc_texte chargerait la configuration qui va
bien...

Evidemment, ces deux fonctionnalit=E9s reposent sur le syst=E8me de choix
des langues (par site, par rubrique, par article) d=E9j=E0 d=E9crit dans ce
document par Antoine.

Voil=E0 voil=E0, ce sont les deux =E9normes difficult=E9s qui se pr=E9parent=

avec le multilingue: chiant =E0 programmer (ou plut=F4t: chiant pour que
les localisations dans une tripot=E9e de langues soient faciles =E0
r=E9aliser, ou notamment =E0 faire r=E9aliser par des webmestres =E9trangers=

sans qu'ils rentrent trop dans le code PHP), et tr=E8s difficile =E0
int=E9grer graphiquement dans l'interface.

Amicalement,
ARNO*

3

Voici la proposition que j'avais écrite à Antoine, suite
à son écrit, et qui réponds à cette demande:

(Elle répond au premier point d'Arno*, concernant la notion
de groupe d'article.)

Proposition:

Rajout d'une colonne «traduction» dans la table article et la
table rubrique.

Pour un article (resp. une rubrique) donné(e), cette colone
contient l'identité de l'article (resp. de la rubrique) dont il
(resp. elle) est la traduction. Un article (resp. une rubrique)
dont la colonne «traduction» contient son propre numéro, signifie
simplement que l'article (resp. la rubrique) n'est la traduction
d'aucun autre article (resp. rubrique). (à mettre par défaut lors
de la création d'un article)

Ce système permet de créer des liens, pour un article
(resp. rubrique) donné(e), dans une langue donnée, vers les
versions du même article (resp. rubrique), dans d'autres
langues.

Dans ce système, il faudra que le fichier d'administration qui
affecte un article X, en une langue xx, comme étant la traduction
d'un autre article Y, qui est écris en langue yy, s'assure:
- que la langue yy est différente de la langue xx, sinon cette
  affectation échouera.
- que l'article Y, n'est pas lui même la traduction d'un article
  Z. Auquel cas, il faudra affecter l'article X comme étant la
  traduction de l'article Z.
- qu'il n'existe déjà pas de traduction de l'article Y (ou Z)
- qu'il n'existe déjà pas de traduction de l'article Y (ou Z)
  dans la langue xx.

Michaël

4

ARNO* wrote:

(1) Comme l'indique Gilles (et comme on me l'a rappelé dans diverses
conversations de webmestres qui attendent une telle fonction), les
fonctions multilingues impliquent qu'on puisse indiquer d'un article
est la traduction d'un autre, afin de pouvoir proposer un lien direct
vers les autres versions.

Ouhlala, heu :

- à moins de trouver une méthode géniale, ça implique de tester
chaque article lors de l'affichage d'une liste dans l'espace public,
donc très lent.

- nécessité de définir comment ce sera pris en compte dans l'espace
public : affichage direct du bon article ? affichage de toutes les
versions avec un message devant ?....

- énorme problème d'interface dans l'espace privé : déjà que certains
(...) se plaignent de la taille des pop-ups de choix de rubrique,
si on fait des pop-ups de choix d'article, c'est la fin...

De plus, je ne suis pas sûr de l'utilité de la chose : quand on
navigue dans un site multilingue, on choisit sa langue une fois
pour toutes, on ne passe pas son temps à sauter d'une traduction
à l'autre. Non ?

Par contre, ce qui me semble beaucoup plus faisable, c'est de pouvoir
régler pour chaque rubrique le mode de fonctionnement du multilingue
dans le site public :

- tout afficher (par défaut)
- ou n'afficher que les articles correspondant à la langue du visiteur

Ainsi on peut régler depuis l'interface de l'espace privé, quelles
rubriques sont sujettes à filtrage automatique par la langue.

Sans cette fonctionnalité, le multilingue pourrait déjà très bien se
gérer avec les mots-clés

Oui, mais dans l'optique d'un SPIP accessible à tous, c'est pas
génial de devoir recourir à ce genre de bidouilles... (sans compter
que tu ne peux pas associer de mots-clés à une rubrique). D'autre part,
ça ne règle pas le problème de la sélection automatique des articles
dans l'espace public.

(2) Si on introduit des fonctionnalités multilingue dans SPIP, plutôt
que de se contenter d'une utilisation des mots-clés, c'est donc
notamment parce qu'on veut (en plus des correspondances entre les
traductions d'un même article) modifier les comportements
typographiques et des dates. "1er janvier 2001" devenant "January
1st, 2001" en anglais. Là aussi, gros bordel en perspective. Comment
configurer pour toutes les langues?

Bien sûr, mais de façon tout à fait pragmatique, le but est de pouvoir
faire des sites en anglais et en français. La typo française est
déjà là, la typo anglaise devrait être très facile à faire (à peu
près la même que la française, mais avec des règles en moins), et
pour les dates ça ne devrait pas poser trop de problèmes. C'est comme
pour l'internationalisation de SPIP : de notre côté, on produira
sûrement une version anglaise, pas plus. Aux contributeurs d'ajouter
ce qui manque, si ça leur dit.

Et pour les langues non supportées :

- typo vide (i.e. aucune transformation)
- dates numériques : 15/09/2001 et non Monday, September 15th

5

ARNO* wrote:

(1) Comme l'indique Gilles (et comme on me l'a rappel=E9 dans diverses
conversations de webmestres qui attendent une telle fonction), les
fonctions multilingues impliquent qu'on puisse indiquer d'un article
est la traduction d'un autre, afin de pouvoir proposer un lien direct
vers les autres versions.

Ouhlala, heu :

H=E9 ben je l'aurais pas dit mieux :-))

C'est exactement ce que je voulais souligner: soit on trouve des
solutions g=E9niales, soit on h=E9rite d'une usine =E0 gaz. D'o=F9 le fait d=
e
voir tous les param=E8tres avant de se lancer dans le multilingue.

De plus, je ne suis pas s=FBr de l'utilit=E9 de la chose : quand on
navigue dans un site multilingue, on choisit sa langue une fois
pour toutes, on ne passe pas son temps =E0 sauter d'une traduction
=E0 l'autre. Non ?

Ben non, =E7a me semble m=EAme le truc le moins int=E9ressant dans le cadre
du multilingue: si tu veux n'afficher que l'anglais ou le fran=E7ais,
tu te contentes de faire des rubriques diff=E9rentes, ou alors
carr=E9ment tu montes plusieurs sites. Un site multilingue, c'est
justement pour que les utilisateurs polyglottes puissent consulter
des articles dans plusieurs langues.

Les webmestres qui m'ont caus=E9 de fonctionnalit=E9s multilingues, =E0
chaque fois c'est pour pouvoir afficher des petits drapeaux qui te
permettent de passer imm=E9diatement =E0 la traduction du texte dans une
langue =E9trang=E8re. Celui qui attend le plus une telle fonctionnalit=E9,
si je ne me trompe, c'est le webmestre des affaires =E9trang=E8res. Je
suppose que, pour de tels sites internationaux, il est tr=E8s pratique
de pouvoir consulter un article dans sa langue courante, et de
pouvoir obtenir d'un clic la traduction du document =E0 faire parvenir
=E0 un interlocuteur =E9tranger (genre un document en japonais expliquant
comment obtenir un visa pour la France; si tu causes pas le japonais,
tu consulte la version fran=E7aise du site, tu cliques sur le logo
nippon, et tu as ton document illico; si tu devais passer par la
navigation du site enti=E8rement en japonais, tu n'y arriverais
jamais); autre raison plausible: tu lis le texte en fran=E7ais parce
que =E7a va plus vite, mais ensuite tu as besoin de voir l'original
pour travailler en =E9vitant les possibles contresens introduits par la
traduction (ou alors, parce que tu fais ton rapport en anglais et
qu'il serait tr=E8s con de traduire en anglais la traduction fran=E7aise
d'un original anglais - suis-je clair? :-)). Pour le multilingue, il
me semble qu'il faut sortir du cadre du webzine d'information auquel
on est habitu=E9, parce qu'en gros, de tels webzines ne font pas de la
traduction syst=E9matique de tous leurs textes et du coup le
multilingue rel=E8ve du gadget (Samizdat est d=E9j=E0 multilingue, y'a du
fran=E7ais et de l'anglais m=E9lang=E9s, et =E7a se passe tr=E8s bien sans
fonctionnalit=E9s sp=E9cifiques). Il faut penser plut=F4t =E0 des sites
destin=E9s =E0 =EAtre des outils de travail pour certaines communaut=E9s
internationales (les affaires =E9trang=E8res et ses ambassades par
exemple; mais aussi des ONG internationales, des communaut=E9s
scientifiques, etc.), qui doivent r=E9ellement manipuler de la
documentation en plusieurs langues et pouvoir passer de l'une =E0
l'autre rapidement.

ARNO*

6

Re-hello,

Pendant que je teste un peu la future beta9, je réponds ;))

Voici grosso modo les usages que je peux voir à un système multilingue
comme je le propose :

- typo, dates (etc ?) spécifiques à chaque langue (dans la limite
des langues supportées :-))

- possibilité de définir des rubriques où les articles et rubriques
sont, dans l'espace public, automatiquement filtrés selon la langue
et les préférences du visiteur à cet égard

- pour les rubriques non filtrantes, possibilité d'utiliser un critère
{lang} dans les boucles. Ainsi on peut afficher, d'abord la liste des
articles dans la bonne langue, puis en-dessous (en utilisant les
doublons), d'éventuels articles dans d'autres langues, de façon séparée.
Présentation plus claire, ce qui est quand même vachement utile et
dans les buts de SPIP.

Heu, l'accès direct et immédiat à la traduction d'un article ne me semble
pas primordial. Tant qu'il suffit d'un ou deux clics dans la structure
du site (retourner à la rubrique ou changer de rubrique), ça me semble
suffisant. Après, ça relève de la gestion de la documentation, qui
n'est peut-être pas exactement le champ de SPIP (heu, enfin, tel que
je le vois....) : pour s'adapter à un autre domaine, un webmestre peut
toujours faire des bidouilles (indiquer l'URL de l'article original
en post-scriptum, que sais-je...).

Ceci dit, ce serait sympa d'avoir l'avis de ceux qui sont intéressés
par ce genre de fonctionnalités. D'autre part, si les liens de type
"traduction" sont la seule chose intéressante dans le multilingue,
il vaut mieux abandonner car ce sera imbouffable à gérer ; ne serait-ce
que niveau performances, je suis absolument contre (sauf si on nous
file une méthode indolore, of course).

Mais quand même, dans l'optique d'un SPIP un jour internationalisé, il
faudra quand même au minimum pouvoir changer la typo française en typo
anglaise (que les angliches ne se retrouvent pas avec des espaces
insécables devant leur deux-points, points-virgules, etc. ;-)).

a+

Antoine.

7

@ Antoine Pitrou (pitrou@free.fr) :

Mais quand même, dans l'optique d'un SPIP un jour internationalisé, il
faudra quand même au minimum pouvoir changer la typo française en typo
anglaise (que les angliches ne se retrouvent pas avec des espaces
insécables devant leur deux-points, points-virgules, etc. ;-)).

Hé les amis, ça fait déjà n versions que ça marche ! Il suffit de
positionner dans "mes_fonctions.php3" une ligne :

    $lang="en";

Ce que j'utilise en 1.0.4 sur http://www.en.monde-diplomatique.fr/
Bon, du coup la fonction typo() ne fait rien, mais il y a tout le code
nécessaire dans inc_texte.php3

-- Fil

8

Bonsoir,

Un site multilingue, c'est justement pour que les utilisateurs
polyglottes puissent consulter des articles dans plusieurs langues.

Tout à fait, et pas forcément les mêmes langues pour tous les
articles, ne serait-ce qu'à cause de la rare synchronisation des
travaux de traduction.

Serait-il envisageable d'utiliser pour identifier un article (ou une
breve, une rubrique, ...), non pas juste un id numérique, mais le
couple id numérique + code ISO de localisation ?

Ainsi :

- les traductions sont faciles à trouver puisque ce sont toutes les
  publications ayant le même id

- les doublons de traduction sont impossibles

- en cas de non disponibilité de la version dans la langue "préférée"
  de l'utilisateur, on peut lui proposer celle qui lui conviendra
  probablement (avec la méthode dont on avait déjà discuté), ainsi que
  la liste des autres versions

- Dans le cache, on a un fichier par couple id + langue

- On ne gère pas de langue "préférée" dans les listes pour chaque
  référence (ce serait trop coûteux et demanderait de gérer un cache
  par utilisateur), mais on propose (a l'admin ou à l'utilisateur ?)
  soit la liste exhaustive toutes langues confondues, soit juste une
  langue

Ce ne sont que quelques idées jetées en pature à vos esprits plus à
même de juger de l'impact sur le source actuel ... :slight_smile:
  
-Nicolas

9

Fil wrote:

Hé les amis, ça fait déjà n versions que ça marche ! Il suffit de
positionner dans "mes_fonctions.php3" une ligne :

    $lang="en";

Oui bien sûr, mais si tu veux le restreindre à une rubrique ou
un article particulier....

10

Coucou,

J'ai un peu survolé le code de Postnuke, le tout nouveau
concurrent de php-nuke. Ca n'a pas l'air génial. Ainsi, les
tables de leur base ne contiennent même pas les bons index
pour ça aille vite (à côté de ça, ils essaient d'optimiser
leurs requêtes en faisant des JOIN explicites... Hem ;-)).
Et comme il n'y a pas de cache, burp (d'ailleurs, le fichier
robots.txt livré par défaut est assez marrant, il interdit
tous les moteurs de recherche sur tout le site : pratique
pour être référencé...).

Bref, si j'ai regardé Postnuke, c'était surtout pour voir
comment le multilingue était géré (car une grande nouveauté
de Postnuke par rapport à son frangin, c'est le multilingue).
Chez eux, c'est tout simple : si un article n'est pas dans
la bonne langue, il n'est pas affiché. Et ça ne sert même
pas pour le réglage de la typo, vu qu'il n'y a pas de typo.
Bon, vu le reste du produit, je n'irai pas jusqu'à conclure
que leur solution est la bonne....

a+

Antoine.

11

Antoine Pitrou wrote:

> (1) Comme l'indique Gilles (et comme on me l'a rappelé dans diverses
> conversations de webmestres qui attendent une telle fonction), les
> fonctions multilingues impliquent qu'on puisse indiquer d'un article
> est la traduction d'un autre, afin de pouvoir proposer un lien direct
> vers les autres versions.

Ouhlala, heu :

- à moins de trouver une méthode géniale, ça implique de tester
chaque article lors de l'affichage d'une liste dans l'espace public,
donc très lent.

D'après ce que j'ai proposé hier:

Rajouter une boucle langue, des balises qui contiennent
les liens vers les rubriques, ou articles, qui sont les
traductions de la rubrique, l'article courrant.

Cela se ferait dans une boucle sur genre:
select lang, id from (rubriques|articles) where
  traduction='traduction_groupe_id'

Dans laquelle traduction_groupe_id serait la valeur de la
colonne traduction de l'article (resp. rubrique) courante.

Cela serait-il si lent?

- nécessité de définir comment ce sera pris en compte dans l'espace
public : affichage direct du bon article ? affichage de toutes les
versions avec un message devant ?....

On ne change pas du tout ce qui existe actuellement, avec
seulement un paramêtre langue dans les boucles articles
et les boucles rubriques. Ce sont les templates qui indiquent
si on affiche les traductions de la rubrique ou de l'article.

- énorme problème d'interface dans l'espace privé : déjà que certains
(...) se plaignent de la taille des pop-ups de choix de rubrique,
si on fait des pop-ups de choix d'article, c'est la fin...

Les choix des rubriques sont faits dans des «select box», pas
des pop-up, ou alors cela a changé dans la version 1.2.
Cela dit, je n'ai pas d'idée particulière pour l'interface d'admin
effectivement.

Cordialement

Michael Parienti