Discussion utilisateur:Od1n/Archives 2022

{{Titre sans précision}}

Salut et bonne année. Je viens de voir cette modif et ton commentaire de diff associé. Je ne connaissais pas ce modèle mais vu que j'étais un peu à l'origine de l'initiation des infobox v3 et des usages que je connais sur les infobox, il y a très peu de cas ou l'insertion dans l'infobox v3 cassera le titre de l'infobox. Donc, je suis plutôt pour son insertion dans l'infobox directement (après il faudra faire le ménage sur les infobox où tu l'as inséré ). 'toff ^[discut.] 1 janvier 2022 à 18:29 (CET)

Salut 'toff et bonne année aussi. L'implémentation du {{Titre sans précision}} directement dans la brique {{Infobox V3/Début}} (et pourquoi pas aussi dans les infoboxes V2) pourra effectivement permettre de généraliser ce traitement, et de simplifier tous les modèles d'infoboxes, qui n'auront plus besoin d'y faire appel explicitement. Pour ce qui est de nettoyer les utilisations déjà présentes dans les infoboxes, cela devrait pouvoir se réaliser programmatiquement sans trop de difficultés. Si jamais tu penses à des cas où ce {{Titre sans précision}} pourrait produire des résultats erronées, n'hésite pas à en faire part, ça serait grandement utile. od†n ↗^blah 3 janvier 2022 à 18:46 (CET)

Bonjour ! Bonne idée, attention toutes fois aux effets de bord des Infobox qui ont un nom construit avec d'autres informations entre parenthèses (autre nom, date...). Par exemple en V2, Modèle:Infobox Cours d'eau, Modèle:Infobox Personnalité militaire et Modèle:Infobox Système d'écriture. Et d'autres trouvées en cherchant dans les statistiques. En V3, il y a par exemple, Modèle:Infobox Pays. --FDo64 (discuter) 3 janvier 2022 à 20:26 (CET)

FDo64, j'ai un peu survolé les infoboxes que tu as données en exemple, mais j'ai l'impression qu'il n'y a pas de cas où il ne serait pas souhaitable de supprimer la partie entre parenthèses ? od†n ↗^blah 10 janvier 2022 à 06:38 (CET)

Bonsoir, j'ai effectué différents tests et en effet, mes craintes ne se sont pas vérifiées. Sans doute parce que les parenthèses sont toujours précédées d'un saut de ligne ? --FDo64 (discuter) 10 janvier 2022 à 23:56 (CET)

Tu parles du saut de ligne dans l'en-tête de l'infobox ? Dans ce cas tu as peut-être confondu : si on prend par exemple Meuse (fleuve), le « Maas, Maes, Moûse, Mosa » n'a rien à voir avec le titre de la page, c'est le paramètre autres noms de l'infobox. Et je précise aussi, le modèle {{Titre sans précision}} supprime tout suffixe entre parenthèses, peu importe son contenu, que cela soit « (film, 1956) », « (fleuve) » ou « (f̵̳̉ͭ̉̐ͬͣ︣͒͑l̵̲̇̉e̷̢̝ͭ̈͗̚u̶̞̻᷊̯̮̎︡ͭv̴̱̖̭̦̤̮̘̖̘͖͌᷾ͫ̉︠͡e̶͇͕͔︢̈̌) ». od†n ↗^blah 11 janvier 2022 à 03:57 (CET)

Salut !

Comme ci-dessus je ne voyais pas la solution que tu envisageais, j'avais imaginé dans {{Infobox V3/Début}} quelque chose de très simple mais qui au final est plus risqué :

|{{Titre sans précision|{{{text|}}}}}

Maintenant j'imagine que tu as prévu la syntaxe suivante :

|{{#if:{{{text|}}}|{{{text|}}}|{{Titre sans précision}}}}

Donc tout va bien !

--FDo64 (discuter) 11 janvier 2022 à 23:51 (CET)

How we will see unregistered users

Bonjour !

Vous recevez ce message parce que vous êtes un administrateur ou une administratrice sur un wiki Wikimedia.

Aujourd'hui, lorsqu'une personne modifie un wiki Wikimedia sans être connectée, nous affichons son adresse IP. Comme vous le savez peut-être déjà, nous ne serons plus en mesure de le faire à l'avenir. Il s'agit d'une décision du service juridique de la Fondation Wikimedia, car les normes et réglementations en matière de confidentialité en ligne ont changé.

Au lieu de l'IP, nous allons montrer une identité masquée. Du fait de votre statut d'admin, vous pourrez toujours accéder à l'adresse IP. Il y aura également un nouveau droit d'utilisateur pour celles et ceux qui ne sont pas admin mais qui ont besoin de voir les IP complètes, afin de lutter contre le vandalisme, le harcèlement et le spam. Les patrouilleurs et patrouilleuses verront également une partie de l'IP même sans ce droit d'utilisateur. Nous travaillons également sur de meilleurs outils pour faciliter la maintenance des wikis.

Si vous ne l'avez pas encore fait, vous pouvez en savoir plus sur Meta. Si vous voulez être sûr de ne pas manquer les changements techniques sur les wikis Wikimedia, vous pouvez vous inscrire à aux actualités techniques hebdomadaires (Tech News).

Nous avons deux propositions concernant le possible fonctionnement de cette identité. Nous apprécierions vos commentaires sur la façon dont vous pensez que cela fonctionnerait le mieux pour vous et votre wiki, maintenant et à l'avenir. Vous pouvez nous laisser un message sur la page de discussion. Vous pouvez écrire dans votre langue. Les suggestions ont été publiées en octobre et nous déciderons après le 17 janvier.

Merci. /Johan (WMF)

4 janvier 2022 à 19:15 (CET)

Vector et MediaWiki:Common.css 

Bonjour, par rapport à cette modification, s'il te plaît ne supprime pas la modification de @Jon (WMF): l'équipe Web est en train de fixer un problème avec le nouvel entête figé, demais cela sera résolu, mais ils ont besoin de cette modification pour progresser. Jon vient de m'écrire que selon lui ce serait préferable de ne pas avoir l'entête sur la page d'accueil de Monobook jusqu'à jeudi plutôt que de casser l'entête figé de tous les utilisateurs connectés qui utilisent Vector". C'est vraiment temporaire. Merci pour ton attention.--Patafisik (WMF) (discuter) 12 janvier 2022 à 19:21 (CET)

Hello, now that the issues have been pinpointed and that they are being worked on, I won't touch the upcoming edits. You can redo the changes in the Common.css and in the messages, as you see fit. Regards, od†n ↗^blah 12 janvier 2022 à 20:03 (CET)

By the way, refs this topic you posted too. od†n ↗^blah 12 janvier 2022 à 20:08 (CET)

@Jon (WMF)--Patafisik (WMF) (discuter) 12 janvier 2022 à 20:08 (CET)

J'ai rétabli comme souhaité : Common.css, messages Mainpage-title et Mainpage-title-loggedin .

À propos de ce que tu as écrit, « ne pas avoir l'entête sur la page d'accueil de Monobook jusqu'à jeudi », ça ne serait pas plutôt le contraire ? À savoir l'en-tête qui s'affiche temporairement jusqu'à jeudi, au lieu d'être masquée.

od†n ↗^blah 12 janvier 2022 à 20:51 (CET)

Utilisateur:Od1n Tomorrow PM all issues raised should have been addressed. If not, I'll make sure to provide the necessary backports ASAP.

Regarding Monobook, the following change will hide the header on the MonoBook homepage for now, but it can be removed (reverted) safely when this week's deploy is complete:

https://fr.wikipedia.org/w/index.php?title=MediaWiki%3AMonobook.css&type=revision&diff=189832648&oldid=189745818 Jon (WMF) (discuter) 12 janvier 2022 à 23:27 (CET)

Siècles en majuscules

Bonsoir Od1n, merci pour la modification sur Divyavadana. Il faut donc systématiquement utiliser les majuscules pour les différents modèles "siècle"?
Je suis retourné sur la page et je vois en effet que tous les modèles sont notés avec le nombre en majuscules. Mais p-ê serait-il bien de spécifier clairement au début de la page qu'il faut utiliser les maj.? Pour moi, le système fonctionnant avec les minuscules, je ne suis pas allé voir plus loin...; d'autant que c'est plus rapide, puisqu'on n'a pas besoin d'activer la touche maj. Et comme l'être humain est naturellement paresseux... Cordialement, Dawamne (discuter) 20 janvier 2022 à 21:25 (CET)

Bonjour,

Je pars du principe que la saisie en majuscules dans le code est beaucoup moins déroutante : 1) le code ressemble davantage à ce qui est affiché, 2) ça fait vraiment bizarre de voir un siècle écrit en minuscules, et 3) une immense majorité des contributeurs écrivent comme cela, donc c'est plus uniforme et moins surprenant.

Cela étant, à ce jour ça fonctionne aussi si on saisit en minuscules (car un CSS "normalise" l'affichage), et cela ne devrait pas changer dans l'immédiat. Disons que je passe sur les articles pour corriger/uniformiser les codes, c'est toujours bon à prendre et cela prépare le terrain en cas de changements ultérieurs au niveau des modèles.

En tout cas, ne te tracasse pas avec cela, mon objectif est de simplifier les codes pour les contributeurs ;) Si je remplace les siècles saisis en minuscules, pour l'instant c'est seulement pour limiter leur propagation, voir s'ils ont tendance à revenir…

Mais sinon, tu as essayé de saisir les siècles en majuscules non pas avec le caps lock, mais avec la touche shift ? Parce que j'en conviens qu'avec le caps lock ça doit être la plaie, mais avec le shift ça passe crème.

od†n ↗^blah 21 janvier 2022 à 02:22 (CET)

Merci pour ta réponse. Oui, j'utilise aussi le shift, mais cela reste malgré tout plus "pesant". Cela dit, c'est un détail et j'utiliserai désormais les majuscules. Bonne suite, Dawamne (discuter) 21 janvier 2022 à 09:01 (CET)

Je suis content

Bonjour,

En parcourant l'historique d'un modèle sur lequel j'ai travaillé, j'ai vu votre pseudo. En parcourant votre historique de contributions, j'observe que vous êtes toujours actif ici. Je suis content de vous savoir parmi nous.

— Cantons-de-l'Est ^p|d|d [‌sysop] 6 mars 2022 à 13:37 (CET)

Et oui, toujours là ! Il faut faire des choix et j'essaie de limiter l'investissement en temps dans Wikipédia, mais je garde toujours un pied ici. Merci pour le message, ça fait plaisir. J'espère que les choses vont bien aussi de votre côté. od†n ↗^blah 7 mars 2022 à 03:14 (CET)

Merci aussi pour avoir maintenu les modules que j'ai créé ou développé il y a quelques années. Désolé pour le manque de commentaire pertinents, les nombreuses faute d'orthographe dans ceux que j'avais écris, et un code parfois (souvent ?) obscur. — Zebulon84 (discuter) 7 mars 2022 à 14:06 (CET)

Zebulon84 après une longue absence je t'avais effectivement vu revenir, c'était assez inespéré et ça a été vraiment une bonne surprise. Aucun problème avec ton approche productive, je vois d'autres personnes qui fonctionnent comme ça, en y réfléchissant je me rends compte que ça a le mérite de faire avancer les choses, et c'est préférable à mon approche perfectionniste (ce qui en réalité est plus un défaut qu'une qualité), où à vouloir faire le mieux dès le départ finalement rien n'est fait. J'en profite donc pour te souhaiter un bon retour, d'autant plus qu'on est plutôt en manque de main-d'œuvre technique. od†n ↗^blah 10 mars 2022 à 01:59 (CET)

Demande d'import d'un modèle très utile

Bonjour. J'ai demandé il y a une semaine sur le Bistro s'il était possible d'importer en:Template:Reflist-talk. Puisque personne ne l'a fait et que je sais que tu es capable de te débrouiller en codage, je te demande directement : pourrais-tu importer ce modèle, sous le nom de "Reflist-discussion", avec "Reflist-talk" comme autre nom possible ? Veverve (discuter) 27 mars 2022 à 20:02 (CEST)

Bonjour, c'est un modèle qui semble effectivement être assez utilisé. En revanche je n'ai vraiment plus le temps de me lancer dans des chantiers supplémentaires. Si tu as demandé seulement sur le bistro, ce n'est pas surprenant que la demande n'ait pas encore trouvé du monde pour s'en charger. Le mieux serait que tu postes une demande sur Projet:Modèle/Demandes. od†n ↗^blah 28 mars 2022 à 02:56 (CEST)

Pour information, Zebulon84 a traité la demande ici : Projet:Modèle/Demandes/2022#Demande d'import d'un modèle très utile, Template:Reflist-talk. od†n ↗^blah 19 avril 2022 à 07:56 (CEST)

Questions : Diff et Palettes

Bonjour Od1n. Pour ma gouverne, ce type de modification présente-t-il un intérêt ?

Aurais-tu une idée pour Discussion modèle:Méta palette de navigation#Palettes enroulées par défaut ? Merci. — Ideawipik (discuter) 6 mai 2022 à 23:50 (CEST)

Bonjour,

Alors pour le premier point : j'ai voulu avoir l'icône de lien externe pour augmenter la visibilité du lien. Un autre avantage est que l'URL est plus descriptive, notamment car on voit le nom de la page. En fait à l'époque j'avais utilisé la syntaxe "spécial:diff" par erreur, étant habitué à l'utiliser dans les résumés de modif où elle est la seule possible. Enfin, dans cette pdd de module on peut se permettre d'ajouter une modif mineure car la page est vraiment légère en octets et avec un historique court.

Pour le deuxième point : j'avais vu passer cette discussion, mais je n'avais pas trouvé d'explication. Le code fonctionne actuellement comme prévu, et si les palettes ne s'enroulaient pas chez cet utilisateur, je penchais pour une erreur JavaScript qui aurait interrompu l'exécution du code avant d'arriver au code pour les palettes dans le Common.js, mais j'avais vérifié son common.js, etc. et je n'avais pas repéré d'erreur.

od†n ↗^blah 7 mai 2022 à 02:37 (CEST)

Pour approfondir le deuxième point : j'ai encore cherché, et vraiment je ne vois rien qui a été changé. Ça replie à partir de deux palettes, et c'est comme ça depuis longtemps.

Je vais évoquer une solution, mais uniquement pour l'éliminer d'emblée : il serait techniquement possible de mettre les palettes dans des "groupes d'autocollapse" distincts, refs discussion, implémentation et attributs "data-autocollapse-group", mais cela nécessiterait d'implémenter un nouveau paramètre dans le modèle {{Méta palette de navigation}} afin de pouvoir overrider la valeur d'attribut data-autocollapse-group="palette", et je ne suis pas sûr qu'il soit souhaitable de complexifier le modèle de la sorte.

od†n ↗^blah 7 mai 2022 à 03:10 (CEST)

Une autre possibilité serait de modifier le module:Palette pour qu'il change le data-autocollapse-group de chaque palette pour un identifiant lié au palettes à afficher par le module (hash du nom des palettes par exemple) de façon à ce que chaque groupe de palette agisse séparément. — Zebulon84 (discuter) 7 mai 2022 à 08:44 (CEST)

Mais ça ne serait pas compatible avec le cas « {{Palette Foo}} \n {{Palette Bar}} » (pas d'utilisation de modèle {{Palette}} englobant) ; bon à la rigueur, ça ne serait pas trop un problème.

Plus problématique, le modèle {{Palette}} a déjà un code un peu tordu, en gros avec parentFrame.args qui contient les noms de palettes et frame.args qui contient carrément le code wiki des palettes ; et parentFrame.args peut aussi contenir des codes wiki de palettes (voir cette discussion), donc il serait possible que le hash se fasse carrément sur le code wiki de palettes, au lieu de leur nom.

Une autre solution à laquelle j'aurais pensé, dans le code JavaScript :

if ($table.closest('.documentation')) {
    collapseGroup = 'palette-documentation';
} else {
    collapseGroup = 'palette';
}

La solution me semble attrayante de prime abord, mais attention. Ce changement est-il vraiment justifié ? Pour ce genre de rajouts je préfère être prudent, pour ne pas complexifier le code si ce n'est pas nécessaire.

od†n ↗^blah 7 mai 2022 à 16:36 (CEST)

Oui, ce n'est probablement pas justifié. Autre solution assez simple à laquelle je pense, que {{Méta palette de navigation}} mette l'état à uncollapsed si le nom de la page correspond au contenu du paramètre modèle :

{{#if:{{{étatboîte|}}}|{{{étatboîte}}}|{{#ifeq:{{{modèle}}}|{{PAGENAME}}|uncollapsed|autocollapse}} }}

Pour ce qui est du code des palettes dans le frame.args, mes premières versions n'avaient évidement pas cette scorie, mais on se retrouvait souvent en erreur de script pour temps lua dépassé sur les pages avec pas mal de palettes.  — Zebulon84 (discuter) 7 mai 2022 à 23:51 (CEST)

Pour revenir rapidement sur ton idée d'ajouter des identifiants uniques aux groupes de palettes, en fait il n'y aurait pas besoin de générer des hashes uniques. Il serait fonctionnellement identique, et probablement plus simple, de modifier le JavaScript pour qu'il traite chaque navbox-container séparément. Mais de toute façon, le problème de cette approche est qu'elle ne gère pas du tout les divers cas où les palettes sont utilisées directement, sans passer par le modèle {{Palette}}.

Pour ce qui est de mettre en "uncollapsed" la palette lorsque l'on se trouve sur sa propre page, un problème par exemple est qu'il m'arrive de naviguer sur des pages de palettes pour repérer celles qui sont en "collapsed" mais qui sont assez petites, pour les passer en "autocollapse". Avec ce changement, il ne me serait plus possible de repérer ces palettes, ou alors il faudrait passer en "uncollapsed" seulement celles qui sont en "autocollapse" et ne pas changer l'affichage de celles en "collapsed" ; mais j'ai le sentiment que cela nous fait rentrer dans de la gestion vraiment trop spécifique.

Par contre je repense à l'idée du "collapse group palette-documentation" que j'ai mise plus haut, elle n'est peut-être pas si mal (avec éventuellement un test "namespace == 10" si cela permet d'améliorer les performances en évitant le .closest() sur les autres namespaces). J'aime bien l'idée que cela empêche les éventuelles palettes présentes dans la documentation d'interférer avec le autocollapse du modèle qui est affiché directement sur la page ; et j'imagine qu'il existe des modèles constitués de plusieurs palettes…

od†n ↗^blah 8 mai 2022 à 10:16 (CEST)

Bien entendu, sur une page comme actuellement Modèle:Palette Dème de Thessalonique, il faudrait que la palette qui est tout en bas soit déplacée à l'intérieur de la documentation ; comme c'est par exemple le cas sur la page Modèle:Palette Alberta. od†n ↗^blah 8 mai 2022 à 10:21 (CEST)

Le code qui serait à ajouter pour mettre en œuvre cette fonctionnalité :

// groupe distinct pour les palettes qui se trouvent à l'intérieur des documentations de modèle
if ( group === 'palette' && mw.config.get( 'wgNamespaceNumber' ) === 10 ) {
	if ( Element.prototype.closest ? table.closest( '.documentation' ) : $table.closest( '.documentation' ).length ) {
		group = 'palette-documentation';
	}
}

(à noter que lorsque MediaWiki n'exécutera plus le JavaScript sur IE11, le .closest() natif sera toujours disponible et il sera possible de simplifier le code)

Qu'en dites-vous ? od†n ↗^blah 9 mai 2022 à 03:07 (CEST)

Cela me semble plus complexe que de remplacer autocollapse par {{#ifeq:{{{modèle}}}|{{PAGENAME}}|uncollapsed|autocollapse}}, et le code wiki d'un modèle est plus naturel pour le wikipédien que le javascript, si quelqu'un cherche pourquoi les palettes ne sont pas repliées ; mais ma solution ne laisse dépliée que la palette codée, pas la ou les palettes qui sont dans la documentation. À toi de voir, de toute façon n'étant pas admin, je ne peux rien faire. — Zebulon84 (discuter) 9 mai 2022 à 08:06 (CEST)

Un autre problème est que comme toutes les palettes sont comptées, quel que soit leur paramètre étatboîte (et pas seulement celles qui sont en autocollapse), voici ce que l'on peut avoir : si on a une palette affichée directement avant la documentation, et une palette à l'intérieur de la documentation, qui est en autocollapse, cette dernière sera enroulée en raison de la première palette qui est aussi comptée.

Pour ma part je pense que les solutions à retenir seraient :

• soit mon système pour compter séparément les palettes qui se trouvent dans les documentations
• soit compter séparément à l'intérieur de chaque conteneur navbox-container (i.e. considérer chaque groupe de palettes comme un "groupe autocollapse" distinct), ce qui pourrait aussi avoir son intérêt pour les articles qui placent des palettes aussi dans le corps de l'article. Pour ce qui est des palettes utilisées directement (sans le modèle {{Palette}} donc sans conteneur navbox-container), je pense que cela devrait être gérable au niveau du code, elles seraient simplement équivalentes à un groupe d'une seule palette.

od†n ↗^blah 9 mai 2022 à 16:58 (CEST)

Cette dernière solution moins spécifique me paraît plus pertinente. Zebulon84 (discuter) 9 mai 2022 à 18:34 (CEST)

Pour cette solution, le code n'est peut-être pas si simple que je l'imaginais… ça serait quelque chose dans ce genre :

var tableGroups = new WeakMap();
var groupLengths = new WeakMap();

$tables.each( function ( _, table ) {
	var group = $( table ).closest( '.navbox-container' )[ 0 ];
	if ( group ) {
		tableGroups.set( table, group );
		groupLengths.set( group, ( groupLengths.get( group ) || 0 ) + 1 );
	}
} );

$tables.each( function ( _, table ) {
	var collapsed = false;
	if ( table.classList.contains( 'autocollapse' ) ) {
		var group = tableGroups.get( table );
		if ( group && groupLengths.get( group ) > Palette_max ) {
			collapsed = true;
		}
	} else if ( table.classList.contains( 'collapsed' ) ) {
		collapsed = true;
	}
	// ...
} );

Notes :

• avec cette solution, le système d'attributs data "autocollapse group" deviendrait caduc.
• pour rappel, on parcourt deux fois $tables ; il est nécessaire de parcourir une première fois pour connaître le nombre de tables par groupe.

od†n ↗^blah 10 mai 2022 à 01:53 (CEST)

Je viens d'implémenter cette solution, avec une approche plus simple : voir 198621034 (ainsi que 198621067 et 198621069). od†n ↗^blah 13 novembre 2022 à 01:02 (CET)

Je suis tombé sur {{Palette Attraction Disney}}, qui imbrique des {{Méta palette de navigation}}, et je me suis aussi souvenu de {{Méta palette de navigation sous-liste}}. Après avoir pas mal réfléchi au problème, je suis parvenu à cette solution, qui permet au "autocollapse" de fonctionner comme attendu également en cas de palettes imbriquées. Je suis revenu à l'approche consistant à remonter à partir de la palette pour trouver son (éventuel) conteneur le plus immédiat, car avec les nouveaux cas de figure supportés, c'est maintenant l'approche qui s'avère à la fois la plus fiable et la plus simple. od†n ↗^blah 17 novembre 2022 à 10:09 (CET)

Extrait/Excerpt

Bonsoir,

Je suis tombé dessus par hasard, mais 100% des articles de mon échantillonnage incluant le {{extrait}} et avec des ref dans cet extrait, posent un problème. Bon, soyons honnête, 100% ça fait 2 articles :

• Konso (woreda)#Préhistoire
• Bardonnex#Conseil municipal

Les ref ne passent pas et nous gratifient d'un beau Erreur de référence : Balise <ref> incorrecte : les références sans nom doivent avoir un contenu. Bon en fait dans le cas de Bardonnex ce n'est pas si net puisque seule la première des trois référence rate, d'où ma tentative de correction sur la loi Suisse, un bel échec. Par contre pour Konso c'est une ref tout à fait standard.

Bref vu que tu as l'air de maîtriser le module excerpt (et en être le seul auteur francophone), peut-être que tu as une idée.

Bonne soirée, Gaillac (discuter) 14 juin 2022 à 22:24 (CEST)

Bon je rajoute ReCAPTCHA#Collecte de données et Notaire#Suisse, avec des petites variations sur certaines ref qui posent problème. Mon échantillonnage prend de l'ampleur, quatre sur quatre ;-) Gaillac (discuter) 14 juin 2022 à 22:31 (CEST)

Bonjour, c'est un module sur lequel je n'ai jamais travaillé (excepté une correction mineure), et dont à propos l'utilisation me semble assez risquée (par exemple, si dans l'article inclus des paragraphes sont ajoutés/supprimés, leurs numéros sont décalés). En tout cas, le problème que tu as signalé semble avoir été corrigé dans cette mise à jour récente (et qui inclut ma correction mineure, que l'auteur a dû remarquer). Voir aussi cette discussion sur le sujet. od†n ↗^blah 15 juin 2022 à 14:47 (CEST)

Espaces insécables inopinées

Bonjour Od1n, je régis à cette modif : d'où sortent ces insécables ? Elles n'ont pas été posées volontairement il me semble, alors est-ce que ça viendrait d'un outil utilisé pour éditer les pages (je pense à un traitement de texte) qui ferait ça tout seul à l'insu de la pcW ? Et comment les repérez-vous ? En cherchant les   dans le html de de la page ? Bien à vous, -- 🐜 jilucorg ✉ 20 juin 2022 à 09:17 (CEST)

Il s'agit de recherches que j'ai effectuées avec l'outil wstat.fr : sur le paramètre "pages totales" et sur le paramètre "pages" (la zone de saisie contient une espace insécable, Alt+0160).

Je me rends ensuite sur la page en question, puis sur "Modifier le code", ensuite je sélectionne tout, je copie puis colle, ce qui fait sauter les espaces insécables (elles sont remplacées par des espaces simples), et enfin je fais "Voir les modifications" pour voir les changements que cela a effectué.

Pour ce qui est de l'origine de telles espaces insécables, je ne sais pas trop, je sais juste que quand on fait de la maintenance sur le wiki, on tombe souvent sur des trucs vraiment improbables ! L'hypothèse la plus probable serait l'utilisation d'un éditeur de texte externe genre Word, en effet.

od†n ↗^blah 20 juin 2022 à 15:36 (CEST)

Merci pour cette explication détaillée ! -- 🐜 jilucorg ✉ 20 juin 2022 à 16:13 (CEST)

Code IETF du moldave déprécié

Bonjour Od1n

Je suis passé sur Module:Langue/Data et j'ai vu ta modif du 1er juin 2022 [1]

Pour info, le problème avec le code mo ne date pas d'hier (cf. [2])

En bref, le code du moldave est déprécié depuis 2008, il faut utiliser celui du roumain.

Il est vraiment improbable que ce code soit utilisé de nouveau et je ne suis pas du tout sûr qu'utiliser ro-MD soit la chose à faire (l'IETF préconise d'utiliser seulement ro, voir sur https://r12a.github.io/app-subtags/ (Find > "moldovan"). )

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 1 juillet 2022 à 18:25 (CEST)

Bonjour, je m'étais penché sur la question, avant de constater qu'en fait, il est tout simplement impossible d'avoir dans ce module de données deux langues avec un même code. C'est une contrainte purement technique, pour laquelle on ne peut pas faire grand chose.

Prenant acte de la contrainte technique, qui d'une certaine façon coupe court au débat, j'ai ensuite trouvé le code ro-MD, que l'on peut malgré tout estimer convenable pour notre utilisation (même s'il est remis en question, au moins on comprend ce qu'il désigne), et je suis donc parvenu à cette solution "la moins pire".

od†n ↗^blah 2 juillet 2022 à 00:49 (CEST)

En fait, j'avais fini par trouver qu'il avait été proposé d'utiliser ro-Cyrl-MD[3] mais ça a été abandonné (d'ailleurs le « moldave » s'écrit aussi avec l'alphabet romain, c'est celui-ci qui est utilisé par l'administration, sur les billets,les panneaux routiers, etc.).

D'ailleurs, [4] à fermé en 2006 et est maintenant redirigé sur ro.wp.

Sinon, je ne pense pas qu'il faille créer nous même des usages pour les codes de langue quand l'IETF dit explicitement le contraire. S'il y a un problème, c'est à la source, sur l'IETF qu'il faut le régler, pas sur Wikipédia.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 2 juillet 2022 à 16:35 (CEST)

La seule autre solution, techniquement possible, serait que « moldave » soit un alias pour le « roumain / ro ». Cela signifierait que les deux langues seraient techniquement équivalentes (correspondant à la même table dans les données). Ainsi :

• {{code langue|roumain}} et {{code langue|moldave}} donneraient tous deux « ro »
• {{nom langue|ro}} donnerait « roumain », en revanche :
  • il ne serait plus possible d'obtenir le nom « moldave » à partir d'un code de langue
  • {{nom langue|mo}} serait bien reconnu comme invalide, mais enverrait vers « roumain / ro ».

Mais si tu trouves que c'est une moins pire solution, pourquoi pas. od†n ↗^blah 12 juillet 2022 à 01:02 (CEST)

Je croyais que c'était déjà le cas mais en fait non, je viens de rectifier [5]. J'avais déjà corrigé {{mo}} et l'article Moldave (qui est d'ailleurs une grosse synthèse inédite). Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 12 juillet 2022 à 12:05 (CEST)

En fait ce à quoi j'avais pensé, c'était carrément de mettre "moldave" en nom supplémentaire dans la ligne "ro/roumain", c'est-à-dire complètement un alias.

Mais j'ai testé les résultats avec la manière dont tu as renseigné les données, et apparemment c'est correct. J'ai aussi confirmé en étudiant la construction pas-à-pas des données finales, et ça semble bien fonctionner.

Si on creuse un peu, les lignes "mo" et "ro-MD" ne rentrent pas en conflit car elles ont à la fois le même nom et redirigent vers le même code. C'est-à-dire qu'il n'y en a pas une qui va écraser les données de la précédente avec des données différentes. Néanmoins, vu que le "ro-MD" c'est un truc que j'avais ajouté, peut-être pourrait-on supprimer cette ligne.

od†n ↗^blah 25 juillet 2022 à 23:27 (CEST)

Le truc c'est que si on met « moldave » en alias de « roumain », ça ne sert que si on met moldave en valeur de paramètre (cas très rare à mon avis, les alias ne servent vraiment que pour les langues très utilisées, par une très petite partie des contributeurs, genre english à la place de en ou anglais), les valeurs mo restantes ou futures ne seront pas reconnues et feront une erreur.

Avec mo = { "moldave", invalide = "ro" }, on n'a pas ce problème, on affiche au survol que c'est en moldave (en affichant à l'écran le code ro), et on garde dans la liste que le code mo est bien invalide.

C'est la même chose avec ro-MD, il n'y a pas de problème de garder ce code dans la liste, il est techniquement valide (après on peut discuter de s'il vaut mieux afficher « moldave », « roumain » ou « roumain de Moldavie », mais c'est beaucoup d'histoire pour pas grand chose, et même l'IETF n'est pas très clair au sujet de l'usage des codes de région).

Ce n'est pas moi mais Zebulon84 qui a codé le truc, et je ne connais pas toutes les subtilités, mais ça ne me semble pas une bonne idée d'avoir des codes IETF en alias (j'ai d'ailleurs récemment enlevé un code ma qui était en alias pour l'arabe marocain : voir lignes 72 & 732, c'est le même problème de code invalide).

Je viens de corriger pas mal d'erreurs, mais il doit en rester d'autres, difficiles à repérer si on ne connait pas les codes corrects et les articles liés. Heureusement cette page n'est pas trop modifiée par le commun des contributeurs... Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 26 juillet 2022 à 01:30 (CEST)

Module Noble

Merci d'avoir attiré mon attention sur un morceau de code un peu trop cryptique. J'ai viré le string.find() et je l'ai remplacé par du code un peu plus long mais j'espère plus clair, avec quelques exemples.

Amicalement, Alserv (discuter) 11 juillet 2022 à 13:42 (CEST)

Le Module:Noble a effectivement bonne allure. De plus, les exemples que tu as ajoutés en commentaires sont vraiment utiles pour répertorier les cas de figures à supporter. od†n ↗^blah 12 juillet 2022 à 01:07 (CEST)

Modèle:A : ancres, performances, affichage incomplets.

Bonjour Od1n. Comme on pouvait s'y attendre, l'ajout d'une ancre pour les appels avec une majuscule au nom du modèle (diff) fait grossir la taille des pages, après expansion du modèle. Ainsi, la quasi-totalité des pages d'archive de WP:Demande de suppression immédiate depuis 2020 et beaucoup depuis 2016 (Archive56) sont entrées dans la catégorie:Page contenant trop d'inclusions de modèles. Il est peut-être préférable de faire machine arrière. L'intérêt des liens ancrés sur les pages d'archive est très faible. Les liens depuis l'historique de ces pages sont inexistants. Si la majorité des appels actuels se font avec les minuscules, autant laisser cela, comme avant (paramètre modèle depuis 2014). À mon avis, il vaut mieux avoir un affichage complet (avec des sections intelligibles et des liens internes, utiles notamment pour la recherche parmi les pages liées), au détriment d'ancres que personne n'utilise puisqu'elle n'étaient pas fonctionnelles avant ta modification du 6 septembre. Par ailleurs, les statistiques de début septembre ne montrent, parmi les 12 158 portant le modèle A, que 1479 pages avec des appels "en majuscule" pour plus de 10 000 avec une minuscule. De même, pour le modèle {{A'}}, on a 72 pages avec « A' » contre 387 avec « a' » et pour ce même modèle, 23 pages avec une redirection en « A- » contre 753 avec « a- ». Le bénéfice/coût semble assez bas. Et on gagnerait en temps de chargement des pages. À moins qu'on puisse faire des économies ailleurs dans le modèle {{A}}. Une autre "solution" pourrait-être de copier le code de A directement dans A' (et autres A-court, A-dpp), en retirant ce qui est inutile. Ainsi, on s'affranchirait du comptage en double dû à l'imbrication des modèles, mais on perdrait la factorisation du code. — Ideawipik (discuter) 14 septembre 2022 à 09:07 (CEST)

Bonjour Ideawipik. Merci pour ce signalement, encore une fois fort bien détaillé. Je ne pense pas que cette modification soit allée ajouter un poids vraiment important, le problème est plutôt que nous étions déjà vraiiiiiment à la limite (et le modèle étant utilisé un grand nombre de fois, le moindre alourdissement est démultiplié). Du coup, j'ai annulé 196751924 (mais j'ai laissé pour l'instant 196751710, dont l'impact devrait être quand même faible).

• Pour ce qui est de recopier le code de {{a}} dans {{a'}} (ainsi que {{a-court}} et {{a-dpp}}), on perdrait effectivement grandement en factorisation de code. Mais je pense que cela peut être envisagé, à titre exceptionnel, étant donné qu'il y a un problème manifeste de taille post-expand avec ces modèles qui sont utilisés un très grand nombre de fois sur certaines pages, et si j'ai bien compris, cette modification permettrait en gros de diviser le post-expand size par deux. Un point qui nous arrange, c'est que ces modèles sont modifiés assez peu souvent. Aussi, il est important de mentionner les modèles entre eux, afin qu'en cas de modifications sur l'un, on pense bien à mettre à jour les autres (c'est d'ailleurs pour cela que je suis intervenu sur les documentations de {{a'}}, {{a-court}} et {{a-dpp}}), après avoir transformé ces deux derniers en recopies de code du premier).
• Une piste complémentaire à envisager serait d'inliner le code de {{abréviation discrète}}. Cela permettrait de gratter quand même significativement en performances, et ça serait acceptable dans la mesure où le modèle {{abréviation discrète}} est stable (i.e. change peu), et que la classe "abbr" est déjà beaucoup utilisée séparément (i.e. sans passer par le modèle) sur le wiki. Enfin, une recherche (<abbr class="abbr[ ]"> reste techniquement réalisable afin de détecter toutes (ou presque) les utilisations manuelles de la classe. D'ailleurs, dans le « NewPP » de par exemple la page Wikipédia:Demande de suppression immédiate/Archives automatiques138 qui continue de poser des problèmes de performances, on voit tout de suite que les {{abréviation discrète}} ont un temps d'exécution significatif (ce qui n'est pas dû au modèle en lui-même, mais à son nombre d'inclusions) :

Transclusion expansion time report (%,ms,calls,template)
100.00% 1248.552      1 -total
 82.81% 1033.915   1268 Modèle:A'
 74.88%  934.900   1268 Modèle:A
 32.30%  403.323   2536 Modèle:Abréviation_discrète
  1.59%   19.889    149 Utilisateur:Gratus/PaStec/motif_SI
  1.52%   18.996      6 Modèle:Ping
  0.53%    6.569      2 Modèle:User
  0.43%    5.371      1 Modèle:Citation
  0.36%    4.488      3 Modèle:Notif
  0.35%    4.421      2 Modèle:Merci

Est-ce que tu valides pour effectuer ces deux modifications ?

od†n ↗^blah 19 septembre 2022 à 15:47 (CEST)

Bonjour Od1n. Bien vu le coup (et coût) de l'appel du modèle d’abréviation discrète dans {{A}}. Tu peux peut-être commencer par là. Et, si cela ne suffit pas, appliquer la "défactorisation généralisée" envisagée dans le premier point. Merci !

Ce qui explique aussi le problème pour la page donnée en exemple est la présence de plusieurs demandes groupées. Donc un ratio nombre de modèles par kilo-octet de wikicode plus élevé que s'il n'y avait qu'un seul modèle par section. J'avoue que je trouve généralement plus logiques les demandes groupées circonstanciées que la multiplication des sections et éditions de la page de requêtes pour des demandes similaires. On peut envisager de réduire légèrement la taille maximale par page d'archive (actuellement maxarchivesize = 400k) pour les demandes de suppression immédiate ou, beaucoup mieux en théorie, demander à Orlodrim (dresseur du bot d'archivage) s'il serait possible d'ajouter une contrainte sur le nombre de modèles de "type A" dans la page. — Ideawipik (discuter) 19 septembre 2022 à 18:30 (CEST)

Les deux modifications agissent sur des points différents et sont donc complémentaires. La défactorisation de {{a}} va principalement réduire le post-expand size (par deux quand même !), tandis que l'inlinage de {{abréviation discrète}} va principalement réduire le temps d'exécution (comme montré plus haut). Chacun agissant aussi sur l'autre point, mais marginalement.

La réduction du post-expand size est un impératif (sinon erreurs sur la page), et la réduction du temps d'exécution est très bonne à prendre vu comment ces pages sont lourdes à charger.

Je viens d'effectuer l'inlinage de {{abréviation discrète}}, mais comme en pouvait s'en douter il ne réduit pas suffisamment le post-expand size. La "défactorisation généralisée" sera donc aussi à effectuer.

od†n ↗^blah 20 septembre 2022 à 16:17 (CEST)

Je viens d'effectuer la "dé-factorisation" dans {{a'}}, {{a-court}} et {{a-dpp}}, et j'ai aussi ajouté un commentaire de code dans {{a}}. Comme on pouvait s'y attendre, le gain est vraiment conséquent. od†n ↗^blah 23 septembre 2022 à 06:08 (CEST)

{{Lien préfixé avec un deux-points}}

Bonjour Od1n.

J'ai vu que tu avais créé le modèle {{Lien préfixé avec un deux-points}}. Mais je l'ai vu un peu trop tard, car j'avais déjà créé {{Lien sûr}} qui fait la même chose (mais pas de la même manière). J'explique le contexte ici.

Néanmoins j'ai testé :

• ici avec le modèle que j'ai créé (ce diff est le résultat de {{subst:Test 1| Asticot| Asticothérapie| Astico-Brenta}} suivi de {{subst:User:Herr Sats/BàS modèle| Asticot| Asticothérapie| Astico-Brenta}}, où {{User:Herr Satz/BàS modèle}} est une copie de {{test 1}} en remplaçant les liens internes par {{safesubst:Lien sûr|{{{1}}}}}) et ça fonctionne.
• ici avec ton modèle (même chose qu'au point précédent, mais cette fois les liens internes étaient remplacés par {{safesubst:Lien préfixé avec un deux-points|{{{1}}}}}) et ça fonctionne aussi mais j'ai un problème avec le subst. Idéalement j'aimerais qu'il ne reste plus aucun autre code que les liens après la substitution, comme dans le test du point précédent.

Mes questions sont donc les suivantes :

• Je ne comprends pas trop le trim dont tu parlais ici quand tu as transféré le code dans {{Modèle:Lien préfixé avec un deux-points/main}}.
• Y a-t-il moyen de faire un safesubst de {{Lien préfixé avec un deux-points}} sans qu'il reste de code à la fin ? On peut mettre safesubst dans son code sans que ça n'ait d'autre conséquence ? Et le problème de la sous-page... J'avoue que je ne comprends pas grand chose aux substitutions.
• Question subsidiaire : est-ce toujours d'actualité, depuis 2021, que l'utilisation du Module:String comme je l'ai fait dans mon modèle, est plus gourmand en ressources que les if ?

En somme, que me conseilles-tu pour modifier avantageusement les modèles de messages utilisateur en adressant le problème des deux-points comme tu l'as fait avec ton modèle ? Je me demande si je ne pourrais pas simplement mettre l'appel du Module:String directement dans les modèles de message (sachant que je vais demander la suppression de mon {{Lien sûr}}, il n'est pas souhaitable qu'il subsiste deux modèles qui font la même chose).

Merci. Cordialement. — Hr. Satz 11 octobre 2022 à 21:29 (CEST)

Bonjour, je vais essayer d'apporter quelques éléments de réponse :

• Pour se prémunir de bugs en cas de présence d'espaces autour des paramètres, e.g. un modèle contenant {{Lien préfixé avec un deux-points| {{{page|}}} }} (démonstration d'espace qui se retrouverait dans le résultat : @[[PHP ]]@ donne @PHP @), j'ai voulu ajouter des {{trim}}. Problème, quand le résultat d'un modèle (en l'occurrence les {{trim}} que je souhaitais ajouter) commence par « : », MediaWiki rajoute un retour ligne au début du résultat, ce qui avait pour effet de casser les liens… Après réflexions, la meilleure solution que j'ai trouvée a été d'utiliser un sous-modèle, comme ça on peut mettre des « 1= » et « 2= » dans le modèle parent, qui ont pour effet de trimmer les paramètres transmis au sous-modèle.
• Vu comment ça complique le code, j'essaie d'implémenter les "safesubst" le moins possible. Mais si tu en as l'utilité, je viens de regarder et oui, ça peut se faire.
• C'est un modèle potentiellement utilisé un grand nombre de fois sur certaines pages, donc s'il existe une méthode n'utilisant pas Lua mais des modèles légers, et qui reste néanmoins fiable et simple, je pense que c'est à privilégier. Évidemment, si le modèle est substé et donc exécuté seulement lors de sa publication, cette question des performances ne se pose pas ; mais c'est un modèle qui est prévu à la base pour des utilisations où il n'est pas substé.

En somme, je pense qu'il suffit de rendre {{Lien préfixé avec un deux-points}} substable, et ça devrait le faire.

od†n ↗^blah 11 octobre 2022 à 23:12 (CEST)

Je viens de rendre ce modèle substable, voir mes modifs sur Modèle:Lien préfixé avec un deux-points et Modèle:Lien préfixé avec un deux-points/main. od†n ↗^blah 11 octobre 2022 à 23:27 (CEST)

Eh bien merci beaucoup d'avoir pris le temps de me lire, d'étudier la question, de me répondre très clairement, et d'avoir modifié le modèle en conséquence. Si l'ajout des safesubst ne crée pas d'effet de bord, c'est parfait.

Par conséquent {{Lien sûr}} peut être supprimé (le titre était pourri mais j'étais content de ma petite expression régulière 🤓 — mais j'ai bien compris le problème lié à l'inclusion massive de ce modèle en non substé).

Sinon question bête, il y aurait moyen de renommer {{Lien préfixé avec un deux-points}} en quelque chose d'un peu plus concis ? Genre {{Lien avec :}} ; je pense que le caractère « : » passe dans un titre de modèle, mais sinon {{Lien avec deux-points}} ? Sinon ce n'est pas grave.

Cordialement. — Hr. Satz 12 octobre 2022 à 00:39 (CEST)

Je serais d'avis de conserver le nom actuel. Tu te doutes bien qu'à l'époque j'avais longuement réfléchi au nom du modèle 😉

Il s'agit d'un modèle "technique" n'étant pas destiné à être utilisé par les rédacteurs, mais à être employé dans d'autres modèles, donc la longueur du nom n'est pas trop importante (bien entendu en restant dans le raisonnable) ; en revanche, au vu de la grande spécificité de sa fonction, il m'a paru important que son nom le décrive précisément.

J'ai donc cherché un nom décrivant la fonction du modèle sans ambiguïté, tout en restant de longueur acceptable. Je trouve que toute suppression dans le nom actuel rend celui-ci moins descriptif ou plus ambigu.

od†n ↗^blah 12 octobre 2022 à 08:13 (CEST)

Bonjour. Oui tu as raison, je n'avais pas vu les choses sous cet angle (modèle technique pas destiné aux rédacteurs) qui permet d'avoir un nom vraiment descriptif, même si un peu long. Je vais l'utiliser sous ce nom alors. Merci ! — Hr. Satz 12 octobre 2022 à 14:11 (CEST)

Doublon

Merci d'avoir viré ce doublon sur le bistro. C'est pas la première fois que ça m'arrive, c'est un bug lié à l'éditeur rapide : tu saurais où signaler ça ? Bonne soirée ! levieuxtoby ^{✍ · w (il/lui)} – le 20 octobre 2022 à 22:21 (CEST)

Pas de souci. Pour ce qui est de ces outils, et à plus forte raison sur mobile, j'imagine qu'ils ne sont peut-être pas encore totalement stables. od†n ↗^blah 20 octobre 2022 à 22:27 (CEST)

Méta palette de navigation latérale buggée

Bonjour Od1n, ta récente suppression du collapse dans les méta palette semble avoir généré un bug sur certaines palettes comme {{Palette DL}} qui n'est plus réduite par défaut malgré le paramètre étatboite à autocollapse... je te laisse voir si tu peux corriger sinon j'annule ta modif GdGourou - Talk to °o° 14 novembre 2022 à 13:28 (CET)

Bonjour GdGourou. Le modèle fonctionne en fait maintenant comme prévu (pour rappel rapide de l'autocollapse, si une palette est seule, elle est déroulée, et dès qu'il y a deux palettes, elles sont enroulées). Le problème est qu'auparavant, toutes les palettes de la page étaient comptées, et notamment aussi les palettes horizontales de bas de page classiques. Il suffisait donc qu'il y ait une autre palette verticale de la série, ou une palette horizontale en bas de page (ce qui est fréquent) alors qu'elle n'a pourtant rien à voir, pour que la palette verticale soit enroulée.

Les modifications que j'ai effectuées ont justement eu pour but de résoudre ce problème. Si des palettes sont utilisées à différents endroits (par exemple, en bas d'article comme habituellement, mais aussi en plein milieu d'article), il n'était pas normal que les palettes à un endroit affectent aussi les palettes à un autre endroit (c'est-à-dire en enroulant tout le monde, même si à chaque endroit il n'y a qu'une seule palette).

La solution, que tu as apparemment déjà trouvée sur {{Palette DL}}, consiste effectivement à passer ces palettes (je suppose toute cette série) en collapsed, afin qu'elles soient toujours enroulées initialement, ce qui est le comportement souhaité, si j'ai bien compris.

od†n ↗^blah 15 novembre 2022 à 02:00 (CET)

GdGourou, du coup c'est tout bon pour toi ? J'en profite pour mentionner la discussion précédente sur ma page, qui a conduit aux présentes modifications sur le code d'autocollapse des palettes. tl;dr : dans les palettes, et même dans les palettes imbriquées, le paramètre "autocollapse" fonctionne maintenant comme attendu, c'est-à-dire qu'elles sont maintenant enroulées quand il y en a deux au même endroit, alors qu'auparavant la présence de palettes à un autre endroit pouvait aussi causer leur enroulement. od†n ↗^blah 17 novembre 2022 à 10:17 (CET)

Oui c'est bon pour les Palettes verticales des Parcs Disney, merci. Désolé pour la brièveté assez débordé IRL --GdGourou - Talk to °o° 17 novembre 2022 à 11:51 (CET)

commons.js

Merci d'avoir optimisé les scripts que j'utilise ! Je t'avoue que c'est du charabia pour moi alors je te fais entièrement confiance . Bonne journée — Pharma ^💬 27 novembre 2022 à 13:00 (CET)

Gadget javascript

C’est évidemment tout à fait envisageable, il y a même d’autres infos intéressantes à ajouter comme la date de naissance pour les biographies (j’ai tendance à préférer faire ça en sparql pour ce genre de truc, mais dans bien des cas c’est kifkif)

Le souci c’est que les gadgets javascript c’est souvent confidentiel et que les catégories offrent assez de de flexibilité pour naviguer. Par exemple avec un affichage comme celui de mon modèle on peut facilement trier sur la colonne année de naissance si on la rajoute, on fait d’une pierre plusieurs coup, alors que naviguer dans une catégorie ça se fait page par page. C’est plus rapide à afficher, certes, après pas forcément plus rapide à utiliser dans tous les cas. — TomT0m ^[bla] 17 décembre 2022 à 09:57 (CET)

Pour info j’ai entamé un travail pour avoir des informations sur les catégories de métier sur Wikipédia et les genre (travail en cours) dont les résultats actuels sont consultables ici (en principe, me dire si le lien ne fonctionne pas).

J’ai essayé de trouver les catégories de métiers sur Wikipédia grâce à Wikidata. Il y en a un certain nombre, dont quelques une très peuplées et beaucoup de catégories pas peuplées. Je dis "peuplé" dans le sens soit la catégorie a plein de personne qui exercent ce métier sur Wikidata, potentiellement la catégorie elle même est vide mais ses sous-catégories le sont pas.

Je sais que la requête fonctionne dans tous les cas, de mémoire, pour le métier "avocat", il n’y a qu’une dizaine de catégorie de métier plus "peuplé" que avocat, donc c’est possible de faire une liste manuelle de cas particuliers sans problèmes. — TomT0m ^[bla] 17 décembre 2022 à 10:43 (CET)