Le codage du var_mode=traduction nous a permet de constat suivant concernant les modules de langue traduits avec Tradlang :
supposons le français comme langue de référence
je crée la langue anglaise sous Tradlang et j’en traduit suffisamment - mais pas tout - pour que salvatore produise le fichier en.
dans ce fichier en salvatore génère tous les items avec leur traduction soit en anglais soit en français donc.
De ce fait, quand SPIP appelle la fonction traduire() pour un item de ce module dans la langue anglaise, il reçoit toujours un chaine, soit la vraie traduction en anglais soit la traduction dans la langue de référence.
En cela, on by-passe la logique de la fonction traduire() qui cherche pour une chaine non traduite dans une langue donnée, d’abord la chaine dans la langue du site puis en fr.
Est-ce que le comportement de Tradlang est voulu ou si non, ne faudrait-il pas que Tradlang n’exporte que les chaines traduites (état OK) et pas les chaines non traduites (état NEW a priori) ?
Le codage du var_mode=traduction nous a permet de constat suivant concernant les modules de langue traduits avec Tradlang :
supposons le français comme langue de référence
je crée la langue anglaise sous Tradlang et j’en traduit suffisamment - mais pas tout - pour que salvatore produise le fichier en.
dans ce fichier en salvatore génère tous les items avec leur traduction soit en anglais soit en français donc.
De ce fait, quand SPIP appelle la fonction traduire() pour un item de ce module dans la langue anglaise, il reçoit toujours un chaine, soit la vraie traduction en anglais soit la traduction dans la langue de référence.
En cela, on by-passe la logique de la fonction traduire() qui cherche pour une chaine non traduite dans une langue donnée, d’abord la chaine dans la langue du site puis en fr.
Est-ce que le comportement de Tradlang est voulu ou si non, ne faudrait-il pas que Tradlang n’exporte que les chaines traduites (état OK) et pas les chaines non traduites (état NEW a priori) ?
Je ne sais pas, c’était comme cela lorsque je l’ai repris. Très certainement utile pour des raisons de perfs pour éviter de charger plusieurs fichiers.
Il faut donc voir avec fil qui avait codé l’ancien salavtore.
Sinon c’est une modif de deux lignes à faire je pense et un réexport complet.
L’avantage aussi de tout avoir c’est que lorsque tu traduis depuis le fichier tu sais ce que tu as à traduire.
On pourrait donc imaginer deux exports => un export pour les fichiers comités (sans les new, juste ok et modif) et un depuis tradlang avec l’ensemble pour le cas que je citais au dessus?
Je n'ai pas vraiment d'avis à jour, l'environnement technique a changé, les
calculs de l'époque ne sont certainement plus du tout valables.
J'avais imaginé un module "spip" commun, "ecrire" et "public" à part ; je
pense qu'il est toujours bon de garder "ecrire" à part pour ne pas le
charger quand on n'en a pas besoin (espace public). mais on pourrait aussi
imaginer fusionner "public" (qui est petit) et "spip".
Attention, sont-elles vraiment identiques dans toutes les langues ?
Les contextes d’utilisation peuvent nécessiter différents termes dans certaines langues, mais pas dans d’autres.
C’est une vigilance à avoir aussi par rapport à un outil de traduction (ou vérification de traduction) en ligne, où l’on voit la chaine dans UN des contextes potentiels d’utilisation.
$text = '';
// parcourir tous les modules jusqu'a ce qu'on trouve
foreach ($modules as $module) {
$var = "i18n_".$module."_".$lang;
if (empty($GLOBALS[$var])) {
charger_langue($lang, $module);
Comme je l'ai dit dans un autre mail, quand on a une chaine de langue de
SPIP dans un squelette on l'écrit toujours <:item:> sans préciser le
module. De ce fait la fonction traduire reçoit en entrée l'argument $ori =
'spip|public|ecrire:item'.
Ainsi, si on suit le code j'ai l'impression qu'on va faire un
charger_langue sur chaque module de SPIP. Donc je pense qu'il a énormément
de chance de charger ecrire dans le public non (par ex les formulaires CVT
privé+public...) ?
En fait, il faudrait pour éviter cela toujours préfixer les chaines de
langue SPIP (ce qui me parait d'ailleurs mieux de toute façon) et respecter
strictement les aspects public et privé en dupliquant les chaines mais cela
est de plus en plus difficile il me semble au vu du code.
Depuis que nombre de formulaires de l'espace privé ont été transformés en squelette, et que des plugins comme Crayons ont été developpés,
il me paraît très vraisemblable que les 3 modules Public, Ecrire et Spip soient chargés quasi-systématiquement.
Ils sont de plus très contre-intuitifs, la preuve a contrario est qu'on n'a jamais demandé aux auteurs de plugins de reproduire ce découpage.
Autre dysémétrie: le fait qu'on ait pas besoin de préciser le module de langue dans les squelettes du noyau, alors qu'on doit le faire pour ceux des plugins, ce qui est pénible à l'écriture comme à la lecture.
Ce que je trouverais plus normal et intuitif, c'est que pour un squelette d'un plugin donné, on cherche le libellé de ses chaînes de langues d'abord dans les modules de langue de ce plugin, ensuite dans ceux des plugins qui lui sont nécessaires d'après sa description en XML, enfin dans ceux de SPIP.
A part ça je soutiens la demande de Klaus d'avoir des liens directs vers Trad-lang à partir des chaînes non traduites vues par var_mode=traduction, car à première vue si on n'a pas ces liens, ce mode ne me parait pas mieux que ce que fait Langonet, qui est graphiquement certainement plus pauvre mais a l'avantage de balayer tous les fichiers, plutôt que de forcer à les tester un par un avec ce var_mode.
crayons n'appelle pas les chaines d'ecrire au calcul des pages publiques.
(Si tu charges un crayon particulier, c'est possible, si le contrôleur a
besoin d'une chaîne, par exemple <:ecrire:email_2:>, mais il s'agit d'une
étape secondaire.)
Depuis que nombre de formulaires de l'espace privé ont été transformés en squelette, et que des plugins comme Crayons ont été developpés,
il me paraît très vraisemblable que les 3 modules Public, Ecrire et Spip soient chargés quasi-systématiquement.
Je pense aussi oui.
Fil dit que l'exemple de Crayons ne le démontre pas, c'est possible, mais je pense que c'est quand même ce qui doit se passer souvent.
Après Langonet ne rend pas le même service que le var_mode car justement lui n'est pas contextuel. En outre, quand on veut connaitre l'item sous-jacent dans une page (cas d'une surcharge) tout le monde ne sait pas faire un var_mode=inclure et lire le fichier HTML pour connaitre l'item de langue. Donc je vois pas le rapport avec Langonet.
Ben quand j'ai un module de langue nommé M_fr.php, si je crée le fichier M_en.php avec au minimum dedans:
<?php $GLOBALS[$GLOBALS['idx_lang']] = array() ?>
puis que j'applique Langonet en sélectionnant ce fichier, je vais avoir toutes les chaînes non traduites.
Le pb de dénoncer les chaînes non traduites en appliquant un squelettes est qu'on va passer à côté des chaînes dans la moitié des parties conditionnelles du squelette. Par exemple si j'ai
<BOUCLE1(ARTICLES}critere> plein de chaînes non traduites</BOUCLE1>
et que j'applique le squelette sur un contexte où le critère est absent, var_mode=traduction (si j'ai bien compris) ne va pas dénoncer ces chaînes. Tandis que Langonet les mentionnera, en disant dans quel fichier, y a pas besoin de var_mode=inclure pour ça.