Carnet Wiki

Plugin Multilang

Version 5 — April 2010 — olivier

Gestion des tags multi dans l’espace privé

Ce plugin a été initié par Renato en 2009. Son “cœur” est le fichier multilang.js
A l’origine il ne fonctionnait que sur les pages d’édition des rubriques. Le fichier multilang.js était stocké dans prive/javascript mais sans être utilisé nulle part dans le core... Manque l’historique du pourquoi.

Pour l’instant cet article n’est pas une documentation utilisateur mais plutôt des notes de développements, donc à caractère technique.

Le plugin nécessite les plugins suivants :

-  Bonux
-  CFG
-  Saisies

Fonctionnement

Une fois activé, tous les champs input:text et textarea sauf ceux des forms .form_upload et .form_upload_icon sont traites dans :
-  articles
-  rubriques
-  configuration du site
-  auteurs (intéressant uniquement pour le champs BIO)
-  documents dans les colonnes de gauche des pages d’édition d’articles et de rubriques
-  documents dans les parties basses des pages de présentation des articles et rubriques
-  groupe de mots clés
-  mots clés
-  sites
-  brèves

Le traitement consiste à rajouter un menu de lang au dessus du type [fr] [en] [it] de chaque formulaire, en fonction des langues activées dans la configuration du site. Le clic sur une langue, bascule le contenu de tous les champs éligibles du formulaire dans la langue choisie. Le résultat est sauvegardé sous la forme “multi” de spip, à savoir <multi>[fr]texte français[en]English text</multi>. Si le plugin est désactivé, l’ensemble reste donc compatible spip. C’est donc juste une aide à la rédaction.

Un champ “num” est rajouté au dessus des champs #titre (articles, rubriques, mots clés) et #titre_documentXX pour saisir le numéro de l’objet (sans le point qui est rajouté automatiquement)

Une image est rajoutée en background de chaque champs traité et indique son état :
-  no multi : pas de multi dans le champ
-  multi (barré) : multi désactivé dans ce champ
-  multi fr : texte affiché actuellement en français
-  multi en : texte affiché actuellement en anglais
-  faudra rajouter les autres ou trouver une autre astuce

Champs éligibles
-  input:text
-  textarea
-  select
-  ...?

Les champs contenant du texte (autre que espace, tab, retour) en dehors des multi ne sont pas traité.

Marche pas complètement bien - - - -

A l’upload d’un document, le menu de lang ne s’affiche pas, il faut recharger la page pour qu’il apparaisse. Il apparait très complexe d’essayer de résoudre ce problème... Utiliser La raison pour laquelle je ne peux pas utiliser ce plugin , qui sinon serait très utile , est toujours la médiathèque si cela pose trop possibilité de * perte de soucis ... données *.

A tester :
-  Suggestion de RastaPopoulos : “J’avais une idée supplémentaire pour que ce soit extensible : activer également ce système sur tous les champs ayant une classe multilang”.
Fait, a tester par les “editeurs” de plugins avec class “multilangclass” sur les champs à traiter. Le plugin va chercher ensuit le “form” parent pour lui rajouter le menu de langues

A faire :

-  Gérer le numéro de titre dans un autre champ
-  F&T : problème de doublon avec forms_lang.js qui est un dérivé du fichier multilang d’origine.
-  Integration avec Porte-Plume : quand on change de langue, la previsu “Voir” ne bascule pas
-  Trouver une possibilité de pouvoir copier l’intégralité du champ (avec la structure multi) pour pouvoir la copier ailleurs

Plugin multilang - retour d’expériences - Paolo

Par ex. j’ai un article dont le champs texte est composé d’un dans une quinzaine de langues suivi de (en dehors du multi) un modèle qui insère des images :
<gallery|id_article=2835|filename=on>

Si tu ouvre l’article en mode édition, alors :
-  1) tu ne peux pas accéder au raccourci du modèle pour le changer.
-  2) si tu sauves l’article le modèle (c’est à dire tout texte en-dehors du multi) est viré. Tu l’as perdu. Aucune image n’apparaît plus sur la page publique.

Que penses-tu de l’idée de Renato pour éviter cette situation ? —
« Une solution a le probleme d’une perte de donness peut etre
d’interdire le script sur touts le champs ou il y a un <multi> que ne
prends pas tout le champ. »

Une autre remarque : dans l’état actuel l’interface ne t’avertit pas si un <multi> existe ou non sur un champ. En fait il est très facile à créer un multi sans le vouloir ! Suggestion : est-ce que les raccourcis de langues pourraient apparaître seulement lorsque le curseur est dans un champ qui contient déjà un <multi>? Et la création d’un <multi> doit passer, au début, par mettre “<multi> ... </multi>” manuellement dans un champ ?

- - - -

Encore une : le plugin semble contenir une confusion entre la *langue principale* du site et la *langue de l’article*. Voici une expérience :

Sur un site dont la langue principale est anglais, j’ouvre un article estonien.
-  au début la langue indiqué par mulitilang est “[en]” (devrait être plutôt [et] je pense)
-  je change la langue en [et], ajoute quelques mots et sauvegarde l’article. En regardant avec phpMyAdmin, je vois qu’un <multi> n’a pas été créé.
-  je rechange en [en] et change quelques mots : toujours pas de création de <multi>.
-  je change la langue en [fr] et efface tout le texte pour y insérer « Allo !».

Résultat dans la base de données : création d’un <multi> comme celui-ci :
<multi>[en] ... tout mon texte[fr]« Allo ! »</multi>. Rien donc en [et] qui est la langue de l’article !