La fonction interne inc_traduire_lang() permet de passer explicitement une langue pour obtenir la traduction d'une chaine. Mais la fonction _T() de plus haut niveau qui est appelée partout et qu'on peut utiliser directement dans les squelettes, elle, ne permet pas ça !
Le patch joint corrige donc ce problème. Il ajoute un argument à la fonction _T() pour pouvoir passer explicitement une langue.
Ce patch casse volontairement la signature existante de _T() car le troisième argument actuel (class) est utilisé UNE fois dans TOUT le logiciel. Il est donc à priori beaucoup moins important que la langue pour une fonction dont c'est le but premier !...
Bien entendu, ça modifie aussi l'unique appel avec "class" dans debusquer.php afin de ne rien casser.
Le patch est pour la 2.1, donc à reporter en trunk aussi.
Pourquoi ne pas considérer que la langue est en fait un argument
implicite de _T, qui aurait sa place dans le second argument $args(),
ce qui permettrait de faire
_T('truc',array(lang=>'en'))
_T se chargeant de d'utiliser ce lang ou le GLOBALS['spip_lang'] le
cas echeant, et de l'enlever des args fournis a _L()
(sous reserve que aucun @lang@ n'existe dans les fichiers de langue)
- Dans la solution de Cédric, s'il n'existe aucun @lang@ dans les chaines de SPIP ou les chaines de la zone, alors ça ne casse rien.
- Dans ma solution, le troisième argument est utilisé UNE fois dans tout SPIP, et nulle part sur la zone. Donc le passer en 4e argument ne casse rien si on modifie le fichier debusquer.php en même temps (ce que fait le patch).
Pourquoi ne pas mettre ce nouvel argument en 4e position afin de ne rien casser ?
Parce que passer explicitement une langue à une fonction dont le but premier est justement de manipuler de la langue, ça parait quand même plus "naturel" que ce soit avant.
Si l'argument "class" était super utilisé, là ok il n'y aurait pas à tortiller, j'aurais mis directement la lang à la fin. Mais comme il n'est quasiment pas utilisé, autant en profiter pour mettre la langue, plus importante, en premier.
Mais s'il n'y a aucun @lang@ la solution de Cédric est encore mieux car ça permet de ne même pas utiliser _T dans un squelette, mais directement le raccourci connu : <:chaine{lang=es}:>, c'est plutôt cool.
* admin_lang/lang/adminlang_es.php:48: 'gerer_master_complet' => 'Modificar y agregar textos al modulo @module@ en @lang@',
* admin_lang/lang/adminlang_fr.php:48: 'gerer_master_complet' => 'Modifier et ajouter des chaînes au module @module@ en @lang@',
* admin_lang_2_0/lang/adminlang_es.php:48: 'gerer_master_complet' => 'Modificar y agregar textos al modulo @module@ en @lang@',
* admin_lang_2_0/lang/adminlang_fr.php:48: 'gerer_master_complet' => 'Modifier et ajouter des chaînes au module @module@ en @lang@',
* admin_mots-cles/lang/amocles_fr.php:57: , 'mots_vides_pour_' => "Mots vides pour @nom_lang@ [@lang@]"
Merci.
Donc la solution de Cédric ne peut pas être appliqué, à moins de changer ces onze occurrences.
Onze, ce n'est pas énorme, mais le problème c'est que les exemples cités sont tout à fait légitimes en utilisant @lang@, donc c'est un peu tordu de changer ça, et en quoi d'ailleurs ?
Ou bien pour _T() ça pourrait être "spip_lang" (c'est le nom de la globale réellement utilisée normalement) plutôt que "lang" tout court. Et là ça serait bon. <:chaine{spip_lang=es}:>
Il y a peut-être des extensions de SPIP en dehors de la zone, ce n'est pas un argument.
Le 3e argument est une classe CSS s'appliquant aux valeurs contenu dans le 2e argument,
je trouve assez normal que ces 2 arguments soit l'un à côté de l'autre.
Si on avait réfléchi à tout ça depuis le début, on aurait sans doute mis la langue en 2e argument (car elle ne concerne que le 1er argument) le tableau en 3e et la class CSS en 4e. Mais maintenant cette configuration intuitive n'en est plus faisable, alors autant éviter toute incompatibilité.
Oui.
D'où la solution de Cédric, qui ne casse rien et qui en plus évite un argument superfétatoire (ah c'est beau la langue française !).
Il suffit juste de ne pas utiliser "lang" mais "spip_lang", qui de toute façon est le nom donné à la globale, donc ça colle. Ça permet à la fois de ne rien casser du tout, et en plus de pouvoir spécifier la langue même dans le raccourci <::>
oui mais ce que dit emmanuel, c'est que ça collisionne possiblement
avec des usages, non repertoriés sur la zone.
Il faut voir si on considère que 'spip_lang' est un nom de paramètre
suffisamment improbable pour cela, avec l'avantage subséquent de
pouvoir utiliser la syntaxe dans un squelette avec <:...:>, ou si
c'est tout de même rédhibitoire, et on met un 4ème arg pour ne rien
casser.
oui mais ce que dit emmanuel, c'est que ça collisionne possiblement
avec des usages, non repertoriés sur la zone.
Oui j'ai bien compris.
Il faut voir si on considère que 'spip_lang' est un nom de paramètre
suffisamment improbable pour cela, avec l'avantage subséquent de
pouvoir utiliser la syntaxe dans un squelette avec<:...:>, ou si
c'est tout de même rédhibitoire, et on met un 4ème arg pour ne rien
casser.
Pour @lang@ c'était quasiment sûr qu'il y avait des occurrences et le grep de denisb l'a montré (et il y en a sûrement d'autres encore pas sur la zone).
Pour @spip_lang@, je pense qu'il y a vraiment très très très peu de chance pour qu'il y ait ce nom utilisé dans une chaine de langue. Et donc je vote pour mon patch !
mouais..
là, à ce jour, aucun @spip_lang@ dans /_plugins_/ ou /branches/
passer la choix de langue dans un 4ème argument obligerait à des
contorsions amusantes dans les squelettes :
<:module:truc_a_traduire{#ARRAY{}, '', oc_ni_la}|strtoupper:>
(ps hors sujet et quémandeur :
quelqu'un peut me rendre mon accès svn sur trac ?)
Ca n'est pas terrible en effet (encore qu'en blindant un peu _T on pourrait remplacer #ARRAY{} par ''),
mais il ne faut pas oublier que revenir sur un syntaxe c'est assez facile,
tandis que revenir sur une sémantique c'est difficile voire impossible dans certains cas.
Bien que le hack du @spip_lang@ soit en pratique vraisemblablement sans danger,
ça ferait encore une exception injustifée supplémentaire dans SPIP.
