[spip-dev] [proposition évolution] multilinguisme

Dev
1

Constat (1.7) :
1- seuls les articles sont multilingues
2- les articles en différentes langues ont un Id différents
3- il est possible d'avoir plusieurs traductions dans la même langue (si si)
4- on aimerait tous avoir des rubriques traduites, ainsi que les mots-clés,
les brèves...
pourquoi pas les messages, les syndics et les auteurs (pour la bio).
5- lors de la traduction d'un article, il faut resaisir les mots-clés, les
auteurs. Dans le cas d'articles scientifiques, c'est vraiment lourd. De
plus, on peut se retrouver avec des incohérences entre les différentes
langues.

Choking :wink:
Les points 2 et 3 me "choquent" particulièrement. En effet, un article est
"unique" et même si la langue change, les idées qu'il véhicule sont les même
: c'est un tout.
Dans la même logique, il ne doit y avoir qu'une seule traduction pour une
langue donnée.

Vers la solution proposée (2 étapes) :

1. (ex.: table articles) la clé primaire devient Id_article et Id_lang. On
évite ainsi les problèmes 2 et 3.
Ce principe peut aussi s'appliquer aux rubriques, brèves mots-clés...
On régle aussi le problème 5 (les auteurs, mots-clés sont saisis pour
l'article (Id), indépendemment de la langue).
Par contre, il y a un gros inconvénient : on perd l'incrémentation
automatique de l'Id

On factorise les tables existantes, ce qui allège la "lecture" de la base
existante :
En route pour l'étape 2 :

2. Abracadbra :slight_smile: On crée une table Objet avec 2 champs : Id et Type
Id est un entier autoincrémentable.
Type contient "article", "mots-clés", "rubrique", "brève"...

Les champs Id_ de rubriques, brèves... perdent leur autoincrémentation.
On ajoute le champ lang et on modifie la clé primaire.

Là où la factorisation intervient, c'est au niveau des indexes du moteur de
recherche :
- actuellement, on a une table index_dico et "N" tables quasi identiques
index_ (une par type d'objet : articles, breves, rubriques...)
- on garde la table index_dico (en lui ajoutant un champ "lang" ?), et une
seule table index_objet avec les champs suivants :
  - hash
  - points
  - id

Voilà :slight_smile:

Je vois un problème pour auteur car il faut resaisir le nom, mais il peut
être différent suivant la langue :
Mao Tsé Toung (fr),
Ben Laden (fr); Bin Laden (en)

Quand pensez-vous ?

Amicalement,
Yves

2

Choking :wink:
Les points 2 et 3 me "choquent" particulièrement. En effet, un article est
"unique" et même si la langue change, les idées qu'il véhicule sont les même
: c'est un tout.
Dans la même logique, il ne doit y avoir qu'une seule traduction pour une
langue donnée.

Si c'est le seul problème, il "suffit" de rajouter un petit test dans le
code pour s'assurer qu'une traduction dans la même langue n'a pas déjà
été faite... Rien de très méchant, et cela évite de chambouler la base
de données dans tous les sens.

De plus, avoir un entier unique comme clé primaire pour chaque table
simplifie énormément les choses, d'un point de vue technique (notamment
pour la sauvegarde / restauration de la base de données).

Là où la factorisation intervient, c'est au niveau des indexes du moteur de
recherche :
- actuellement, on a une table index_dico et "N" tables quasi identiques
index_ (une par type d'objet : articles, breves, rubriques...)
- on garde la table index_dico (en lui ajoutant un champ "lang" ?), et une
seule table index_objet avec les champs suivants :
  - hash
  - points
  - id

Je ne vois pas trop l'intérêt par rapport à la situation actuelle,
honnêtement... Une table ou 5 tables différentes, ça ne change pas
grand'chose. Les recherches sont même un peu plus rapides avec des
tables spécialisées, plutôt qu'une grosse table unique (si je fais une
recherche sur la petite table des rubriques, je ne me farcirai pas les
entrées associées aux articles).

Je vois un problème pour auteur car il faut resaisir le nom, mais il peut
être différent suivant la langue :
Mao Tsé Toung (fr),
Ben Laden (fr); Bin Laden (en)

Là ça devient carrément ingérable : si un auteur peut être représenté
par plusieurs entrées différentes dans le système, le fonctionnement
n'est plus limpide du tout... Comment fais-tu si le nom de l'auteur
n'est pas renseigné dans la langue de l'article (etc.) ?

a+

Antoine.

3

Si c'est le seul problème, il "suffit" de rajouter un petit test dans le
code pour s'assurer qu'une traduction dans la même langue n'a pas déjà
été faite... Rien de très méchant, et cela évite de chambouler la base
de données dans tous les sens.

Ajoutons qu'un article peut très bien être traduit deux fois dans la même
langue ;^)
Sur www.spip.net/ecrire/trad.php3 j'ai mis une "vue d'ensemble des
traductions" qui permet d'éviter le problème le plus évident (un traducteur
se lance sur un article déjà en cours de traduction par quelqu'un d'autre).
On pourrait éventuellement ajouter ce genre d'outils dans la distrib, à
terme (pour l'instant, ça devrait rester une contrib extérieure, car on n'a
pas encore assez de pratique).

> Ben Laden (fr); Bin Laden (en)

Là on est clairement dans le rôle du filtre spécialisé [(#NOM|trad_auteur)]
avec une fonction trad_auteur($nom) qui regarde la langue d'affichage
(variable globale) et fait les ajustements nécessaires. Pour ce qui est de
traduire les mots-clés, on peut imaginer un système comparable...

-- Fil

4

Est-ce que tu as lu mon mail de cet après-midi? Il me semble plutôt
clair sur ce sujet: SPIP n'est pas massivement multilingue, parce qu'il
n'a pas été conçu dès l'origine pour l'être. Mais cela apporte quelques
avantages.

Les points 2 et 3 sont particulièrement pas graves, si tu veux mon avis,
puisque ça revient à reprocher, pour le coup, au système d'être trop
souple.

Pour le reste des remarques:
- alors il faut tout reprogrammer from sratch. Rendez-vous dans 2 ans
avec un SPIP massivement multilingue;
- la factorisation a du bon, mais aussi énormément d'inconvénients: le
langage de boucle devient monstrueux pour gérer le multilinguisme, on
perd la compatibilité des squelettes précédents, on perd la souplesse
d'affichage des traductions;
- un site massivement multilingue (absolument tout se traduit
directement) peut rapidement tourner à l'usine à gaz; sans rire. il faut
donc repenser intégralement l'interface graphique, et en particulier
introduire des méthodes de limitation drastique de ce qui est affiché.
Là encore, la version actuelle de l'interface graphique est la troisième
refonte totale en trois ans; donc: rendez-vous dans 3 ans.

Bref, avant d'aborder la théorie du code, le mieux serait de monter des
sites multilingues et de voir réellement les limites in situ. Jusqu'à
présent, en situation réelle, ça tient plutôt bien la route, le code est
simple et la 1.7 bientôt prête, sans qu'on ait eu à tout recoder (et à
tout tester dans tous les sens), c'est entièrement compatible avec les
squelettes précédents, les nouvelles méthodes pour intégrer le
multilinguisme sur le site public ne sont pas tuantes (il y a la
difficulté des chaînes du site public, mais on bosse dessus pour la
suite).

Attention à ne pas non plus décider d'imposer des méthodes de site
multilingue selon une seule forme de multilinguisme. Or, généralement,
les systèmes massivement multilingues reviennent à une seule forme
d'utilisation du multilinguisme. En gros: le site produit est censé être
lui-même massivement multilingue (tout est censé être traduit). Or, dans
le contexte des sites sous SPIP, ça n'est vraiment pas le cas souvent.

Pour le point des auteurs non "dupliqués": c'est dans de nombreux cas
une mauvaise idée. Voir le Scarabée (les sources sont accessibles,
j'avais fait un mail expliquant la méthode): l'auteur de la traduction
est indiqué dans le squelette comme "traducteur", l'auteur de l'article
de référence est indiqué comme "auteur du texte original". Si la
traduction comportait les deux auteurs, cet effet serait perdu. Ca n'est
qu'un exemple parmi d'autres besoins possibles et imprévisibles de
l'utilisation du multilinguisme.

Pour la duplication des liens des mots-clés, c'est un peu le même topo.
C'est introduire une duplication d'information qui n'est souvent pas
souhaitable. Pour ce genre de chose, le plus "propre" consiste souvent
tout de même à aller chercher les mots-clés de l'article de référence;
ainsi on n'a qu'à les modifier qu'à un seul endroit et on obtient le
même résultat.

Il faut toujours non seulement imaginer un usage "idéal" (et, pour moi,
l'usage "idéal" et "propre" est de ne pas dupliquer les liens d'auteurs
ni de mots-clés), et laisser la liberté d'un usage imprévu. (Ce qui
revient à ce que je disais précédemment: les systèmes massivement
multilingues ne sont pas forcément ceux qui induisent le plus de
souplesse.)

Amicalement,
ARNO*

5

Gaffe, le petit test risque d'être chéman et/ou carrément bloquer le
système:

- création de traduction: l'interface, pour rester "légère", ne précise
pas "Traduire dans telle langue", mais seulement "Traduire cet article";
donc on ne sait pas dans quel langue est créé l'article; il y a des
règles, vaguement intelligentes, mais en fait pas tellement :-))

- la méthode la plus simple (la moins contraignante pour la gestion
quotidienne) consiste à gérer les langues uniquement dans les rubriques;
donc les articles héritent de la langue des rubriques. Un article change
de langue quand on change de rubrique. Là le test risque de se montrer
carrément bloquant parce que ne tolérant aucune erreur. (Je déplace une
sous-rubrique dans une rubrique dans une autre langue, genre par erreur:
que fait le système, il refuse le déplacement - alors que je pourrais
souhaiter changer la langue de la rubrique -, ou bien il perd les liens
de traduction concurrents?)

- dans la même idée, blocages au démarrage que certains admins prendront
pour un gros bug: genre je lance mon site avec une rubrique en français
et une rubrique en anglais; quelqu'un veut me proposer une traduction en
allemand: non seulement il ne peut pas (parce que la rubrique
correspondante n'est pas encore créée), en plus ça lui est refusé, parce
qu'il existe déjà une version française et une version anglaise.

Enfin bref, ce genre de choses désagréables, quoi...

Sans compter qu'un rédacteur peut trouver une traduction pas terrible et
vouloir en proposer une nouvelle. Dans ce cas, la présence de plusieurs
traductions dans une même langue n'a rien d'insupportable. A charge,
comme toujours, pour les admins, de vérifier la cohérence lors de la
validation.

6

En fait, le seul truc qui m'inquiète réellement là-dedans, c'est plutôt
qu'on ne va pas traîner à voir une utilisation totalement détournée de
ce système, avec risque de solutions catastrophiques (des pseudo listes
d'articles, hein).

Sauf si... enfin... des listes d'articles, pas pseudos, on va bien finir par
s'y mettre :wink:

-- Fil

7

Salut,

Je suis un peu perdu dans la conversation. Je ne sais pas si Arno me
répondait ou si il s'adressait à Fil ?

Mise au point :
J'ai bien aimé vos discussions précédente sur les sites massivements
multilingues.
Ce n'est pas le cas de SPIP et heureusement.

J'avais regardé à l'époque du côté de Glasnost, mais le fait que le site
"gère" les traductions (en utilisant automatiquement un dictionnaire de
phrases) m'avait plutôt rebuté.

Ma proposition ne va pas vers une solution massivement parallèle et n'est
pas incompatible avec les fonctionnements actuels (site avec n arbos //,
site monolingue avec qq articles traduits...).

Bon, je n'ai pas parlé (et trop réfléchi) sur la gestion des URLs, des
squelettes, mais franchement ça ne me parait pas monstrueux.

Effectivement cela implique une réécriture de certaines parties, et je vois
plutôt mon mel comme une contribution au sujet dans la discussion en cours,
pas comme une application effective pour la 1.7 (soit la 1.8, soit la 2.0).

Attention à ne pas non plus décider d'imposer des méthodes de site
multilingue selon une seule forme de multilinguisme.

Je me répète, "ma" solution n'impose rien.

Pour le point des auteurs non "dupliqués": c'est dans de nombreux cas
une mauvaise idée. Voir le Scarabée (les sources sont accessibles,
j'avais fait un mail expliquant la méthode): l'auteur de la traduction
est indiqué dans le squelette comme "traducteur", l'auteur de l'article
de référence est indiqué comme "auteur du texte original". Si la
traduction comportait les deux auteurs, cet effet serait perdu.

Oui et non.
En utilisant des "rôles" sur les auteurs tu y arrives.
D'autre part il serait possible de "garder" le fonctionnement actuel
(auteurs, mots-clés propres à chaque article - lien avec Id seul ou
Id+lang), mais ça serait vraiment très pratique de recopier ces champs liés
lors de la traduction de l'article (mais ça fait du code à rajouter).

Pour la duplication des liens des mots-clés, c'est un peu le même topo.
C'est introduire une duplication d'information qui n'est souvent pas
souhaitable. Pour ce genre de chose, le plus "propre" consiste souvent
tout de même à aller chercher les mots-clés de l'article de référence;
ainsi on n'a qu'à les modifier qu'à un seul endroit et on obtient le
même résultat.

C'est exactement ce que je voulais dire (mais apparemment je n'était pas
très clair).

- la factorisation a du bon, mais aussi énormément d'inconvénients: le
langage de boucle devient monstrueux pour gérer le multilinguisme, on
perd la compatibilité des squelettes précédents,

Pas sûr. C'est une requête SQL avec un filtre (on non) sur la langue.

on perd la souplesse d'affichage des traductions;

Tu veux dire article-10.html et article-11.html en suposant que 10 soit la
rubrique FR et 11 la rubrique EN ?
Rien ne t'empêche de garder cette structure dédoublée (bis repetita).
Mais je me souviens de nombreux messages d'utilisateurs qui trouvaient ça
lourd (et c'est peut-être à cause de ça qu'il n'y a pas beaucoup de sites
SPIP multilingues).

Mais je pense qu'il est possible d'étentre la syntaxe squelette-xx,
squelette=xx :
par exemple squelette.lang-xx ou squelette-xx.lang ...
A voir...

il faut donc repenser intégralement l'interface graphique

Je crois que c'est assez simple :
Tu affiches tes listes d'articles, rubriques toujours de la même façon
sauf...
que tu affiches de préférence la version dans la langue de l'interface et si
ce n'est pas possible, la version "originale de l'article".
Et pour spécifier les versions existantes, tu affiches des petits drapeaux à
coté du titre :
http://localhost/rubrique.php3?id_rubrique=15

A+
Yves

PS : j'avais oublié de compléter des exemples sur les auteurs (ça s'affiche
correctement en utf-8) :
Mao Tse-tung (fr)
Mao Zedong (en)
??? (zh)

ou pour un mot-clé :
Pékin (fr)
beijing (en)
?? (zh)

(pour info, les formes "fr" et "en" sont en fait des translitérations faites
avec deux méthodes différentes, l'une utilisée plutôt par les français,
l'autres plutôt par les anglais)

8

@ Yves Pratter <yves.pratter@laposte.net> :

Mais je pense qu'il est possible d'étentre la syntaxe squelette-xx,
squelette=xx :
par exemple squelette.lang-xx ou squelette-xx.lang ...
A voir...

Euh... C'est déjà prévu comme ça (et ça fonctionne !). Ca n'est pas le plus
pratique (mieux vaut des squelettes multilingues).

Et pour spécifier les versions existantes, tu affiches des petits drapeaux à
coté du titre :
http://localhost/rubrique.php3?id_rubrique=15

Non, pas de drapeaux. Merci de penser aux objecteurs de conscience :wink:
Par ailleurs je n'ai pas accès à ton url (localhost !)

En fait je pense que, quand on fait "écrire une traduction de l'article",
SPIP pourrait recopier les éléments de l'article source dans l'article en
préparation. Je ne sais plus pourquoi Arno+ y était hostile... s'il peut
redire l'argument ? Sinon ça serait très pratique...

-- Fil

9

> par exemple squelette.lang-xx ou squelette-xx.lang ...
Euh... C'est déjà prévu comme ça (et ça fonctionne !).

Donc il n'y a pas de problèmes sur ce point :wink:

(En fait je croyais que c'était une config Apache, pas une possibilité de
SPIP)

Par ailleurs je n'ai pas accès à ton url (localhost !)

oups, http://81.56.244.159/rubrique.php3?id_rubrique=15

Non, pas de drapeaux. Merci de penser aux objecteurs de conscience :wink:

c'est graphique, petit et explicite (du moins pour les langues europèennes;
pour l'arabe c'est moins évident).
Je n'ai pas voulu en parler car il y avait eu un grosse discussion dans ma
boite à ce sujet (mettre un drapeau, les codes iso, les langues "français,
anglais, allemand..." ou "français, english, deutch...")

On peut proposer les drapeaux, libre aux utilisateurs de les remplacer.
J'ai piqué les miens chez Kdevelop : http://www.kdevelop.org/graphics/flags/

Pour trouver les drapeaux par pays (tient on pourrait proposer un groupe de
mots-clés prérempli), il y a la CIA ;-))
http://www.cia.gov/cia/publications/factbook/index.html

Ils sont tous chez moi : http://81.56.244.159/IMG/country/ et j'ai un
fichier utilisable avec wget pour les récupérer :
http://81.56.244.159/IMG/country/flags.txt

En fait je pense que, quand on fait "écrire une traduction de l'article",
SPIP pourrait recopier les éléments de l'article source dans l'article en
préparation. Je ne sais plus pourquoi Arno+ y était hostile... s'il peut
redire l'argument ? Sinon ça serait très pratique...

oui

10

Pour l'auteur, c'est là que je suis le plus certain d'être contre: parce
que l'auteur du texte original n'est pas l'auteur de la traduction. Le
fait qu'on connaisse, dans SPIP, le "texte de référence", permet de
faire des boucles très propres pour différencier directement l'auteur
original et les traducteurs. Si on "recopie" l'auteur d'origine dans la
traduction, on se retrouve, pour la traduction, avec au minimum deux
auteurs, dont on ne sait pas ce qu'ils ont fait.

Pour les mots-clés, à mon avis (là je suis moins catégorique), la
méthode "propre" consiste à afficher sur le site les mots-clés de
l'article de référence, et non de les dupliquer. De cette façon, on ne
modifie les mots-clés qu'à un seul endroit (dans l'article de
référence), et non dans toutes les traductions de l'article. (Cela me
semble d'autant plus vrai qu'on utilise beaucoup de mots-clés, et c'est
justement le cas où l'on est tenté de dupliquer les mots-clés pour se
"simplifier" la vie.)

ARNO*

11

@ Arno* <arno@scarabee.com> :

> En fait je pense que, quand on fait "écrire une traduction de l'article",
> SPIP pourrait recopier les éléments de l'article source dans l'article en
> préparation. Je ne sais plus pourquoi Arno+ y était hostile... s'il peut
> redire l'argument ? Sinon ça serait très pratique...

Pour l'auteur, c'est là que je suis le plus certain d'être contre: parce

.../...

Pour les mots-clés, à mon avis (là je suis moins catégorique), la

Je ne parlais ni de l'auteur ni des mots-clés, car effectivement il est bcp
plus intelligent que ça reste centralisé sur 'article d'origine. Je parlais
du contenu (titre*, chapo, descriptif, texte...). Ca se règle en deux lignes
de code... mais ça ressemble un peu plus encore à "dupliquer cet article" :frowning:

* Pour le titre on pourrait mettre "Traduction de $titre_original"

-- Fil

12

-> Ben, oui, d'abord, ça va faire "dupliquer cet article"; je
suspecterais presque que ça revienne par ce biais sur la liste et que ça
n'a toujours rien à voir avec le multilinguisme. :wink:

-> Dans le cadre du multilinguisme, il n'y a aucun intérêt à insérer des
informations qui sont destinées à être détruites (parce que la
traduction ne conserve rigoureusement rien du texte d'origine).

Le seul cas où il y a des choses à conserver, ce sont les docs
techniques (façon spip.net) où il y a des morceaux de code à dupliquer.
Mais je préfère que dans ce cas spécifique les gens se fassent un petit
peu chier avec des copier-coller (surtout qu'avec "cadre", les morceaux
de code sont ultra-simples à copier-coller).

A*

13

-> Dans le cadre du multilinguisme, il n'y a aucun intérêt à insérer des
informations qui sont destinées à être détruites (parce que la
traduction ne conserve rigoureusement rien du texte d'origine).

Je vois l'intérêt d'avoir cette possibilité:

1) Il y en a qui aime traduire phrase par phrase en effaçant le texte
d'origine au fur et à mesure qu'ils avancent. Ce n'est pas une méthode qui
donne des très bons résultats pour un document littéraire, mais pour
certains documents il est pratique.

2) Parfois le premier traducteur ne sais pas traduire une phrase ou un
paragraphe. Il peut être pratique de le laisser en place dans la langue
originelle - le temps de demander à un autre traducteur de le regarder.
Lorsque ce deuxième achève la traduction il aura l'avantage de voir la
phrase dans son contexte.

3) Certains noms propres (noms de personnes, villes etc.) plutôt exotiques
et qui doivent être recopiés plutôt que traduits seront déjà dans la fenêtre
où on est en train de traduire.

4) Pour traduire les articles Spip, ce serait pas mal de ne pas avoir
toujours à retaper les balises <cadre>,</cadre>, etc.

Paolo