Avant d’aller plus loin — oui, je sais, on a pas fait grand chose pour l’instant — on va parler un peu d’organisation et plus particulièrement ce que j’utilise comme sous-répertoires pour le plugin et ce que je mets dedans.
On a vu dernièrement que j’utilise le sous-répertoire lib pour le code tiers, dans notre cas la bibliothèque accessConfig d’Access42. D’autres répertoires viendront s’ajouter au fur et à mesure du développement :
- js : c’est ici que je mets tout les codes javascripts qui seront utilisés à un moment ou à un autre.
- css : comme son nom l’indique, les feuilles de style, si besoin, viendront là, éventuellement avec un sous-répertoire fonts, voire img (pour les images utilisées par les feuilles de style) ; mais je ne crois pas avoir déjà développé un plugin qui utilise ces sous-répertoires.
- inc : ici je placerai les classes PHP utilisées ; en particulier tout ce qui concerne les
behaviors
(comportements) publiques et d’administration — on y reviendra le moment venu. J’y place aussi la gestion des données enregistrées en base de données quand c’est le cas, et encore le code qui gère les balises template. - locales : contiendra les traductions ; on va voir juste après ce qu’il contient et comment le mettre à jour.
- img : parfois utile quand on a des images supplémentaires.
Tous ces noms sont indicatifs, mais les utiliser permet de conserver un semblant de cohérence d’un plugin à l’autre.
Bien évidemment vous êtes tout à fait libre d’utiliser cette organisation, ou bien de tout mettre au niveau principal du plugin — ce que je fais parfois pour des plugins ultra simples. À vous de voir ce qui vous paraît le plus facile à utiliser.
Revenons à la gestion des traductions.
Un outil est mis à disposition pour générer ou mettre à jour les traductions d’un plugin (ou d’un thème). Cet outil, qui s’utilise en ligne de commande, se trouve dans le dossier build-tools de votre installation Dotclear.
Ensuite, pour préparer les premières traductions en français — je rappelle que par défaut les libellés doivent être en anglais dans le code —, je lance la commande suivante, en considérant que je me trouve à la racine du dossier Dotclear :
./build-tools/po_update.sh fr ../plugins/a11yConfig
La première fois que je vais lancer cette commande, l’outil va créer automatiquement l’arborescence suivante dans le répertoire principal du plugin :
- répertoire locales : dossier des traductions
- sous-répertoire _pot : dossier modèle de traduction (utilisé ensuite pour les mises à jour)
- sous-répertoire fr : dossier des traductions françaises
Pour notre plugin, lorsque j’ai lancé cette commande, l’outil a émis quelques messages d’erreur, sans aucune gravité, simplement parce qu’aucun libellé pouvant être traduit n’a été reconnu comme tel dans les fichiers PHP et HTML de notre plugin.
Les libellés qui seront reconnus sont ceux, dans le code PHP, écrits sous la forme __('label')
(voire sous la forme __('label-singular', 'label-plural', n)
pour la gestion des pluriels[1]), tandis que dans les fichiers HTML, ce sont les balises template {{tpl:lang …}}
.
Comme je souhaite offrir une description en français de mon plugin, j’ai modifié le fichier _define.php comme suit (voir les lignes 17 et 18) :
<?php
/**
* @brief a11yConfig, a plugin for Dotclear 2
*
* @package Dotclear
* @subpackage Plugins
*
* @author Franck Paul, Biou and contributors
*
* @copyright Franck Paul carnet.franck.paul@gmail.com
* @copyright GPL-2.0 https://www.gnu.org/licenses/gpl-2.0.html
*/
if (!defined('DC_RC_PATH')) {return;}
$this->registerModule(
__("a11yConfig"), // Name
__("Implements Access42 accessibility configuration tool"), // Description
"Franck Paul, Biou and contributors", // Author
'1.0', // Version
[
'requires' => [['core', '2.15']],
'permissions' => 'admin', // Permissions
'type' => 'plugin', // Type
'support' => 'https://github.com/franck-paul/a11yConfig', // Support URL
'settings' => ['pref' => '#user-options.a11yConfig'] // Settings
]
);
Puis j’ai relancé l’outil de gestion des traductions :
./build-tools/po_update.sh fr ../plugins/a11yConfig
Cette fois-ci, plus d’erreurs vu qu’il a trouvé au moins un libellé à traduire à se mettre sous la dent et quelques nouveaux fichiers sont apparus dans l’arborescence :
- locales/_pot/main.pot : on peut ignorer ce fichier, il est simplement utilisé à des fins internes
- locales/fr/main.po : qui contient les traductions française.
Le 2e fichier est créé comme tel :
# SOME DESCRIPTIVE TITLE.
# This file is put in the public domain.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Dotclear 2 a11yConfig module\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-11-12 10:30+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
msgid "a11yConfig"
msgstr ""
msgid "Implements Access42 accessibility configuration tool"
msgstr ""
Que je modifie (ligne 23) ensuite pour insérer la traduction française de la description du plugin :
…
msgid "Implements Access42 accessibility configuration tool"
msgstr "Implémente l'outil de configuration de l'accessibilité d'Access42"
Vous noterez que j’ai laissé inchangé la traduction du nom du plugin, pas utile en français, c’est assez compréhensible comme ça. Dans ce cas, Dotclear utilisera la version anglaise du libellé (ce qui est vrai pour tous les libellés non traduits dans une langue ou une autre).
Nota : si vous souhaitez ajouter une autre langue, changez simplement le fr par le code de la langue correspondante (2e paramètre) dans la ligne de commande de génération des traductions. Par exemple, pour l’espagnol :
./build-tools/po_update.sh es ../plugins/a11yConfig
Notez également que vous pouvez lancer autant de fois que vous voulez cet outil, il n’écrasera pas ce que vous avez déjà traduit.
Un petit tour du côté de la gestion des plugins, en imaginant que la langue réglée chez vous soit en français, et voilà, la description est dorénavant affichée en français (vous pouvez basculer votre interface en anglais et revenir vérifier que vous avez maintenant la description en anglais) :
Nous voilà maintenant prêt à rentrer dans le vif du sujet, mais ça sera pour la prochaine fois. Pour l’instant, il s’agit d’enregistrer toutes les modifications et ajouts effectuées aujourd’hui dans notre dépôt.
Note
[1] Pour l’anglais ; certaines langues pouvant avoir jusqu’à 5 formes différentes de pluriel, Dotclear se charge alors d’utiliser l’idoine.
1 De Bernard -
Pour les traductions j’utilise l’extension de JC Denis translater 2013.05.11 qui, à partir des thèmes et plugins choisis, crée les dossiers de traductions (.po et .php) à partir des saisies manuelles que l’on effectue dans son interface.
On peut remanier les modifications effectuées quand bon nous semble (depuis l’interface)
De mémoire :
- il n’écrase pas les fichiers déjà créés mais les complète le cas échéant
- il permet de revenir sur les traductions existantes dans les fichiers de langue
- il tient compte des traductions préalablement existantes sous Dotclear (système?)
- je crois qu’il crée des copies (pas sûr)
- je ne sais plus s’il s’occupe des pluriels (à vérifier)
Bref un outil relativement facile à utiliser pour un neuneu comme moi
2 De Franck -
Sinon, pour modifier les fichiers .po (générés par l’outil livré avec Dotclear) on peut aussi utiliser l’outil Poedit qui tourne sur Windows, MacOS ou Linux.
3 De Bernard -
Bon j’ai tenté d’utiliser Poedit, mais, un peu paresseux, je suis dit que me taper le fonctionnement d’un nouveau logiciel, c’est pas la cerise sur le gâteau.
Du coup j’ai téléchargé l’extension de JC Denis translater, puis, pruneau, effectivement des erreurs avec php 7…
Du coup, tomate, j’ai vu que j’avais déjà proposé des modifs de ce plug sur le forum dc et retrouvé son lien sur le site de Brol - liste des plugs qu’il héberge et c’est retombé en marche…
Du coup, je me suis dit: si tous les plugs étaient sur Github peut-être que leur modifs seraient plus aisée ??
Certes pas facile si on considère le droit d’hauteur ;-)
4 De Franck -
Tu n’es pas obligé d’utiliser PoEdit, d’ailleurs moi-même je ne l’utilise pas non plus ; je me contente d’éditer les fichiers .po avec mon éditeur de code habituel, c’est aussi rapide.
Par contre remplacer DotAddict par Github est une très mauvaise idée ; prendre par exemple Bitbucket qui a décidé de supprimer le support des dépôts Mercurial. Quand c’est ailleurs, on est tributaire de ce genre de mésaventure.
5 De Bernard -
Note: De Franck - 17/09/2019, 07:59
cf https://open-time.net/post/2019/09/…
6 De Franck -
Ah oui tu as raison Bernard, faut cloner le dépôt Git pour l’avoir :-)