Bonjour,
pour le moment, il n'est pas possible de mettre une chaîne multilingue (plugin:chaine) dans le titre ou le descriptif d'un composition.
Y a-t-il une opposition à ce que je modifie la fonction compositions_charger_infos de inc/compositions.php en y ajoutant des appels à _T ?
Cordialement
Joseph
Bonjour Joseph,
pas de problème pour prendre en charge les chaines de langue dans les xml de compositions, mais il faut que ça reste compatible avec les textes libres comme actuellement car cela correspondra à la majorité des usages perso.
Cédric
Le 2 févr. 2010 à 13:22, Joseph a écrit :
Bonjour,
pour le moment, il n'est pas possible de mettre une chaîne multilingue (plugin:chaine) dans le titre ou le descriptif d'un composition.
Y a-t-il une opposition à ce que je modifie la fonction compositions_charger_infos de inc/compositions.php en y ajoutant des appels à _T ?
Cordialement
Joseph
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
J'ai procédé à quelques tests ce matin.
Si on passe le contenu du champs xml à la fonction _T() et que cela ne correspondant pas à une chaîne de langue connue, _T() renvoie le contenu du champs, SAUF si le champs contient le caractère :, auquel cas seul ce qui suit le : est renvoyé.
Doit-on considérer que ce défaut est mineur et que lorsque l'on écrit un descriptif contenant un : il faut ajouter un : en début de champs ?
Faut-il faire une autre fonction qui renvoie tout le champs si aucune chaine de langue n'a été trouvée ? Ajouter un paramètre à _T pour modifier son comportement par défaut ?
Note : le problème de mettre une chaîne de langue dans un xml se rencontre aussi dans d'autres plugins (le plugin menu par exemple).
Si l'on interdit les chaines de langue dans les xml, cela complique considérablement les traductions, puisque tous les éléments à traduire ne sont pas centralisés dans le fichier de langue.
J
On peut aussi proposer que si une chaine de langue est utilisée, elle est écrite sous la forme
<:module:chaine:>
comme dans un squelette, non ?
Cédric
Le 3 févr. 2010 à 10:15, Joseph a écrit :
J'ai procédé à quelques tests ce matin.
Si on passe le contenu du champs xml à la fonction _T() et que cela ne correspondant pas à une chaîne de langue connue, _T() renvoie le contenu du champs, SAUF si le champs contient le caractère :, auquel cas seul ce qui suit le : est renvoyé.
Doit-on considérer que ce défaut est mineur et que lorsque l'on écrit un descriptif contenant un : il faut ajouter un : en début de champs ?
Faut-il faire une autre fonction qui renvoie tout le champs si aucune chaine de langue n'a été trouvée ? Ajouter un paramètre à _T pour modifier son comportement par défaut ?
Note : le problème de mettre une chaîne de langue dans un xml se rencontre aussi dans d'autres plugins (le plugin menu par exemple).
Si l'on interdit les chaines de langue dans les xml, cela complique considérablement les traductions, puisque tous les éléments à traduire ne sont pas centralisés dans le fichier de langue.
J
Le 03/02/2010 10:23, cedric.morin@yterium.com a écrit :
On peut aussi proposer que si une chaine de langue est utilisée, elle est écrite sous la forme
<:module:chaine:>
comme dans un squelette, non ?
C'est ce que j'ai fait pour le plugin Saisies. Et qu'il faudrait faire dans Menus aussi.
--
RastaPopoulos
Le 3 févr. 2010 à 10:30, RastaPopoulos a écrit :
Le 03/02/2010 10:23, cedric.morin@yterium.com a écrit :
On peut aussi proposer que si une chaine de langue est utilisée, elle est écrite sous la forme
<:module:chaine:>
comme dans un squelette, non ?C'est ce que j'ai fait pour le plugin Saisies. Et qu'il faudrait faire dans Menus aussi.
et dans le core pour les <bouton> et <onglet>
Tu as trouvé une fonction pour ça, ou tu en as fais une pour ?
Cédric
C'est possible. Dès lors, il faut tester la présence ou non de <:module:chaine:> et la traiter au besoin. Existe il déjà une fonction interne qui fait ça ?
Dans tous les cas, il faudrait harmoniser dans tous les plugins qui gèrent des 'objets' définis par un xml.
Je repère Compositions et Menus, mais il y en a probablement d'autres. N'ayant pas été très présent ces derniers mois, il y a beaucoup de choses que je n'ai pas vu passer.
Cordialement
Joseph
Le 03/02/2010 09:23, cedric.morin@yterium.com a écrit :
On peut aussi proposer que si une chaine de langue est utilisée, elle est écrite sous la forme
<:module:chaine:>
comme dans un squelette, non ?Cédric
Le 03/02/2010 10:35, cedric.morin@yterium.com a écrit :
et dans le core pour les<bouton> et<onglet>
Tu as trouvé une fonction pour ça, ou tu en as fais une pour ?
J'ai pas trouvé de solution miracle pour l'instant.
Dans Saisies j'ai fait une fonction "transformer_langue" qui s'applique sur une valeur.
- Si c'est une chaine :
- Si c'est <:truc:> on envoie à _T()
- Si on trouve <multi> dedans, on applique typo()
- Si c'est un tableau on réapplique la fonction récursivement sur les valeurs du tableau
C'est un peu pourri mais ça marche. 
Mais je suis grandement partant pour qu'on trouve une solution générique qu'on pourra utiliser dans le core ou n'importe quel plugin ayant un fichier de conf (qu'il soit XML ou YAML...).
Le besoin c'est qu'il faut pouvoir à la fois avoir :
- une chaine classique
- une chaine de langue
- des <multi>
--
RastaPopoulos
Le 3 févr. 10 à 11:01, Joseph a écrit :
C'est possible. Dès lors, il faut tester la présence ou non de <:module:chaine:> et la traiter au besoin. Existe il déjà une fonction interne qui fait ça ?
Dans tous les cas, il faudrait harmoniser dans tous les plugins qui gèrent des 'objets' définis par un xml.
Je repère Compositions et Menus, mais il y en a probablement d'autres. N'ayant pas été très présent ces derniers mois, il y a beaucoup de choses que je n'ai pas vu passer.
ça existe bine dans plugin.xml on peut écrire par exemple :
<bouton id='mon_id' parent="bando_configuration">
<icone>images/truc-16.png</icone>
<titre>mon_plugin:le_nom_de_mon_plugin</titre>
<url>cfg</url>
<args>cfg=tarte_aux_lampions</args>
</bouton>
où la chaîne de titre fait référence aux fichiers de langue.
Mais je ne sais pas ce qui gère cela.
pierre
Le 3 févr. 10 à 11:50, Pierre Fiches a écrit :
où la chaîne de titre fait référence aux fichiers de langue.
préfixé mon_plugin évidemment
ça existe bine dans plugin.xml on peut écrire par exemple :
<bouton id='mon_id' parent="bando_configuration">
<icone>images/truc-16.png</icone>
<titre>mon_plugin:le_nom_de_mon_plugin</titre>
<url>cfg</url>
<args>cfg=tarte_aux_lampions</args>
</bouton>où la chaîne de titre fait référence aux fichiers de langue.
Dans ce cas, afin que la convention d'écriture soit la même partout, il faudrait adopter module:chaine et non <:module:chaine:>.
(Note : c'est déjà le cas dans le plugin menus)
Le 03/02/2010 12:06, Joseph a écrit :
Dans ce cas, afin que la convention d'écriture soit la même partout, il
faudrait adopter module:chaine et non <:module:chaine:>.(Note : c'est déjà le cas dans le plugin menus)
Sauf que ça va pas parce que comme tu le disais, quand on a une chaine classique avec ":" dedans (et pourquoi faudrait-il l'interdire ?), et bien ça ne colle pas.
Il doit y avoir matière à amélioration pour qu'une même fonction colle à tous les besoins, du core et des plugins.
--
RastaPopoulos
Le 3 févr. 10 à 12:59, RastaPopoulos a écrit :
Le 03/02/2010 12:06, Joseph a écrit :
Dans ce cas, afin que la convention d'écriture soit la même partout, il
faudrait adopter module:chaine et non <:module:chaine:>.(Note : c'est déjà le cas dans le plugin menus)
Sauf que ça va pas parce que comme tu le disais, quand on a une chaine classique avec ":" dedans (et pourquoi faudrait-il l'interdire ?), et bien ça ne colle pas.
Il doit y avoir matière à amélioration pour qu'une même fonction colle à tous les besoins, du core et des plugins.
Sûrement mais je ne comprend pas pourquoi la fonction du core qui parse le fichier plugin.xml ne peut pas être utilisée,
c'est quoi le problème ?
Le 03/02/2010 13:23, Pierre Fiches a écrit :
Le 3 févr. 10 à 12:59, RastaPopoulos a écrit :
Le 03/02/2010 12:06, Joseph a écrit :
Dans ce cas, afin que la convention d'écriture soit la même partout, il
faudrait adopter module:chaine et non <:module:chaine:>.(Note : c'est déjà le cas dans le plugin menus)
Sauf que ça va pas parce que comme tu le disais, quand on a une chaine
classique avec ":" dedans (et pourquoi faudrait-il l'interdire ?), et
bien ça ne colle pas.Il doit y avoir matière à amélioration pour qu'une même fonction colle
à tous les besoins, du core et des plugins.Sûrement mais je ne comprend pas pourquoi la fonction du core qui parse
le fichier plugin.xml ne peut pas être utilisée,
c'est quoi le problème ?
Dans un plugin, que ce soit Compositions ou un autre, la structure du XML n'est pas forcément la même, et surtout, c'est même pas forcément un XML ! Dans Saisies c'est un YAML.
Ce qu'il faut c'est une fonction "générique" à utiliser sur une valeur, n'importe laquelle, et qui teste si c'est une chaine de langue, ou un <multi> ou etc. Et qui le fait proprement.
Ensuite on pourra appeler cette fonction dans plusieurs cas différents.
--
RastaPopoulos
Le 03/02/2010 11:59, RastaPopoulos a écrit :
> Sauf que ça va pas parce que comme tu le disais, quand on a une chaine
> classique avec ":" dedans (et pourquoi faudrait-il l'interdire ?), et
> bien ça ne colle pas.
Une chaine classique avec un : pose souci avec la fonction _T en effet.
Mais le problème est là uniquement si on a recours seulement à _T.
Peux envisager une fonction qui prends le contenu du champs.
1/ La fonction regarde si ça correspond à une chaine de langue existante. Si oui, elle renvoie la chaine de langue.
2/ S'il ne s'agit pas d'une chaine de langue, elle passe le contenu à propre pour traiter d'éventuels champs [multi] et autoriser de fait les raccourcis typo de spip comme les [->liens].
Que se passe-t-il si dans le champs on a mis une chaine de langue module:chaine qui pointe vers une chaine inexistante (oubli dans le fichier de langue) ?
Sera affiché module:chaine au lieu de chaine (comme ce qu'on obtient ordinairement avec _T).
Est-ce problématique ? je ne crois pas
Le 03/02/2010 12:29, RastaPopoulos a écrit :
Ce qu'il faut c'est une fonction "générique" à utiliser sur une valeur,
n'importe laquelle, et qui teste si c'est une chaine de langue, ou un
<multi> ou etc. Et qui le fait proprement.Ensuite on pourra appeler cette fonction dans plusieurs cas différents.
L'intérêt d'une telle fonction, c'est qu'elle amènera à une écriture générique entre différents plugins.
La question est donc de savoir où elle est censée être déclarée. Je suppose dans le core ?
Oui mais tu peux déjà la mettre dans spip-bonux pour la tester et la valider, et si il est encore temps, on l'intègre dans la 2.1 avant sa release stable.
Cédric
Le 3 févr. 2010 à 15:39, Joseph a écrit :
Le 03/02/2010 12:29, RastaPopoulos a écrit :
Ce qu'il faut c'est une fonction "générique" à utiliser sur une valeur,
n'importe laquelle, et qui teste si c'est une chaine de langue, ou un
<multi> ou etc. Et qui le fait proprement.Ensuite on pourra appeler cette fonction dans plusieurs cas différents.
L'intérêt d'une telle fonction, c'est qu'elle amènera à une écriture générique entre différents plugins.
La question est donc de savoir où elle est censée être déclarée. Je suppose dans le core ?
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 03/02/2010 15:44, cedric.morin@yterium.com a écrit :
Oui mais tu peux déjà la mettre dans spip-bonux pour la tester et la valider, et si il est encore temps, on l'intègre dans la 2.1 avant sa release stable.
Et pour ça il faudrait quand même définir ce que doit faire la fonction.
Si ça correspond au modèle <:truc:>, on passe à _T().
Sinon on passe propre ou typo ? Et est-ce qu'on le passe que quand on trouve un <multi> ou bien on le passe dans tous les cas où ce n'est pas _T() ?
Et comment on l'appelle ?
--
RastaPopoulos
Si on part du principe que la chaîne de langue est écrite sous la forme module:chaine (sans <: et :>, et pour respecter la convention d'écriture lors du nommage des boutons, alors on peut avoir à la louche (à partir du code de _T et avec mes quelques moyens) quelque chose comme :
function _TT($texte, $args=array()) {
static $traduire=false ;
if (!$traduire) {
$traduire = charger_fonction('traduire', 'inc');
include_spip('inc/lang');
}
$text = $traduire($texte,$GLOBALS['spip_lang']);
if (!strlen($text)){
// C'est ici que l'on modifie la fonction
include_spip('inc/texte');
$text = typo($text);
}
if (is_array($args))
foreach ($args as $name => $value)
$text = str_replace ("@$name@", $value, $text);
return $text;
}
La proposition de nom _TT : on applique _T sinon typo
A discuter, annoter, corriger
Le 03/02/2010 17:12, RastaPopoulos a écrit :
Le 03/02/2010 15:44, cedric.morin@yterium.com a écrit :
Oui mais tu peux déjà la mettre dans spip-bonux pour la tester et la
valider, et si il est encore temps, on l'intègre dans la 2.1 avant sa
release stable.Et pour ça il faudrait quand même définir ce que doit faire la fonction.
Si ça correspond au modèle <:truc:>, on passe à _T().
Sinon on passe propre ou typo ? Et est-ce qu'on le passe que quand on
trouve un <multi> ou bien on le passe dans tous les cas où ce n'est pas
_T() ?Et comment on l'appelle ?
Je viens de tester en local une fonction _TT() ajouter à bonux (avec création au passage d'un spip_bonux_options.php).
Cette fonction regarde si le champs $texte qu'on lui passe est une chaîne de langue sous la forme module:chaine . (On reprend ainsi la convention d'écriture déjà utilisée pour les boutons mais également dans le plugin menus depuis 33428).
On applique donc traduire() à $texte qui renvoie la traduction de la chaine de langue dans la langue courante si elle existe, dans une autre langue sinon.
Si jamais il ne s'agit pas d'une chaîne de langue, alors on renvoie typo($texte).
Comme pour _T, on peut passer des arguments.
J'ai tester la modif sur les plugins menus et compositions. Je n'ai pas rencontré de bug.
Puis-je commiter tel quel ou préférez-vous que des sabots soient posés sur les trois plugins ?
Pour info, voici le code de _TT() :
/**
* une fonction qui regarde si $texte est une chaine de langue
* si oui applique _T()
* si non applique typo()
*/
function _TT($texte, $args=array()) {
static $traduire=false ;
if (!$traduire) {
$traduire = charger_fonction('traduire', 'inc');
include_spip('inc/lang');
}
$text = $traduire($texte,$GLOBALS['spip_lang']);
if (!strlen($text)){
// C'est ici que l'on modifie la fonction
include_spip('inc/texte');
$text = typo($texte);
}
if (is_array($args))
foreach ($args as $name => $value)
$text = str_replace ("@$name@", $value, $text);
return $text;
}
Cordialement
joseph
Le 03/02/2010 14:44, cedric.morin@yterium.com a écrit :
Oui mais tu peux déjà la mettre dans spip-bonux pour la tester et la valider, et si il est encore temps, on l'intègre dans la 2.1 avant sa release stable.
Cédric
Le 3 févr. 2010 à 15:39, Joseph a écrit :
Le 03/02/2010 12:29, RastaPopoulos a écrit :
Ce qu'il faut c'est une fonction "générique" à utiliser sur une valeur,
n'importe laquelle, et qui teste si c'est une chaine de langue, ou un
<multi> ou etc. Et qui le fait proprement.Ensuite on pourra appeler cette fonction dans plusieurs cas différents.
L'intérêt d'une telle fonction, c'est qu'elle amènera à une écriture générique entre différents plugins.
La question est donc de savoir où elle est censée être déclarée. Je suppose dans le core ?
_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone