Discussion Convention:Modules

Cette page est dédiée aux discussions des conventions de codage des modules Lua du Wiktionnaire.

Conventions de nommage

Français ou anglais ?

Je serais pour utiliser l’anglais pour nommer les variables et les fonctions locales, ça permettrait une réutilisation plus facile par les autres projets. Pour les fonctions exportées, je suis plus partagé. Utiliser le français permettrait aux utilisateurs/utilisatrices qui ne maitrisent pas bien l’anglais de comprendre le code des modèles invoquant un module mais l’anglais permettrait de rester cohérent si c’est la langue qu’on choisit pour les variables/fonctions locales. Darmo (Viendez parler !) 27 avril 2020 à 15:30 (UTC)

Bien que je ne code beaucoup de module, j’ai une préférence pour nommer les variables en français. De même pour les fonctions à l’exception de « set » et « get » qui sont énormément répandues en informatique et qui présente l’avantage d’être bien plus court que des équivalents en français. Pour le moment, MediaWiki ne gère pas un dépôt central de modèles ou modules que n'importe quel projet wikimedia pourrait utiliser sans avoir à le posséder en local donc l’avantage de coder en anglais pour pouvoir être réutilisé me parait faible. Si un autre projet veut réutiliser un module du Wiktionnaire francophone, c’est qu’il maitrise probablement le français, sinon il se tournera plus naturellement vers le Wiktionnaire anglophone. Donc utilisons autant que possible le français dans le code pour ne pas ajouter une barrière linguistique en plus de la barrière technique. Pamputt ^[Discuter] 27 avril 2020 à 15:58 (UTC)

Je vote pour l'anglais pour ne pas que nos super-modules soient abandonnés à terme parce que les autres Wiktionnaires (plus nombreux) en maintiennent un autre qu'il faudra adopter ici pour avoir toutes les fonctionnalités. JackPotte ($♠) 27 avril 2020 à 16:32 (UTC)

Je suis d’accord avec JackPotte. J’ai été confronté au problème de la langue il y a quelques semaines lorsque j’ai voulu regarder comment les autres Wix gèrent les sens d’écriture. Un contributeur du Wix en grec m’a contacté pour me montrer comment eux avaient fait et j’ai été très content de tomber sur du code écrit en anglais et non pas en grec. Darmo (Viendez parler !) 27 avril 2020 à 16:39 (UTC)

Il faut avant penser aux contributeurs de notre projet, et nous sommes un projet francophone. Par ailleurs, quand il y a des mots réservés (en anglais) dans le langage, ça permet parfois de rendre le nom des variables plus clair, même pour ceux qui parlent anglais. Et les contributeurs grecs qui parlent français et pas anglais peuvent être bien contents de trouver les programmes en français plutôt qu’en anglais, ne l’oublions pas. Ma très longue expérience professionnelle montre que c’est toujours mieux de prévoir de programmer dans sa propre langue, par exemple pour les commentaires, plutôt que dans un mauvais anglais (ou sans commentaires du tout parce qu’on ne se sent pas suffisamment à l’aide en anglais, c’est malheureusement classique). La maintenabilité est donc améliorée. J’ai participé à de nombreux projets internationaux avec des pays de langues diverses, et le problème est très différent dans ce cas, mais ici, nous sommes un projet francophone, encore une fois. Lmaltier (discussion) 27 avril 2020 à 17:11 (UTC)

Je n’envisageais pas d’écrire les commentaires en anglais, seulement le code. Par rapport à mon exemple grec, je pense qu’il y a plus de gens qui maitrisent les bases de l’anglais que du français (je parle dans le cas général, pas uniquement des grecs), surtout parmis les gens qui programment et mon expérience de développeur m’a montré qu’il est préférable de coder en anglais plutot que dans une autre langue si on veut que son code soit réutilisable par d’autres Darmo (Viendez parler !) 27 avril 2020 à 17:24 (UTC)

Je en comprends pas la logique : oui, c’est fondamental que le code soit réutilisable par d’autres (à commencer par d’autres personnes du projet). Et pour que le code soit réutilisable par d’autres, les commentaires, c’est ce qu’il y a de plus important. Lmaltier (discussion) 27 avril 2020 à 17:32 (UTC)

Je me suis mélangé, ce que je voulais dire, c’est que les commentaires hors du code seraient en français, c’est-à-dire ceux dans la sous-page de documentation. Les commentaires dans le code pourraient, quant à eux, être en anglais. Darmo (Viendez parler !) 27 avril 2020 à 17:36 (UTC)

La page de documentation aussi, elle est fondamentale pour la réutilisation… Sur le principe général, nous devons en tout donner la priorité aux francophones ici, dans un projet francophone. Cela n’empêche pas des personnes intéressées de traduire dans d’autres langues pour réutiliser ailleurs. Lmaltier (discussion) 27 avril 2020 à 20:19 (UTC)

Dans tous les cas, on peut utiliser Module:TNT pour traduire les modèles et messages à l'attention de l'utilisateur (non développeur Lua). Par exemple je l'avais fait dans b:Module:Version imprimable que j'ai déployé dans plusieurs langues, avec traductions sur commons:Data:I18n/Module:Printable_version.tab. JackPotte ($♠) 28 avril 2020 à 06:53 (UTC)

Salut, je suis plus trop présent en ce moment, mais Darmo m’a demandé de passer donner un avis, vu que j’ai fait quelques modules. Pour ma part, je pense que le code et les commentaires dans le code devraient être en anglais. La documentation, elle, peut être en français. Et ce, pour plusieurs raisons. La première est purement esthétique, mais Lua ne supportant pas les accents, ben je peux pas écrire des mots comme « définitions », « créer » ou autres. De plus, le fait est que les mots-clés et fonctions de base (déjà implémentées) le sont en anglais, ainsi, si on utilise le français, on aura des mélanges de langue dans le code. En plus de devoir maitriser le langage de programmation, comprendre les deux langues, il faudra aussi pouvoir sauter rapidement d’une langue à l’autre. De plus, aujourd’hui, et bien que je sois tout jeune dans le monde professionnel, tout est en anglais : la documentation, les forums d’aide, les codes d’autres personnes. Bien que j’aurai aimé que la langue internationale soit l’espéranto, et bien, c’est l’anglais. Et la plupart des développeurs/informaticiens de mon âge, voire plus vieux, parlent nécéssairement l’anglais. Enfin, il faut se rappeler que les modules sont de la contribution de niche. On ne vient pas sur un dictionnaire pour contribuer sur le développement de modules. Une partie de nos modules ont été pompés, ou du moins inspirés, du Wiktionnaire anglophone. Nous sommes une petite équipe à entretenir le code. Si nous nous privons de l’aide potentielle que peuvent fournir d’autres développeurs non francophones, nous filons droit à une rapide obsolescence de nos modules (ce qui est déjà en partie le cas). Lepticed7 (Venez tcharer !) 2 mai 2020 à 09:25 (UTC)

Au passage, sans remettre en cause le choix entériné de l’anglais:

J’en profite pour faire remarquer que ce type de choix crée en un processus qui fait auto-renforcement : tout est dans tel langue, donc nous aussi on passe à cette langue, et donc tout est encore plus dans cette langue. D’ailleurs j’avais ouvert un ticket à ce sujet auquel je ne repense que maintenant que je lis cela : Allow users to code in localized programming languages.

Là le problème évoqué par @Lepticed7 c’est plutôt le fait que Lua ne permet pas d’utiliser des identifieurs Unicode est un sous-ensemble du problème. Psychoslave (discussion) 2 juin 2021 à 13:04 (UTC)

Donc, si je résume, pour le moment, la balance penche plutot vers le code en anglais pour les raisons suivantes :

• facilité de réutilisation de code venant des autres projets,
• facilité de réutilisation par les autres projets,
• augmentation de la durée de vie des modules
• harmonisation du code, en évitant le mélange français/anglais entre les mot-clés, noms de variables et de fonctions (get, set…)

Darmo (Viendez parler !) 9 mai 2020 à 16:04 (UTC)

Bon, au vu de l’absence de réactions, je considère comme actée l’utilisation de l’anglais dans le code des modules (commentaires compris). Seule la page de documentation du module sera en français mais ne sera qu’une traduction de la doc écrite dans le code. Darmo (Viendez parler !) 12 mai 2020 à 17:41 (UTC)

Nommage des modules

• Je trouve que c’est une bonne habitude d’avoir tous les tableaux associatifs dans des pages qui finissent par /data. Ça n’a pas été fait sur Wikipédia, et certains module n’ont pas ce nom là ici non plus. Séparer distinctement les deux types de modules me paraît le plus efficace, non ? Noé 29 avril 2020 à 10:34 (UTC)

  Et dans le cas de modules avec plusieurs tables, on pourrait les mettre sous /data/ avec un nom explicite en laissant /data vide. Genre comme sur Module:données Unicode avec données Unicode/data/blocks, données Unicode/data/scripts et données Unicode/data/script ranges. Darmo (Viendez parler !) 29 avril 2020 à 11:03 (UTC)

Nommage des variables

Les noms des variables devraient suivre la même convention que les fonctions, c’est-à-dire utiliser le camelCase, sans majuscule au début. Darmo (Viendez parler !) 12 mai 2020 à 17:49 (UTC)

Variables de modules

> Il s’agit des variables dans lesquelles les modules sont chargés.

J’ai pour habitude de les nommer m_<nom du module>, par exemple pour le Module:bases : local m_bases = require("Module:bases"). Darmo (Viendez parler !) 27 avril 2020 à 15:23 (UTC)

Je suis franchement pas fan, ça me rappel la notation hongroise du C++ où il a valeur de member.

Je suis donc d’avis que nous nous passions de cette convention qui du reste n’a pas l’air très employé dans les autres projets. Via cette recherche je vois quelques mVariable, mais c’est loin d’être systématique. Psychoslave (discussion) 2 juin 2021 à 13:20 (UTC)

Variable d’export

> Il s’agit de la variable qui est retournée à la fin de chaque module.

J’ai vu que le nom p est assez répandu. Personnellement j’utilise export. Darmo (Viendez parler !) 27 avril 2020 à 15:25 (UTC)

Après reflexion, je pense qu’il serait plus judicieux de garder le nom p car c’est celui utilisé dans les extraits de code de la doc et sur les autres wix. Darmo (Viendez parler !) 12 mai 2020 à 17:43 (UTC)

Moi je préférais assurément export, où tout autre identifieur soulignant le fait que c’est ce qui va être accessible depuis un appel externe. Psychoslave (discussion) 2 juin 2021 à 13:23 (UTC)

Nommage des fonctions

La norme interwiki MW:Manual:Coding_conventions/Lua demande d'utiliser le CamelCase pour toutes les fonctions, et le préfixe underscore pour celles qui ne prennent pas "frame" en argument (et qui ne sont pas forcément privées). JackPotte ($♠) 27 avril 2020 à 15:34 (UTC)

Petite précision, la norme indique de ne pas mettre de majuscule au début du nom. Darmo (Viendez parler !) 12 mai 2020 à 17:48 (UTC)

Salut @JackPotte et @Darmo117. Alors ce n’est pas une norme, le document en question explicite même que c’est un essai qui exprime des préférences personnelles et que tout le monde n’est pas nécessairement en accord avec celles-ci. De plus en regardant la page de discussion, il y a une remarque sur le fait que ce qui est indiqué sur la page n’est pas en accord avec les conventions utilisés pour les extensions de Mediawiki comme Scribunto avant de pointer vers https://en.wikipedia.org/wiki/Wikipedia_talk:Lua_style_guide#WMF_coding_conventions Psychoslave (discussion) 31 mai 2021 à 21:37 (UTC)

Peut-être, mais ces conventions/suggestions sont déjà suivies sur d’autres projets et ici. J’estime qu’elles sont suffisament claires, d’autant qu’il y a la page d’aide pour tout expliquer. Darmo (Viendez parler !) 31 mai 2021 à 21:44 (UTC)

Indentation, retours à la ligne et espaces

Personnellement, je partirais sur 2 ou 4 espaces, pas de tabulations. Darmo (Viendez parler !) 27 avril 2020 à 15:20 (UTC)

https://en.wikipedia.org/wiki/Wikipedia_talk:Lua_style_guide#CodeEditor_switched_to_tabs tout comme l’essai ci-dessus indique que l’éditeur visuel force de toute façon tabulation, donc la question ne se pose plus, c’est tabulation qui s’est imposé par contrainte technique. Psychoslave (discussion) 31 mai 2021 à 21:39 (UTC)

Structure des scripts

Les modules ne devraient pas utiliser directement les données des pages /data d’autres modules. Il faut passer par les fonctions du module auquel elles sont associées Darmo (Viendez parler !) 29 avril 2020 à 11:05 (UTC)

Nommage des modules

Rien n’a été stipulé à ce sujet il me semble.

• Est-ce qu’il doit être en français ou en anglais ?
• Est-ce qu’il doit correspondre à un singulier, pluriel, un nom de collectif, ou on s’en fout et BidÜle2678lolZ c’est tout à fait recevable ?

Psychoslave (discussion) 31 mai 2021 à 21:46 (UTC)

Pour le coup, rien n’a été décidé. Je serais d’avis de nommer tous les nouveaux modules en anglais, puisque contrairement aux modèles les modules n’ont pas vocation à être invoqués directement dans les pages. Concernant le singulier/pluriel, j’ai pas de préférence. Faut quand même que le nom soit compréhensible. Darmo (Viendez parler !) 31 mai 2021 à 21:50 (UTC)

Je précise un peu le contexte, je viens sur cette page suite à un lien que m’a fourni @Darmo117 sur la page de discussion de Module:exemples. Le titre du module est au pluriel en français, et le code contient aussi des identifieurs de module en français comme local m_params = require("Module:paramètres"), ce qui du coup déroge un peu au fait d’avoir du code en anglais indiqué ci-dessus.… Psychoslave (discussion) 31 mai 2021 à 21:57 (UTC)

Oui, je sais, c’est moi Darmo117… La raison est simple, c’est que le Module:parameters existe déjà car importé de enwikt et que je l’ai réimplémenté en plus clair sur Module:paramètres. J’ai pas pu remplacer le code du premier car certaines de ses fonctionnalités sont utilisées sur le wix mais pas encore réimplémentées dans le second. Darmo (Viendez parler !) 31 mai 2021 à 22:03 (UTC)

Haha, je précise que je précisais le contexte pour les autres personnes qui passeraient par là Darmo.

Merci quand même pour les explications complémentaires. Psychoslave (discussion) 31 mai 2021 à 22:48 (UTC)

Du coup @Darmo117, @JackPotte, @pamputt, @Lmaltier, @Lepticed7

Deux points appels à commentaire avant décision:

1. tous les nouveaux modules sont à nommer en anglais (les modèles eux conserveront un titre en français)

2. les modules existants doivent être renommer en anglais

Pour ma part, étant donné que l’usage de l’anglais est entériné pour le code des modules, il me paraîtrait effectivement plus cohérent que le nom des modules soient en anglais. Et donc à mon sens il faut viser à un renommage exhaustif des modules (ce qui peut se faire au fil de l’eau je contribue à un module, je le renomme si le nom est encore en français). Psychoslave (discussion) 2 juin 2021 à 12:37 (UTC)

OK, ça va dans le sens des modules utilisés sur plusieurs projets, avec traduction sur Commons. JackPotte ($♠) 2 juin 2021 à 15:08 (UTC)

Ça me va aussi, j’avais déjà plus ou moins commencé un travail dans ce sens. Je pourrai me charger du renommage, j’ai une bonne vue d’ensemble des dépendances entre modules et modèles. Darmo (Viendez parler !) 2 juin 2021 à 16:15 (UTC)

Si cette vue d’ensemble est d’une complexité suffisante pour que sa connaissance constitue à atout pour contribuer aux évolutions, ne serait-il pas pertinent de créer une page de documentation des dépendances de nos modules ? 🤔 Psychoslave (discussion) 3 juin 2021 à 08:52 (UTC)

Si, mais ça prend du temps. Darmo (Viendez parler !) 3 juin 2021 à 17:33 (UTC)

Diversité des valeurs de retour, renvoie d’erreur, quelle convention?

Dans module:exemples j'ai ajouté quelques commentaires, et notamment --- @error string when lang is missing. Je pense que c’est assez parlant, mais en l’état ça ne suis aucune convention. Pour être clair sur ce commentaire, il stipule que la fonction peut possiblement retourner une erreur, sous forme d’une chaîne, et explique le cas soulevant cette erreur. Sachant qu’une fonction peut potentiellement avoir différent point de sortie, générer plusieurs erreurs de par des situations distincts, et que potentiellement Lua permet de retourner des types différent (ce que je déconseille fortement), comment formater les commentaires dans ces cas ? Psychoslave (discussion) 1 juin 2021 à 08:38 (UTC)

Faut que je regarde quelle est la convention dans la communauté Lua pour noter les cas d’erreur. Pour l’instant j’ai juste mis une petite phrase dans le corps de la doc. Pour le nom de la fonction, j’ai revert, format ne me parait pas plus clair, format_example me semble plus adapté. Par contre, essaye de garder les discussions de modules spécifiques sur les PDD des modules en question, ça évite de s’éparpiller. Darmo (Viendez parler !) 1 juin 2021 à 10:53 (UTC)

Je suppose que ça peut dépendre d’un projet à l’autre côté convention Lua. C’est LDoc qui semble le plus populaire, dont voici la liste des tags pris en compte.

Ça indique notamment que return peut être fourni de multiple fois, tout comme param. Il y a aussi @warning éventuellement.

Le sujet de cette section me semble plus à sa place ici, je ne donnais la référence au module exemples que pour donner du contexte et une illustration. Psychoslave (discussion) 1 juin 2021 à 16:51 (UTC)

Catégorisation ?

Comment fait-on pour catégoriser un module ? Catégorie:Modules à Wiktionnariser a besoin d’en inclure un certain nombre... Urhixidur (discussion) 8 mai 2024 à 14:18 (UTC)

J’ai trouvé: il faut ajouter à /Documentation :

<includeonly>
[[Catégorie:Modules à Wiktionnariser]]
</includeonly>