Plugin Multilang

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és 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 médiathèque si cela pose trop de soucis...

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 :

-  <del > Gérer le numéro de titre dans un autre champ </ del >
- F&T : problème de doublon avec forms_lang.js qui est un dérivé du fichier multilang d’origine.
-  <del > Integration avec Porte-Plume : quand on change de langue, la previsu « Voir » ne bascule pas </ del > Merci Kent1
-   < del > Trouver une possibilité de pouvoir copier l’intégralité du champ (avec la structure multi) pour pouvoir la copier ailleurs </ del > => Fait  : rajout d’un menu «  no multilang  » a la suite de toutes les langues qui permet de re-afficher la page sans traitement multi

Plugin multilang - retour d’expériences - Paolo

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 !