[spip-dev] Developpement multilinguisme

Dev
1

Salut,

Je viens d'effectuer des modifications sur la configuration du multilinguisme. Il y avait un gros défaut, qui était qu'un site ne pouvait être "multilingue" que dans les langues dans lesquelles SPIP a été traduit. Or je peux trÚs bien parler anglais et utiliser ainsi SPIP, mais vouloir publier un site en yiddish et en hébreux. D'où la nouvelle configuration.

L'essentiel des nouveautés est visible sur /ecrire/config-lang (nouvel onglet).

Ca regroupe les réglages de langue précédents (inchangés), et ça ajoute, quand on active le menu de rubrique et/ou le menu d'article, une liste des "langues utilisées sur ce site".

(Note: pour éviter de planter les traducteurs avec des machins pas encore définitifs, j'ai été avare de textes, hein. Y'a quelques textes sucrés/nouveaux, mais pas beaucoup pour l'instant. Evidemment tout cela méritera d'être plus explicite.)

Cette liste est constituée de toutes les langues référencées dans inc- langues (fonction de traduction). Donc un poil bancal, parce que certaines langues sont traduites dans leur langue d'origine, d'autre pas (encore). Les langues pour lesquelles on a installé une traduction de l'interface sont indiquées en couleur (il faut donc les préférer, puisque là on a vraiment les dates et les formulaires bien traduits); ces langues sont sélectionnées par défaut (donc fonctionnement similaire à précédemment au départ).

(Note: j'indique entre parenthÚses et en gris le "code" de chaque langue. C'est nécessaire pour pouvoir repérer des langues qu'on ne peut pas afficher (par exemple, le webmestre d'un site multilingue sait que certains articles seront en arabe et en hébreux, donc il veut configurer le site pour que les participants puissent le faire, même si lui-même ne peut afficher ces langues; il lui faut donc au moins les codes pour s'en sortir) . De plus, accéder ici aux codes des langues sert d'indication pour le développement des squelettes.)

On sélectionne et déselectionne ce qu'on veut, et c'est ça qui est ensuite affiché dans les menus de langue (sauf celui de sélection de l'interface, bien sûr).

ARNO*

2

Salut,

Je continue à bidouiller le multilinguisme.

N.B. Ne pas utiliser sur un site en cours de fonctionnement, hein, c'est à considérer comme extrêmement instable... :slight_smile:

Là , je me suis attaqué à la gestion des langues "héritées". J'ai remplacé la gestion du champ unique "lang" avec des points pour les langues héritées par une gestion avec deux champs: "lang" (qui est trÚs simplifié, du coup, que ce soit en français fixé à la main ou en français hérité, c'est pareil: "fr") et "langue_choisie", qui est fixé à "oui" quand c'est une langue qu'on a fixée à la main, et à "non" quand c'est hérité. (Si je ne me suis pas trompé, lors de la mise à jour, ça convertit les anciens réglages en ".fr" dans le nouveau systÚme.)

Avantages:
- ça simplifie énormément les appels dans les requêtes mySQL, notamment récursives (voir la fonction calculer_langues_rubriques); - ça simplifie également la sélection dans les BOUCLES, puisqu'on n'a plus besoin de jouer avec les expressions réguliÚres pour sélectionner les articles selon une langue (sauf erreur, il suffit de faire "{lang=fr}" pour récupérer les articles en français).

Les menus déroulants de sélection des langues s'enrichissent d'une nouvelle possibilité: choisir "langue du parent" (désolé pour la formulation, faudra trouver mieux...), indiquant que c'est hérité.

Pour l'immédiat, il faut:
- que je sucre l'affichage de l'héritage quand les langues de rubriques ne sont pas activées;
- que j'installe le réglage "intelligent" de la langue lors de la création d'un article.

Truc chiant: avoir utilisé la même fonction menu_langue pour sélectionner la langue d'interface et les langues des articles/rubriques, ça complique énormément le code, bicoz ces menus n'ont rigoureusement pas les mêmes comportements. Je crois que je vais modifier ça.

ARNO*

3

Salut,

Vite fait, bicoz là je sors. Je viens d'uploader le dernier avancement de mes travaux sur le CVS. Boulot interrompu, donc particuliÚrement instable.

- Gestion des langues sur les brÚves.

- Gestion "évoluée" des langues lors de la création d'articles et de brÚves:

     A. Si les langues des rubriques sont activées, automatiquement l'article ou la brÚve hérite de cette langue. B. Si pas de langues- rubriques, alors ça teste si la langue utilisée par l'auteur en interface est une langue "autorisée" sur le site. Si oui, alors hop l'article ou la brÚve est fixée dans cette langue.
     C. Si rien de tout ça, ça hérite de la langue principale du site.

A*

4

(Si je ne me suis
pas trompé, lors de la mise à jour, ça convertit les anciens réglages en
".fr" dans le nouveau système.)

Petite question et gros soucis:

Pour les sites existants multilingues répartis par secteurs (exemple:
français = secteur 1 et anglais = secteur 2), en fixant à la main le secteur
2 à "en", est-ce que tous les enfants (rubriques, articles, brèves)
hériteront de la langue ou faudra-t-il changer à la main pour chaque article
du secteur anglais le ".fr" fixé lors de la mise à jour en ".en"?

André Vincent

5

Je viens d'ajouter une page affichant les statistiques selon les langues. Affichage au choix depuis le début ou "actuellement" (d'aprÚs la popularité).

A*

6

- Dans la configuration des langues, dans le choix des langues "autorisées", la langue du site ainsi que les langues déjà attribuées à des articles publiés ou des rubriques actives ne peuvent pas être déselectionnées. (Y'en a qu'ont essayé, ils ont eu des problÚmes.)

- Quand on change un article de rubrique, si la langue de cette rubrique est héritée (ce qui sera par exemple le cas, systématiquement, si on ne sélectionne que le multilingue par rubriques), la langue est immédiatement changée. (Je préfÚre un code spécifique à cette page plutÎt qu'un recalcul par recalcul_langues_rubriques, qui est nettement plus lourd.)

(Oups, faut que je fasse la même chose pour les brÚves...)

A*

7

Salut,

Je viens d'uploader un systÚme de gestion de liens entre les articles pour gérer les traductions. Il s'agit tout simplement de pouvoir indiquer qu'un article est la traduction d'un autre.

- Dans la page d'un article, sous le choix de la langue, apparaissent deux entrées:

     A. La principale, à droite, est un bouton "Ecrire une nouvelle traduction de cet article". C'est la façon la plus simple de s'y prendre: le nouvel article est directement "lié" au premier en tant que traduction. Tous les rédacteurs peuvent utiliser ce bouton pour proposer une traduction.

     B. La seconde (en interface complÚte seulement), uniquement si article éditable, à gauche, permet d'indiquer qu'un article est la traduction d'un autre article (on indique son numéro). Cette fonctionnalité est indispensable pour rattraper les oublis, et pour mettre à jour un site déjà existant. Messages d'erreur si article inexistant ou déjà lié.

- Les articles ainsi liés apparaissent en tant que "Cet article est la traduction de...". On peut décider de ne plus lier l'article (déplier la case).

- Si on lie un article appartenant déjà à un groupe de traduction à un autre groupe déjà existant, les deux groupes de traductions fusionnent.

- Il n'y a pas de vérification de concurrence des langues (par exemple, un article en français peut être lié à un autre article en français par ce biais - même si ça n'est vraiment pas fait pour). Je ne sais pas si c'est vraiment nécessaire (notamment: ça pose de gros problÚmes de logique: que faire en cas de concurrence?)

- Dans la table, c'est géré trÚs simplement via une colonne supplémentaire dans "spip_articles": "id_trad" (qui n'est qu'un chiffre dans l'absolu, incrémenté par calcul manuel; il n'y a pas par exemple de table "spip_trad" où l'on retrouverait ces "id_trad"). Les articles qui sont la traduction l'un de l'autre ont tout simplement le même numéro de $id_trad. L'avantage de cette méthode est de simplifier à l'extrême les requêtes (notamment dans les requêtes construites par les boucles: il n'y a pas besoin d'un table intermédiaire, on se contente de récupérer le id_trad du contexte).

- Dans les boucles (uniquement de type ARTICLES, puisque seuls les articles sont ainsi liés), il suffit d'utiliser le critÚre {traduction}:
    <BOUCLE_trad(ARTICLES){traduction}{exclus}>
fournit la liste des articles liés à l'article principal (lui-même s'excluant). TrÚs trÚs simple donc.

N.B. J'aurais pu utiliser directement {id_trad} (on peut, mais faut alors préciser aussi {id_trad>0}, mais j'ai préféré créer un critÚre spécifique ({traduction}). En effet, c'est nettement plus explicite, et surtout {id_trad} pourrait laisser penser à de véritables "groupes" de traduction (façon id_mot, id_forum...) alors que ça n'est pas le cas: il ne faut surtout pas essayer de s'amuser à sélection des id_trad (genre {id_trad=3}) parce que ça ne rime à rien (sachant que, de plus, pour un article, les id_trad peuvent changer au cours du temps, notamment lors des fusions de liens).

8

merci ARNO,

tu m'as battu en vitesse, j'était justement en train de créer cette gestion
des liens vers les traductions...
Quels sont les fichiers à télécharger pour utiliser ce mod indispensable ?

9

Passe par le CVS, y'a vraiment une tripotée de fichiers modifiés, y compris dans les langues.

N.B.: à tes risques et périls, hein, c'est de la beta de chez beta; je te déconseille absolument de l'installer sur un site accessible au public pour l'instant.

A*

10

pfffff .... y'en a qui chôment pas pendant les vacances :wink:

vient d'installer la version du jour et je trouve simple et astucieux
le système "traduction de cet article"

je continue à tester pour remonter les éventuels bugs

beau boulot, merci

Amicalement

Nico

11

Hello,

- Si on lie un article appartenant déjà à un groupe de traduction à
un autre groupe déjà existant, les deux groupes de traductions
fusionnent.

Comment un article pourrait-il être la traduction simultanée de deux
autres articles ???

-Nicolas

12

(1) Tout simplement en étant la traduction en anglais d'un article existant déjà sur le site en français, en italien et en volapuk. Nous avons dnoc là un article est qui la traudction simultanée de 3 autres articles.

(2) Si par ailleurs un article dont on a déjà indiqué qu'il était la traduction en hébreux d'un article en arabe et en allemand est indiqué comme étant aussi la traduction du premier article, alors on obtient un seul groupe, indiquant qu'on a des versions en français, en italient, en volapuk, en hébreux, en arabe et en allemand d'un même article.

A*

13

Comment un article pourrait-il être la traduction simultanée de
deux autres articles ???

(1) Tout simplement en étant la traduction en anglais d'un article
existant déjà sur le site en français, en italien et en volapuk.
Nous avons dnoc là un article est qui la traudction simultanée de 3
autres articles.

Je ne connais pas beaucoup de traducteurs qui utilisent plusieurs
traductions d'un même texte comme source pour une nouvelle version,
mais bon ... :wink:

(2) Si par ailleurs un article dont on a déjà indiqué qu'il était la
traduction en hébreux d'un article en arabe et en allemand est
indiqué comme étant aussi la traduction du premier article, alors on
obtient un seul groupe, indiquant qu'on a des versions en français,
en italient, en volapuk, en hébreux, en arabe et en allemand d'un
même article.

OK, c'est surtout dans ce cas alors, très bien.

Du coup, difficile par contre de savoir quel est l'article d'origine,
le premier à avoir été écrit, non ?

-Nicolas

14

Quand la ville dort, Nestoooor

15

Je pense qu'il serait utile de toujours connaitre l'article d'origine...

Si l'on gère les traductions avec un système du style
id_article
id_trad < article père ou traduction de

il serait possible lors de la création d'une traduction de l'article déjà
traduit de mettre en père l'article d'origine...

ex :
article 1 français
article 2 anglais id_trad = 1

article 3 allemand traduction de article 2 mais id_trad = 1

a suivre... ???

@+ Coyote

16

Salut,

J'ai modifié le systÚme de lien entre les articles traduits: l'id_trad utilisé est désormais le numéro de l'article de référence. De cette façon, on reconnait, dans la liste des {traductions}, lequel est l'article d'origine.

- Si vous avez déjà créé des groupes de trad avec la précédente version (qui était ultra-beta), et que vous sélectionnez un nouvel "article de référence" dans cette liste, vous aurez parfois de petites surprises (fusion avec un autre groupe "imprévu"). Le plus simple: avec phpMyAdmin, remettez tous les id_trad=0 avant toute chose et refaites des groupes.

- Du coup, nouvelle "petite" icone dans la liste des traductions d'un article: l'article de reference est indiqué comme tel, avec un petit micro foncé à cÎté. Les autres articles de la liste se voient attribuer un petit micro éclairci; en cliquant dessus, c'est ce nouvel article qui devient l'article de référence.

- Afin de pouvoir jouer avec cette notion d'article de référence, la liste des traductions affiche également l'article en cours, mais sans lien hypertexte.

A*

17

Je viens d'uploader un nouveau critÚre de boucle pour pouvoir sélectionner l'article d'origine d'une traduction: {origine_traduction} (dans une boucle ARTICLES, évidemment). Si vous ajoutez ce critÚre à une boucle, seuls les articles qui sont à l'origine d'une traduction sont affichés.

Vous pouvez voir cela sur le Scarabée:
http://www.scarabee.com/article.html (regardez le source)

Sur le Scarabée, les articles en anglais sont des traductions réalisées par Eric Cotte. J'ai choisi d'attribuer comme auteur "ARNO" à mes propres textes, et "Eric Cotte" aux traductions. Voici ce que j'ai fait pour afficher de maniÚre distincte:
- que je suis l'auteur unique quand ce sont les versions françaises;
- qu'Eric Cotte est le traducteur des versions anglaises, et que je suis l'auteur de la version d'origine.
A priori, cette méthode fonctionne quel que soit le nombre de traductions différentes (je pourrais ajouter des versions en allemand, espagnol... en n'indiquant que le nom du traducteur aux versions traduites).

http://www.scarabee.com/article.html

<BOUCLE_tester_traduction(ARTICLES){id_article}{traduction}>
  <BOUCLE_traduit(ARTICLES){id_article}{origine_traduction}>
    [<p>par (#LESAUTEURS)]
  </BOUCLE_traduit>
    <BOUCLE_auteur_origine(ARTICLES){traduction}{origine_traduction}>
    [<p>by (#LESAUTEURS)]
    </BOUCLE_auteur_origine>
    [<br>translation by (#LESAUTEURS)]
  <//B_traduit>
</BOUCLE_tester_traduction>
  [<p>par (#LESAUTEURS)]
<//B_tester_traduction>

La BOUCLE_tester_traduction détermine si l'article actuel (ici, celui de la boucle principale) est traduit ou non (on sélectionne l'article lui-même par {id_article}, on le prend dans un éventuel groupe de traduction par {traduction}. S'il n'en existe pas de traduction, on va à la fin (avant //B_tester_traduction) et on affiche directement le nom de l'auteur ("par ARNO").

Si cet article est dans un groupe de traduction, alors on passe à l'intérieur de la boucle.

Là , une seconde boucle (BOUCLE_traduit) teste si c'est l'article d'origine (on resélectionne l'article lui-même par {id_article} et on teste s'il est l'article de référence de la trad par {origine_traduction} (la requête mySQL vérifie que id_article est l'article actuel, et que id_article=id_trad).

Si oui (id_article et id_article=id_trad), alors il s'agit de l'article original (sur le Scarabée, on est en train de visiter la version française) , on se contente donc d'afficher le nom de l'auteur ("par ARNO").

Si non (id_article n'est pas égal à id_trad), c'est donc une traduction, et non l'original (sur le Scarabée, c'est donc une version anglaise). Dans ce cas, le nom de l'auteur est affiché en tant que "translation by" (ici, Eric Cotte). J'ajoute ici une petite boucle pour récupérer l'article d'origine et afficher le nom de son auteur (BOUCLE_auteur_origine va chercher, parmi les articles {traduction} celui qui est {origine_traduction}). Cela me permet donc, quand il s'agit d'une traduction d'un article, d'afficher: "by ARNO, translation by Eric Cotte".

Avec ce systÚme, sans modif, si quelqu'un (disons un certain Gunther) me fait une version en allemand, cette version sera, dans l'espace privé, simplement signée par ce "Gunther". Sur le site public, ça affichera: "by ARNO, translation by Gunther".

18

Et si l'auteur de l'article d'origine est aussi le traducteur, le nom
s'affiche deux fois.

Pourrais-tu également mettre à dispo d'autres boucles (ex: comment gérer les
menus...)
les liens vers les autres traductions, etc...

Super boulot, à quand la mise en ligne de la version 1.7 de SPIP ?

19

Et si l'auteur de l'article d'origine est aussi le traducteur, le nom
s'affiche deux fois.

Evidemment. Mais c'est à toi de concevoir ton site comme tu l'entends, avec les boucles dont tu as besoin. Là j'ai simplifié en appelant directement #LESAUTEURS. Mais si tu passes par une boucle (AUTEURS), tu peux affiner.

Pourrais-tu également mettre à dispo d'autres boucles (ex: comment gérer les
menus...)
les liens vers les autres traductions, etc...

Pour les liens vers les autres traductions, c'était dans un message précédent, ça n'a pas changé. Tu utilises le critÚre {traduction} dans une boucle (ARTICLES) et ça te donne ça.

<BOUCLE_trads(ARTICLES){traduction}{exclus}>
<li>#TITRE
</BOUCLE_trads>

Super boulot, Ã quand la mise en ligne de la version 1.7 de SPIP ?

Il n'y a jamais ce genre de calendrier avec SPIP: on code quand on a le temps, alors ça sort quand ça sort.
Pour la 1.7, a priori y'a le temps: ce sont les premiÚres ébauches.

ARNO*