Discussion autour de _T_ou_typo()

Bonjour,

Plusieurs fois on nous a fait la demande d'intégrer la fonction 
_T_ou_typo() au Core. Cette fonction est actuellement définie dans les 
plugins Bonux et/ou Saisies.

Elle a comme usage principal d'appliquer la fonction typo() sur le texte 
qui lui est envoyé, ou récursivement sur chaque valeur si un tableau lui 
est donné.

Et, si un des textes est de la forme "<:cle_de_langue:>" ou 
"<:module:cle_de_langue:>" (une forme simple de l'écriture de chaîne de 
langue dans les squelettes donc), alors c'est la valeur de traduction de 
cette chaîne de langue qui est retourné.

Autrement dit :
_T_ou_typo("Coucou") == "Coucou"
_T_ou_typo("<:module:bonjour:>") == "Coucou" (avec le fichier de langue 
qui va bien quand même)
_T_ou_typo("<multi>[fr]Coucou[en]Hi</multi>") == "Coucou"
_T_ou_typo(["Coucou", "<:module:bonjour:>", 
"<multi>[fr]Coucou[en]Hi</multi>"]) == ["Coucou", "Coucou", "Coucou"]


Cette intégration pose plusieurs questions sur l'usage / le besoin 
d'origine et sur la réponse apportée.

L'usage et solution actuelle
----------------------------

Le besoin est de permettre dans des fichiers de configuration (yaml, 
xml, json) de certains plugins, ou dans des options de configuration de 
certains plugins directement dans l'interface privée de SPIP (Menus, 
Formidable, Champs Extras, ...), de pouvoir indiquer soit un texte 
quelconque, soit de se référer à une chaîne de langue quelque part.

Par exemple, dans une déclaration .yaml d'une saisie, on peut trouver : 
"label: '<:saisies:option_groupe_description:>'". On pourrait utiliser 
pour des saisies spécifiques à un site "label: 'Description'" si on sait 
que le site n'est pas multilingue par exemple.

La difficulté d'utiliser directement le code de langue (ie: label: 
'saisies:option_groupe_description'" qui paraît pourtant plus simple) 
est qu'il est impossible de discriminer les cas où on écrirait un code 
de langue, des cas où c'est réellement le texte voulu, par exemple avec 
"label: 'todo'", qui si on utilise le code de langue retournerait 'à 
venir' (dans spip_fr.php), alors que ce n'était pas forcément ce qui 
serait souhaité.

D'où donc l'apparition de cette écriture "<:truc:muche:>" pour les 
textes de configuration, écriture connue déjà dans les squelettes SPIP, 
avec les nuances qu'on parle bien ici d'une syntaxe simplifiée.
On ne peut pas écrire "label: '<:module:nb_elephants{nb=5}:>'" par exemple.


Proposition
-----------

Dans la petite lumière matinale d'IRC, il m'a semblé ce matin qu'une 
autre solution que d'intégrer et utiliser pour cela _T_ou_typo() 
pourrait être implémentée.

Cette solution consisterait à dire que,
à l'instar de la balise (polyglotte) "<multi>...</multi>" que l'on peut 
écrire à la fois dans les squelettes SPIP et à la fois dans le texte 
d'un article (traité par la fonction typo()), que l'idiome 
"<:module:cle:>" pourrait aussi être traité par typo directement.

Ainsi typo("<:module:bonjour:>") retournerait "Coucou" en allant piocher 
la chaîne de langue correspondante.

La conséquence est que ça permettrait plus de possibilités (on pourrait 
mettre des chaines de langue dans les textes d'articles par exemple)(je 
ne dis pas que ça serait recommandé non plus, mais dans certains cas ça 
serait pratique !), tout en répondant au problème d'origine avec les 
configurations de type .yaml ou d'autres déclarations multilingues.

Qu'en pensez-vous ?

N'étant pas certain des effets de bords que cette solution pourrait 
entrainer pour les plugins concernés, si cette solution semble 
intéressante, peut être à voir du coup pour la version suivante 3.3.
La 3.2 ne cassant pas de choses actuellement dans les plugins hors JS.
Ou pas.

Bon dimanche,

MM.