Project

General

Profile

Evolution #3897

Traduction des configurations (yaml, xml, json) et certains formulaires ( _T_ou_typo )

Added by marcimat 🌻 over 4 years ago. Updated 3 months ago.

Status:
En cours
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
02/06/2017
Due date:
% Done:

0%

Resolution:

Description

Je remets le texte d'un mail envoyé sur spip-devel (comme il n'y a plus de liens gmane pour les voir), sur le sujet parlant de la fonction _T_ou_typo() qui permet de pouvoir traiter des chaînes contenant
  • soit "du texte"
  • soit une "<:chaine_de_langue:>"
  • soit des "<multi>...</multi>"

La fonction _T_ou_typo() 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

Il me semble qu'on pourrait voir la chose autrement, en considérant que toute présence d'un idiome doit être transformé par la fonction typo().
La fonction typo() traite déjà en fait le cas des polyglottes <multi>...</multi> que l'on peut écrire à la fois dans les squelettes SPIP et à la fois dans le texte d'un article.
Il suffirait d'ajouter la gestion de l'idiome <:module:cle:> également. 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 que le besoin d'origine (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 avec les configurations de type .yaml ou d'autres déclarations multilingues : il leur suffirait d'appliquer typo() sans autre question, du moins en théorie.

idiome.patch View (3.98 KB) marcimat 🌻, 02/06/2017 05:36 PM

multi_langue_objet.patch View (1.24 KB) marcimat 🌻, 02/13/2017 08:14 PM

multi_langue_objet.patch View (8.55 KB) marcimat 🌻, 02/13/2017 08:15 PM


Related issues

Related to SPIP - Anomalie #3900: Pouvoir distinguer la langue utilisée dans une boucle entre @<:cle:>@ et @#TEXTE@ Nouveau 02/13/2017

History

#1 Updated by marcimat 🌻 over 4 years ago

Voici un patch qui traite typo() (celui de Textwheel) et ajoute une fonction extraire_idiome() symétrique à extraire_multi()

Un des premiers problèmes soulevés, et que la fonction inc_traduire_dist() utilisée ne sait pas retourner/connaître la langue de la chaîne de langue.
Or, cela permet (pour les multi) de mettre un span indiquant la langue du texte si le texte n'est pas dans la langue désiré au départ.
En permettant d'inclure des chaînes de langues dans les articles, il semble qu'il faille avoir ce comportement également.

Effectivement techniquement la fonction actuelle
1) ne peut retourner que le texte, et pas, par exemple un tableau texte, langue (ça c'est facile à corriger)
2) utilise différents fallbacks lorsque la langue n'est pas trouvée, ou le module de langue pas trouvé
  • si le module de langue n'existe pas, ça utilise le module de la langue du site, sinon le module de langue 'fr' (langue par défaut)
  • avec ce module, si la clé de langue n'est pas trouvé, ça va utiliser le module de la langue du site, sinon le module de langue fr (langue par défaut)
    En gros, il y a 2 endroits où il faudrait pouvoir connaître et retourner la langue utilisée, dans i@nc_traduire_dist() et dans @charger_langue()

Ce premier patch ne gère pas donc ce span de langue.

D'autre part, peut être que ce comportement d'englober du span de langue doive être débrayable, pour l'utilisation de ce nouveau typo() pour gérer les configurations yaml ou autres, mais je n'en suis pas certain.
Mes premiers tests de ce patch en tout cas ont montré que sans rien changer d'autre, les plugins saisies, champs_extras semblent fonctionner tout pareil (assez logique vu qu'ils utilisent une version de _T_ou_typo() qui applique typo seulement s'il n'y a pas de multi ou d'idiome…). Toujours est-il que cette nouvelle possibilité ne semble pas casser les plugins existants sur lesquels justement cela pourrait avoir un impact, donc c'est déjà une bonne chose.

#2 Updated by marcimat 🌻 over 4 years ago

  • Project changed from SVP to SPIP

#3 Updated by marcimat 🌻 over 4 years ago

j'en ai envoyé un morceau par erreur avec https://core.spip.net/projects/spip/repository/revisions/23398 !

#4 Updated by Maïeul Rouquette over 4 years ago

a mon sens ta proposition est jouable. Mais il faut faire attention à échapper les code, cadre quote etc.

#5 Updated by marcimat 🌻 over 4 years ago

C'est déjà le cas

#6 Updated by marcimat 🌻 over 4 years ago

enfin pour cadre et code … j'ai pas testé quote

#7 Updated by b b about 4 years ago

Todobien, +1 pour l'intégrer.

Pour ce qui est des quote, je ne comprends pas pourquoi ils devraient être échappés, autant ça me parait logique de le faire pour les extraits de code, mais pourquoi devrait-on échapper les citations ?

#8 Updated by Maïeul Rouquette about 4 years ago

Effectivement, quote n'a pas être échappé. Sauf si on imagine un cas très particulier, si on cite un ouvrage qui utilise une syntaxe proche des chaînes de langues. Il y a des choses qui s'en rapproche (sans être identique) dans certeines éditions de texte anciens. On ne peut pas exclure la possibilité que cela existe. Mais on peut peut être s'en sortir de manière plus sûr en permettant d'échapper uniquement la chaîne.

#9 Updated by marcimat 🌻 about 4 years ago

  • Related to Anomalie #3900: Pouvoir distinguer la langue utilisée dans une boucle entre @<:cle:>@ et @#TEXTE@ added

#10 Updated by marcimat 🌻 about 4 years ago

Un patch qui est capable d'obtenir la langue utilisée pour $traduire.
Ça modifie pas mal inc_traduire_dist()

#11 Updated by marcimat 🌻 about 4 years ago

Hum, il manquait un morceaeu du diff.

#12 Updated by marcimat 🌻 about 4 years ago

J'ai envoyé ce patch donc https://core.spip.net/projects/spip/repository/revisions/23469 pour obtenir la langue de la traduction.

Il reste à faire :
- appliquer extraire_idiome() sur typo() du Core
- appliquer extraire_idiome() sur typo() de Textwheel

#13 Updated by marcimat 🌻 about 4 years ago

  • Status changed from Nouveau to En cours
  • Target version changed from 4.0 to 3.2

#14 Updated by RastaPopoulos ♥ over 2 years ago

Reste que _T_ou_typo() est récursive quand on lui envoie un tableau, à l'infini. Mais pas typo() tout court, donc impossible actuellement de remplacer avec la nouvelle version améliorée fournie par SPIP. Faudrait une autre fonction toute bête typo_recursive() qui fait juste le test string ou array et fait typo en cascade, peut-être.

#15 Updated by RastaPopoulos ♥ over 1 year ago

Il y a une deuxième différence, avec le récursif, c'est le fait qu'avec le paramètre supplémentaire (pour l'instant "multi") la fonction _T_ou_typo() n'applique alors typo() QUE si besoin = que si on trouve au moins un truc à traduire vraiment.

Car pour le cas d'utilisation principal de _T_ou_typo(), ça s'applique EN MASSE sur tableau d'options, dont on ne connait pas le détail (on peut absolument pas préciser sur telle clé on veut l'appliquer et pas sur telle autre). Or dans ces options, il a des chaines humaines et d'autres paramètres. Et sur ces paramètres non humain, on ne veut pas du tout appliquer typo() ! Car il fait pas que traduire si nécessaire, ça ajoute aussi des espaces, des entités HTML, etc. Et donc ça peut totalement niquer certains paramètres qui ne doivent pas du tout être transformés.

Donc même si typo() était récursif sur un tableau (ou si on faisait une fonction typo_recursive), ça n'irait pas du tout. Car il faudrait pouvoir faire un truc du genre typo($chaine_ou_tableau, $seulement_si_trad), ce que fait exactement _T_ou_typo().

#16 Updated by RastaPopoulos ♥ over 1 year ago

Et donc pour résumer : actuellement depuis 3.2, c'est super, on peut appeler des chaines de langue dans les #TEXTE, mais en revanche, rien pour ce ticket, on ne peut absolument pas remplacer _T_ou_typo($chaine_ou_tableau) par typo($chaine_ou_tableau).

#17 Updated by cedric - 3 months ago

  • Target version changed from 3.2 to 4.0

ça a l'air bien !

Also available in: Atom PDF