[spip-dev] #PLUGIN et infos_paquet (SPIP 3.0 ou 3.1)

Dev
1

Hello,

Contexte : utilisation de la balise #PLUGIN pour un plugin utilisant un paquet.xml

Quand on utilise la balise #PLUGIN pour récupérer les informations de description du plugin qui peuvent être traduites, soit nom, slogan et description, la valeur de retour est pour ainsi dire inutilisable. En effet, soit le plugin Crayons, on obtient :

#PLUGIN{CRAYONS, nom} = Crayons // Quelque soit la langue demandée
#PLUGIN{CRAYONS, slogan} = crayons_slogan // c’est à dire l’item de langue du module paquet-crayons_xx.php
#PLUGIN{CRAYONS, description} = crayons_description // c’est à dire l’item de langue du module paquet-crayons_xx.php

Donc, la valeur retournée n’est pas cohérente d’une info à une autre puisque le nom est celui inscrit dans paquet.xml (donc non traduit) alors que pour le slogan et la description on récupère l’item de langue dans le module paquet-crayons_xx.php.

Même si le fichier paquet-crayons_xx.php contient l’item crayons_nom permettant de traduire le nom du plugin, cet item n’est jamais utilisé.

En effet, cela vient de la fonction infos_paquet qui stocke ces valeurs sans se poser plus de question. Il n’est donc jamais possible actuellement d’afficher le nom du plugin dans une autre langue en utilisant #PLUGIN.

Deux solutions pour corriger ce souci :

  1. Modifier la fonction info_paquet afin de stocker dans chacun de ces index (nom, slogan ou description) la chaine traduite dans la langue courante. Ce devrait être la meilleure solution mais je ne sais pas si cela ne peut pas poser des soucis avec le cache.

  2. Faire le traitement dans la balise #PLUGIN et si on est en présence de l’info nom, slogan ou description, aller chercher directement la traduction si elle existe, sinon on appelle le filtre info_plugin comme actuellement.

J’ai codé ce patch est cela fonctionne très bien.

Des avis ?

2

Yop

Si j'ai bien compris les 2 options, la 2 me semble plus logique en
terme de fonctionnement.
Quand on a une chaîne de langue, on charge la traduction selon le
contexte de langue de la boucle ou du squelettes. Selon cette logique,
il semble pertinent que ce soit à la balise PLUGIN de retourner la
bonne information selon le contexte de langue.

Km

3

Yo,

4

Hello,

Et donc, pour le SAD, il faudra qu’on connaisse le nom de notre plugin traduit dans toutes les langues offertes avec le plugin?

5

Je ne comprends pas le sens de ta remarque.

Si c’est de dire qu’il ne fallait autoriser à traduire le nom des plugins cette discussion est terminée depuis longtemps et le but n’est pas de la rouvrir.

Si c’est autre chose peux-tu m’expliquer ce que tu veux dire stp ?

6

Re,

Oui, il m’a semblé que le résultat de la discussion sur la traduction du nom du plugin a terminé sur “on ne traduit pas le titre”.
De ce fait, je ne comprends le but de ton message initial parlant de la traduction du nom d’un plugin. Est-ce bien cela le but? Ou est-ce la mise en place de la mécanique de traduction avec le balise #PLUGIN?

7

Ben non,

La discussion sur la traduction du nom du plugin a débouché sur on permet la traduction du nom du plugin.

Tu en as d’ailleurs pas mal aujourd’hui comme ça.

D’où mon message.

8

Ok.
Donc, dans le but initial de ton message, je préfère la solution 2 que tu as proposé.