C’est cryptique n’est pas ? C’est un raccourci pour écrire localization, soit traduction en français. On s’en sert côté Dotclear pour traduire tous les textes affichés à l’écran et malheureusement un des outils utilisés pour générer la liste des textes à traduire est pété : il y a certains fichiers sources (en PHP) pour lesquels il ignore complètement les textes à traduire qui s’y trouvent, ce qui fait que dans les versions distribuées on peut avoir des textes non traduits (affichés en anglais donc).
Ça fait déjà quelques années que j’ai des soupçons à son sujet, mais après énième vérification ce matin, c’est avéré.
Il va falloir que je remette ça à plat et que je corrige, si possible, cet outil…
Le coupable évident c’est l’utilitaire xgettext (sa doc officielle est ici), mais je ne sais pas (encore) dire pourquoi (bug, paramètre fourni incorrect, …), juste qu’il ne fonctionne pas comme attendu.
Exemple, la commande :
xgettext -L PHP -k"__:1,2" -k"__:1" --from-code=UTF-8 -o messages.pot *.php
Exécutée dans le répertoire plugins/dcLegacyEditor/inc
ne trouve absolument aucun libellé à traduire alors qu’on peut observer ceci dans le seul fichier dc.legacy.editor.behaviors.php
qui s’y trouve, ligne 90 et suivantes :
$js = [
'dialog_url' => 'popup.php',
'iframe_css' => $css,
'base_url' => $GLOBALS['core']->blog->host,
'switcher_visual_title' => __('visual'),
'switcher_source_title' => __('source'),
'legend_msg' => __('You can use the following shortcuts to format your text.'),
'elements' => [
'blocks' => [
'title' => __('Block format'),
'options' => [
'none' => __('-- none --'),
'nonebis' => __('-- block format --'),
'p' => __('Paragraph'),
'h1' => __('Level 1 header'),
'h2' => __('Level 2 header'),
'h3' => __('Level 3 header'),
'h4' => __('Level 4 header'),
'h5' => __('Level 5 header'),
'h6' => __('Level 6 header'),
], ],
'strong' => ['title' => __('Strong emphasis')],
'em' => ['title' => __('Emphasis')],
'ins' => ['title' => __('Inserted')],
'del' => ['title' => __('Deleted')],
'quote' => ['title' => __('Inline quote')],
'code' => ['title' => __('Code')],
'mark' => ['title' => __('Mark')],
'br' => ['title' => __('Line break')],
'blockquote' => ['title' => __('Blockquote')],
'pre' => ['title' => __('Preformated text')],
'ul' => ['title' => __('Unordered list')],
'ol' => ['title' => __('Ordered list')],
'link' => [
'title' => __('Link'),
'accesskey' => __('l'),
'href_prompt' => __('URL?'),
'hreflang_prompt' => __('Language?'),
],
'img' => [
'title' => __('External image'),
'src_prompt' => __('URL?'),
],
'img_select' => [
'title' => __('Media chooser'),
'accesskey' => __('m'),
],
'post_link' => ['title' => __('Link to an entry')],
'removeFormat' => ['title' => __('Remove text formating')],
'preview' => ['title' => __('Preview')],
],
…
Étrange…
1 De Nicolas -
xgettext ne fait pas une recherche récursive ! Si tu utilises la commande suivante ça devrait déjà être beaucoup mieux !
find ./ -type f -name '*.php' | xargs xgettext -L PHP -k"__:1,2" -k"__:1" --from-code=UTF-8 -o messages.pot
2 De Franck -
Nicolas je n’ai aucun problème avec la recherche récursive, qu’on utilise d’ailleurs dans la construction des traductions. Uniquement avec la recherche à l’intérieur des fichiers PHP, cf l’exemple cité dans le billet.
3 De Franck -
D’ailleurs si je remplace dans la commande indiquée dans le billet
*.php
par le nom du seul fichierdc.legacy.editor.behaviors.php
ça ne fonctionne pas mieux.