Discussion Projet:Modèle

Le salon des modélistes

Questions générales. On discute du projet modèle.

Afin de vous assurer que vous faites votre demande au bon endroit, veuillez consulter l’encadré ci-dessous et déterminer si vous postez au bon endroit.

Le salon des modélistes concerne principalement les discussions à propos du projet, mais aussi les questions générales portant sur les modèles si les différentes rubriques d’aide n’y répondent pas. Toute demande qui aurait dû être faite dans l’une des pages mentionnées ci-dessous n’est pas faite au bon endroit, elle pourrait être ignorée.

Question aux modélistes

Annonces (section remplie automatiquement)

Modèles proposés à la suppression

• Aucun modèle actuellement

Nouveaux modèles

22 mai 2024

• 00:0622 mai 2024 à 00:06 ‎Modèle:Utilisateur L'attaque des titans (hist | modifier) ‎[479 octets] ‎RedGust67 (discuter | contributions) (Création du modèle utilisateur L'attaque des titans)

21 mai 2024

• 23:2921 mai 2024 à 23:29 ‎Modèle:Palette Honoré Daumier (hist | modifier) ‎[911 octets] ‎Mistico Dois (discuter | contributions) (Nouvelle palette)
• 23:1121 mai 2024 à 23:11 ‎Modèle:Palette Chronologie du softball (hist | modifier) ‎[1 607 octets] ‎Eskivor (discuter | contributions) (création modèle)
• 22:5521 mai 2024 à 22:55 ‎Modèle:Palette Chronologie du snowboard (hist | modifier) ‎[1 585 octets] ‎Eskivor (discuter | contributions) (création modèle)
• 22:4621 mai 2024 à 22:46 ‎Modèle:Palette Chronologie de l'escalade (hist | modifier) ‎[875 octets] ‎Eskivor (discuter | contributions) (création modèle)
• 22:3621 mai 2024 à 22:36 ‎Modèle:Palette Chronologie du skateboard (hist | modifier) ‎[895 octets] ‎Eskivor (discuter | contributions) (création modèle)
• 22:1221 mai 2024 à 22:12 ‎Modèle:Palette Chronologie du rugby à sept (hist | modifier) ‎[1 052 octets] ‎Eskivor (discuter | contributions) (création modèle) créé initialement avec le titre « Modèle:Palette Chronologie du rugby à VII »
• 21:4721 mai 2024 à 21:47 ‎Modèle:Palette Chronologie du trampoline (hist | modifier) ‎[1 550 octets] ‎Eskivor (discuter | contributions) (création modèle)
• 21:3421 mai 2024 à 21:34 ‎Modèle:Palette Chronologie du water-polo (hist | modifier) ‎[4 624 octets] ‎Eskivor (discuter | contributions) (création modèle)
• 19:1621 mai 2024 à 19:16 ‎Modèle:Palette Championnat d'Asie féminin de rugby à XV (hist | modifier) ‎[1 745 octets] ‎Rashinseita (discuter | contributions) (Nouvelle page : {{Méta palette de navigation | modèle = Palette Championnat d'Afrique féminin de rugby à XV | étatboîte = autocollapse | titre = {{Coloré|#{{charte sportive/Texte|rugby à XV}}|Championnat d'Afrique féminin de rugby à XV}} | styletitre = background:#{{charte sportive/Niveau 1|rugby à XV}}; color:#{{charte sportive/Texte|rugby à XV}}; | stylecorps = background:#{{charte sportive/Niveau 4|rugby...)

Le projet « Modèle » a 2 notifications (voir).

Archives

• 2006
• 2007
• 2008
• 2009
• 2010
• 2011
• 2012
• 2013
• 2014
• 2015
• 2016
• 2017
• 2018
• 2019
• 2020
• 2021 (01-06)
• 2021 (06-12)
• 2022
• 2023
• 2024

Lien_archive

Ne pas archiver.

Bonjour. Il y a là Discussion_modèle:Lien_archive#Mieux_coller_aux_paramètres_de_lien_web de vieilles demandes de modification du modèle {{Lien_archive}} qui sont légitimes. Est ce que l'unE d'entre vous pourrait se pencher sur cette question? Merci. --Lewisiscrazy (discuter) 9 octobre 2021 à 13:47 (CEST)

Orlodrim peut-être? Merci! --Lewisiscrazy (discuter) 16 octobre 2021 à 16:41 (CEST)

ou Epok ? à moins que la demande soit jugée sans intérêt? --Lewisiscrazy (discuter) 3 novembre 2021 à 10:09 (CET)

Multiplicité de modèles affichant une syntaxe de modèle

Pour citer du wikicode, dans le cas des paragraphes ou citations de plusieurs lignes, on peut utiliser les balises <pre> ou <syntaxhighlight lang="moin">.

Pour de courts extraits, outre <syntaxhighlight lang="moin" inline>, il est possible d'écrire le code entre balises <code> et <nowiki>, cette dernière afin que le code ne soit pas interprété. Il existe aussi de nombreuses possibilités via des modèles. Pas forcément plus simples et pas toujours bien utilisés (y compris par des bots,  Linedwell) comme le montrent les statistiques pour {{M}}.

Voici une comparaison de quelques modèles identifiés.

Comparaison des modèles

Modèle	Lien interne	Insécable	Balise	Accepte argument vide	Gère le = sans avoir besoin de recourir à {{=}}	Nombre max de param. positionnels	Notes (en gras les défauts, inconvénients, limitations) Statistiques approximatives d'utilisation.
{{m}}	oui	non	–	non	non	9	Stats : 89 961 pages distinctes.
{{m-}}	non	non	–	non	non	9	Une infobulle mais plutôt gadget Stats : 36 pages distinctes.
{{mdl}}	non	non	<kbd>	non	non	9	Attention ! Ce modèle introduit un caractère {{!}} qui peut interférer avec la syntaxe des tableaux et altérer l'affichage ; Il serait préférable qu'il utilise dans son code le caractère &#124; Stats : 13 141 pages distinctes.
{{mpl}}	oui	non	–	oui mais limité à un	non	1	Paramètre "2" obligatoire, celui permettant d'indiquer un paramètre. Pas d'autres paramètres : besoin de solliciter {{!}} ou &#124; pour en afficher plusieurs Stats : 2 pages distinctes dont un brouillon utilisateur.
{{Lien vers modèle avec paramètres}} / {{tlx}}	oui	non	–	non	non	10, puis affiche « … »	Stats : 3 868 pages distinctes.
{{tlc}}	non	oui	<code>	oui	non	8	Stats : 205 pages distinctes.
{{tld}}	non	oui par défaut (cf paramètre dédié)	<code>	oui	non	10, puis affiche « … »	Possède un paramètre subst de substitution et un paramètre allowlinebreak pour autoriser le passage à la ligne. Repose sur un méta-modèle {{tlg}} qu'uniquement lui sollicite. Stats : 9 pages distinctes ; un seul appel du paramètre allowlinebreak.
{{mpn}}	oui	non	–	non	oui sans limite, mais les affiche à la fin, après les paramètres non nommés et dans un ordre douteux. Incompatible avec la substitution.	9	Possède un paramètre namespace présentant peu d’intérêt, sauf pour cibler un "modèle" hébergé dans un espace autre que « Modèle: » L'ordonnancement des paramètres nommés est assez étrange et ne respecte pas l'ordre préconisé. Exemple : {{mpn|nom modèle|p1=|p2=|p3=|p4=|p5=}} affiche chez moi « {{nom modèle|p5=|p4=|p2=|p3=|p1=}} ». Si le modèle est substitué, les paramètres nommés ne s'affichent plus. En outre, l'autorisation d'une infinité de paramètres nommés pose un problème de renseignement du TemplateData. Stats : une seule page concernée. Paramètre namespace inutilisé.

Exemples

Modèle	Rendu (figé au 24 mai 2022) {{Modèle|nom modèle|nommé1=valeurnom1|num1|num2||num4|nommé2=|num5|num6|num7|num8|num9|num10|num11|num12}}
m	{{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9}}
m-	{{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9}}
mdl	{{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9}}
mpl	{{nom modèle|num1}}
lmp / tlx	{{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9|num10|...}}
tlc	{{nom modèle|num1|num2||num4|num5|num6|num7|num8}}
tld	{{nom modèle|num1|num2||num4|num5|num6|num7|num8|num9|num10|…}}
mpn	{{nom modèle|num1|num2|num4|num5|num6|num7|num8|num9|nommé1=valeurnom1|nommé2=}}

Remarque générale : actuellement, aucun de ces modèles n'est écrit pour accepter une substitution propre (sauf le plus simple « mpl »).

Observations

• Le rendu de Modèle:Mpl est identique à celui de Modèle:Lien vers modèle avec paramètres. On peut éventuellement calquer le second sur Modèle:Tlc pour qu'il accepte les paramètres à la valeur vide (ou espace).
• Modèle:Tlc et Modèle:Tld sont sensiblement similaires ; la différence est la présence d'options dans le second.
• Modèle:Tld sait déjà faire tout ce que fait Modèle:Mdl, sans le défaut de codage. La différence de balises (kbd ou code) semble anecdotique.

Des fusions sont possibles afin de simplifier les choses pour le néo-contributeur. Des avis ? Notification à quelques créateurs des modèles  Pixeltoo, GLec, TomT0m et GrandEscogriffe. Merci par avance. — Ideawipik (discuter) 25 mai 2022 à 01:47 (CEST)

Bonjour Ideawipik, merci de m'avoir cité pour m'informer d'un usage incorrect du modèle {{m}} par LinedBot. Au vu de la page de statistiques (et des logs du bot) les appels avec des paramètres inexistants par le bot sont du fait que les utilisateurs ayant apposés les bandeaux d'origine sur les pages (que ça soit {{En travaux}}, {{En cours}} ou leurs nombreuses déclinaisons) l'ont fait avec ces mêmes paramètres (en effet, lors de la suppression du modèle, le bot récupère la liste de tous les paramètres pour la spécifier dans son Log). Conscient que cela semble désormais poser un problème, quelle serait la préconisation que tu proposerais ? Est-ce que remplacer l'utilisation du modèle {{m}} par {{m-}} (aussi bien dans les futures action du bot, que rétroactivement en corrigeant ses logs passés) serait une solution qui te conviendrait ? Cordialement, Linedwell ^[discuter] 25 mai 2022 à 08:43 (CEST)

Bonjour,

J'ai créé {{m-}} en septembre dernier pour aligner {{m}} sur l'usage, existant sur d'autres modèles, que l'ajout du tiret au nom du modèle retire le lien interne en gardant le même rendu. C'est le cas de {{date-}} et de {{s-}}. Plus généralement, sur des modèles comme {{a-}}, {{u-}}, ou {{notif-}}, la version avec tiret donne un rendu plus sobre que la version sans tiret (mais en gardant quand même un lien interne).

De plus {{m-}} est le seul des modèles listés plus haut a avoir un rendu sobre, sans lien interne ni code. Par contre il ne prend pas plus en compte que les autres les paramètres nommés, donc le mettre à la place de {{m}} ne changera rien sur ce point.

Favorable à faire des redirections parmi les autres modèles pour garder les plus performants. De la synthèse d'Ideawipik, je retiens qu'il y a quatre rendus possibles : texte simple ( {{m-}} ), mise en balise de code ( {{mdl}}, {{tlc}} et {{tld}} ), lien interne seulement sur le nom du modèle ({{mpl}} et {{lmp}}), ou lien interne couvrant tout le texte ( {{m}} et {{mpn}} ). On peut garder un seul modèle pour chaque rendu. l'Escogriffe (✉) 25 mai 2022 à 16:15 (CEST)

C’est quoi les cas d’utilisation d’une substitution ? — TomT0m ^[bla] 25 mai 2022 à 16:45 (CEST)

En ce qui concerne {{mpn}} : il suit une approche qui permet d’afficher les paramètres nommés grâce à un module en lua. Il n’y a pas moyen de récupérer l’ordre des paramètres nommés par ce biais, et les paramètres positionnels seront sans doute forcément dans l’ordre. Il y a moyen d’améliorer la gestion des paramètres numérotés vides par contre, et de faire sauter la limite du nombre de paramètres. Je vais m’y atteler si ça offre des trucs que les autres ne peuvent pas trop faire. — TomT0m ^[bla] 25 mai 2022 à 16:42 (CEST)

Bonjour Linedwell. Cas particulier pour ton bot. Remplacer m par m- ne résoudrait rien car le second ne gère pas davantage les paramètres nommés que le premier. Si on considère que le lien interne vers la page du modèle n'est pas indispensable, le plus simple serait d'utiliser directement la syntaxe <code><nowiki>{{…}}</nowiki></code> reproduisant tout le code du modèle. Sinon, on verra quel est le modèle le mieux adapté en fonction de la suite de la présente discussion. Peut-être {{tlx|Nom du modèle|<nowiki>liste des paramètres sans la barre verticale initiale</nowiki>}} ? Une autre possibilité est de conserver le lien et de limiter l'affichage au nom du modèle : {{m|Nom du modèle retiré/ajouté}} et éventuellement de l'accompagner d'un second lien vers la modification ([[Special:Diff/oldid|modif/retrait/ajout]]) (libellé à choisir).

Cas général pour l'affichage de paramètres nommés (donc avec présence d'un signe égal)

• Soit on conserve le fonctionnement actuel qui impose à l'utilisateur de remplacer les « = » par {{=}} ou par = ou de les entourer de balises <nowiki> ou de recourir au numéros explicites |n=param=valeur pour le nième paramètre du modèle appelé, i.e. le (n-1)ième "paramètre" du modèle cité (décalage lié au fait que le premier est le nom du modèle cité).
• Soit on trouve une solution (à priori en Lua) permettant de reproduire tous les paramètres dans leur ordre d'entrée et en gérant les arguments vides qui ont un sens dans certains modèles à paramètres positionnels.
  • Dans ce cas, aucun paramètre optionnel de configuration ne serait disponible dans le nouveau modèle (ou alors avec un nom réservé à ce seul modèle et sans possibilité de se citer lui-même).
  • Je ne sais pas s'il est possible de faire comprendre à un modèle (TemplateData) que tous les noms de paramètres sont valides.  Tractopelle-jaune ?
  • Il n'est pas évident d'analyser le contenu des "paramètres" pour savoir comment interpréter les signes égal. Nombreux cas : déjà en nowiki, pour un attribut dans une balise à l'intérieur, dans un modèle imbriqué, dans un nom de modèle (typiquement {{=}}), en paramètre numéroté explicite (exemple : 2=blabla) mais cela se réfère-t-il au modèle de citation ou au modèle cité ?, etc.

L'avantage du fonctionnement actuel du modèle {{Lien vers modèle avec paramètres}} est de pouvoir mettre des liens vers plusieurs modèles lors d'appels imbriqués. Exemple : {{m|{{=}}}} affiché grâce au code {{tlx|m|{{tlx|1==}}}}.

Salut TomT0m. Pas vraiment d'intérêt de substituer ce modèle, c'était juste une observation. Pour les signes égal, s'il n'y a pas moyen de récupérer l'ordre des paramètres, je ne suis pas convaincu de la pertinence d'un affichage différent de celui souhaité par le rédacteur. — Ideawipik (discuter) 25 mai 2022 à 17:04 (CEST)

@Ideawipik parfois on s’en fiche un peu de l’ordre, il n’est pas significatif. L’avantage principal c’est qu’on peut facilement transformer un vrai appel pour faire une citation.

Par exemple dans une autre discussion sur un bug je viens de taper rapidement {{Wikidata|entity={{Qid|Antonie Ruset}}|P1559}}. Comment montrer l’appel sans trop de soucis à rajouter des balises ? juste rajouter « mpn| » devant suffit {{Wikidata|P1559|entity=Q541714}} à montrer l’idée. — TomT0m ^[bla] 2 juin 2022 à 19:56 (CEST)

Salut GrandEscogriffe, le modèle m-, avec son infobulle, n'est pas le plus sobre. À ce détail près, on obtient la même chose avec {{Tlg|nolink=oui|…}} qui intègre les arguments vides. Utilisable pour mutualiser, reste à voir les performances. — Ideawipik (discuter) 25 mai 2022 à 17:30 (CEST)

J'ai mis le bot à jour pour l'utilisation des balises code + nowiki pour les prochains runs. Si l'affichage n'est pas bugué, je ferai les remplacements dans les logs (et leurs archives) dans la journée de demain. Cordialement, Linedwell ^[discuter] 25 mai 2022 à 18:20 (CEST)

Si c'est utile, OK recoder m- avec {{tlg|nolink=oui}}. Pour moi l'important est qu'on puisse continuer à utiliser {{m-|...}} qui est de loin la syntaxe la plus intuitive une fois qu'on connaît {{m}} et les modèles à tiret. --l'Escogriffe (✉) 25 mai 2022 à 20:37 (CEST)

taille du logo pour modèle:Infobox Jeu de données

Bonjour.

Je m'aperçois que le logo dans l'{{Infobox Jeu de données}} de Base Léonore est un peu petit. À mon avis, il devrait être de 280px de large pour remplir la largeur de l'infobox.

Ça doit être géré au niveau du Module:Infobox (ou peut être Module:Infobox/Jeu de données), mais je ne sais pas quoi modifier.

Merci de regarder ça de plus près, cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 juin 2022 à 11:34 (CEST)

Bonjour SyntaxTerror. Suite à modification sur le module Infobox/Jeu de données, c'est désormais réglé par le paramètre upright logo (mettre un coefficient de l'ordre 1, pas une taille en pixels). Le paramètre existait déjà mais non documenté et appelé de façon trompeuse « upright blason ». l'Escogriffe (✉) 10 juin 2022 à 14:26 (CEST)

Merci GrandEscogriffe. Il semble que upright logo = 1.5 soit le maximum, des valeurs plus grandes n'agrandissent pas l'image ou l'infobox (ce qui est souhaitable).

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 juin 2022 à 19:10 (CEST)

Appel du modèle Géolocalisation par le modèle Méta palette Équipe nationale

Bonjour, Les modèles {{Méta palette Équipe nationale}} et {{Méta palette Équipe nationale sans numéro}} appellent un modèle {{Géolocalisation/Pays qui va bien}} => Pourquoi ?

Vu avec le modèle {{Palette Équipe de Grande-Bretagne féminine de hockey sur gazon aux Jeux olympiques 2016}} qui appelle le modèle {{Géolocalisation/Grande-Bretagne}} qui n'existe pas mais cela n'a pas l'air d'être utile à la palette. Cordialement - Drongou (discuter) 30 juin 2022 à 23:22 (CEST)

 Drongou : Bonsoir, c'est le modèle:Du? qui s'en sert pour construire le titre de la palette.

Quand le modèle de géolocalisation n'existe pas il met par défaut « de la zone » (comme on peut le voir dans l'exemple que tu donnes).

--FDo64 (discuter) 30 juin 2022 à 23:35 (CEST)

 FDo64 : Un grand merci, je n'aurai jamais trouvé => je cherchais une carte ... Cordialement - Drongou (discuter) 30 juin 2022 à 23:49 (CEST)

Hello FDo64,

Merci pour cette réponse, j'avais aussi de mon côté cherché sans succès, en raison de la forte présence de {{Géolocalisation/Grande-Bretagne}} dans les modèles demandés. Dans ce cas, ne faudrait-il pas protéger le modèle {{Du?}} contre un appel de modèle inexistant, en vérifiant que le modèle existe avant de l’appeler ?

Wikipédiennement, Epok__ (✉), le 1 juillet 2022 à 10:35 (CEST)

Bonjour, j'ai créé le modèle de géoloc (la géoloc n'est ici qu'un prétexte) pour donner l'affichage souhaité.

Je ne suis pas contre vérifier que le modèle existe avant de l'appeler mais dans ce cas il faudrait mettre un place un autre mécanisme de détection des échecs de {{Du?}}. Ici on voit que ça a permis de résoudre un problème. l'Escogriffe (✉) 1 juillet 2022 à 19:22 (CEST)

GrandEscogriffe : entourer le code actuel tel quel d'un simple #ifexist, en renseignant "de la zone" dans le cas négatif résoudrait le problème. Mais cette parser function étant couteuse, ce n'est peut-être pas une solution acceptable... Epok__ (✉), le 2 juillet 2022 à 11:13 (CEST)

Ajout : je viens de tomber là dessus depuis la doc de la parser function : à priori, cela n'allègerait pas la page spéciale car les pages testées par ifexist se retrouvent tout de même dans une autre liste... J'annule donc ma remarque. Epok__ (✉), le 2 juillet 2022 à 11:15 (CEST)

Modèles de langues

Le modèle:en russe fonctionne bien. Mais les modèles modèle:en biélorusse et modèle:en ukrainien ne fonctionnent pas correctement. Le paramètre "translittération" ne fonctionne pas et le texte apparaît en italique, ce qui est inutile et indésirable pour le texte cyrillique. Les transcriptions latines sont présentes, mais ne sont pas visibles. Donc

• en biélorusse : Беларусь
• (en ukrainien : Україна)
• en russe : Россия, Rossiïa

Quelqu'un peut-il aider? GPinkerton (discuter) 5 juillet 2022 à 15:15 (CEST)

 GPinkerton : le truc c'est que le modèle:en russe utilise un modèle spécial ({{lang-ru}}) pour indiquer la langue, tandis que les deux autres utilisent le Modèle:En langue, prévu à la base pour les langues écrites avec l'alphabet latin (le seul qui devrait être mis en italique).

Je ne comprends pas vraiment pourquoi ces modèles simples utilisent des sous-modèles et des sous-sous-modèles, et ce qui me gêne un peu c'est que certains de ces modèles de ces « modèles de langue avec nom » ont des parenthèses et d'autres pas, et certains on « en » avant le nom de la langue, d'autres pas.

Il faudrait vérifier tous les modèles de la catégorie, enlever toutes les parenthèses pour permettre leur utilisation dans un plus grand nombre de situations et passer avec un bot pour ajouter toutes les parenthèses qui auront disparu...

En bref un sacré boulot en perspective (mais ça fait un moment que j'ai envie de me lancer dedans).

Il y a un autre problème : pour les deux modèles problématiques, il n'y a qu'un seul argument, où l'on doit mettre le texte en cyrillique ET sa transcription éventuelle, alors que le modèle « en russe » à deux arguments, pour le cyrillique et le romain (ce qui est la bonne chose à faire).

• {{en russe|Николай|Nikolaï}} → en russe : Николай, Nikolaï
• {{en biélorusse|Гвардыя, Hvardyya}} → en biélorusse : Гвардыя, Hvardyya

Enlever l'italique pour le cyrillique veut dire l'enlever aussi pour la transcription, donc on se retrouve avec un autre problème...

Je préfère ne rien toucher en attendant d'autres avis. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 5 juillet 2022 à 16:11 (CEST)

À y réfléchir, il y a un autre problème : certaines langues peuvent s'écrire en romain ET avec un ou plusieurs autre systèmes d'écriture (comme certaines langues yougoslaves, selon la date du texte, par ex. le serbe qui est redevenu en cyrillique après la dissolution de la Yougoslavie il me semble). C'est donc un problème bien plus vaste que ces deux modèles fautifs.

Idéalement, il ne faudrait pas ajouter la mise en italique dans ce genre de modèle, et le faire en dur dans les articles, comme pour le modèle {{langue}}, mais ça veut dire retoucher des dizaines (centaines ?) de milliers de pages si on enlève l'italique des modèles.

Le mieux serait peut-être de créer un module, et d'utiliser le modèle {{en langue}} (synonyme {{en lang}}) pour toutes les indications de langue dans les articles, au lieu de l'utiliser comme méta-modèle.

On pourrait se servir de Module:Langue/Data comme base de données, et ensuite {{en langue|ru|...}} marcherait, de même que {{en langue|russe|...}}, ou n'importe quel synonyme de nom de langue indiqué dans Module:Langue/Data.

Comme les modèles {{en trucmuche}} utilisent en majorité {{Langue avec nom}} comme méta-modèle, on pourrait les modifier un à un sans chambouler les articles trop longtemps. [EDIT] ça marche pas, j'ai le cerveau en bouillie...

L'avantage serait qu'il n'y aurait plus jamais besoin de créer de nouveaux « modèles de langue avec nom », il suffirait d'ajouter la langue à Module:Langue/Data pour avoir un modèle fonctionnel.

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

 Zebulon84 qui a créé le module:langue. Şÿℵדαχ₮ɘɼɾ๏ʁ 5 juillet 2022 à 16:57 (CEST)

Modèles dynastiques

Bonjour,

Les noms dynastiques (ceux avec un numéro en chiffres romains) sont supportés par une série de modèles comme Monarque, Souverain, Souverain-, Souverain2, Souverain3 qui donnent une migraine à essayer de comprendre leur utilisation, quand utiliser l'un ou l'autre, et quelles sont les différences et les incompatibilités, et comment modifier un appel pour ajouter ou supprimer le lien.

Question : y aurait-il un intérêt à créer un seul modèle qui en fasse une synthèse ? Vous trouverez une proposition de ce genre, sans préjuger de rien, sur Utilisateur:Alserv/Documentation. J'en ai parlé un peu avec Golmote qui y semble favorable.

Deuxième question : je ne connais pas bien les usages, est-ce « Crée le d'abord, qu'on voie à quoi ça ressemble », ou bien est-ce « Pas de passage en force, touche à rien tant qu'on n'a pas donné notre avis » ? Alserv (discuter) 6 juillet 2022 à 12:53 (CEST)

Bonjour Alserv j'ai juste survolé, mais ça me semble bien.

Le vrai problème ça va être le boulot pour tout mettre en phase avec le nouveau modèle, surtout que les paramètres sont différents, et qu'il y en a en plus que dans ton modèle « noble » (entre crochets, le nombre de transclusions) :

• [2871] {{monarque|prénom|nombre romain|(optionnel : nom du pays)|pays=}}
• [145] {{Souverain|prénom de règne|ordre|article wikipédia|complément du nom}}
• [9929] {{Souverain-|prénom de règne|ordre|complément de nom}}
• [15892] {{Souverain2|prénom de règne|ordre|complément de lien|complément du nom}}
• [6979] {{Souverain3|prénom de règne|ordre|complément de lien}}

En plus, selon la doc de certains modèles « pour des raisons historiques (compatibilité des anciennes versions), il est toujours possible d'écrire les paramètres en les séparant par des « | », sans changement de rendu »

Ça fait que c'est un sacré boxon, surtout qu'avec un total de 35 816 pages à éditer, ça prendra au mieux une dizaines d'heures si on compte 2 secondes par édition, mais c'est sans compter les autres manips et les problèmes éventuels.

Sinon, quant au truc de passer en force, tu ne peux pas, car les paramètres sont différents, il te faut l'aide d'un bot pour faire le boulot, et il va falloir discuter avant, parce que ce genre de modification de grande ampleur ça amène toujours des pénibles (c'est pour ça que mon bot à 180 000 édits au compteur, une bonne moitié ont été défaites puis refaites, parfois deux fois...).

En 10 ans ici, je suis devenu un peu pessimiste, mais c'est bien d'avoir des nouvelles idées . Attendons de voir ce qu'en disent les autres, avec lua on fait parfois des miracles.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 6 juillet 2022 à 13:34 (CEST)

Merci. L'idée n'était pas de supporter tous les paramètres des anciens modèles mais bien d'avoir un modèle aussi simplifié et facile à utiliser que possible pour les nouvelles utilisations, donc sans s'imposer de contrainte de compatibilité. Ce qui signifie qu'un bot ne pourrait pas modifier toutes les pages existantes, sauf dans certains cas bien particuliers très limités ; les anciens modèles peuvent rester, ils ne gênent pas. Donc pas de bots. Et cela permet d'avoir un code Lua plus compact et plus performant: le code Lua pour implémenter le modèle proposé fait tout juste 256 lignes, commentaires compris.

Quand je parlais de passer en force, je me suis mal exprimé. Je voulais dire, créer le modèle puis discuter après - au risque de polluer l'espace des modèles avec des essais ratés. Alserv (discuter) 6 juillet 2022 à 14:09 (CEST)

Bonjour Alserv. Je pense que tu peux créer module et modèle sans problème. Pour les modèles, il est possible de créer un brouillon dans une sous page utilisateur (« Utilisateur:Alserv/… ») qui se sollicite ainsi : « {{Utilisateur:Alserv/…|paramètres}} ». Cela permet d'éviter la proposition d'insertion du modèle par l'outil de l'éditeur visuel. Pour les modules, aucune idée. Au pire, si la proposition était abandonnée, la page pourrait être supprimée. Dans un premier temps, il convient d'indiquer clairement que les modules/modèles sont en phase de développement et donc pas à utiliser dans les articles pour le moment.

La simplification de l'utilisation des modèles va dans le bon sens à mon avis. Il faudra établir comment convertir les syntaxes des anciens modèles, en fonction des cas (titre d'article avec parenthèse, titre d'article avec du texte après le numéral, etc.). Le modèle {{Souverain}} étant relativement peu employé (moins de 140 articles), il serait possible, à moyen terme, de réutiliser ce nom (préférable à « noble ») pour le futur modèle Lua, en faisant rapidement passer un robot dans les articles concernés puis en surveillant ces derniers quelque temps (en cas de retour à une version antérieure). Pour {{Souverain-}} (7600 pages distinctes), c'est un peu plus délicat. Voir si on peut temporairement avoir un modèle qui accepte les deux syntaxes (en fonction des valeurs des arguments). Ensuite, les modèles pourrait être déployés petit à petit, au fil de l'eau en remplacement des autres modèles listés. Il n'y aurait pas d'urgence à convertir les modèles Monarque, Souverain2 et Souverain3.

N.B. – Les nombres donnés par SyntaxTerror correspondent aux nombres de pages qui incluent une transclusion du modèle mais le nombre de pages dont le code source contient le modèle peut être inférieur (exemple du modèle présent dans une palette portée par de nombreuses pages). — Ideawipik (discuter) 6 juillet 2022 à 17:36 (CEST)

Merci. Je ne suis pas très chaud pour réutiliser le nom d'un module existant. Pour coller à la bonne pratique de beaucoup de modèles où le modèle X génère un lien et le modèle X- (avec un tiret) fait exactement la même chose sans générer de lien, il faudrait redéfinir {{Souverain}} et {{Souverain-}} en même temps, et là on tombe sur un bec de gaz : d'abord il y a beaucoup d'articles qui utilisent {{Souverain-}}, et je vois vraiment pas un bot capable de reconnaître et de convertir « {{Souverain-|Louis II}} d'Italie ». Ensuite, je sais par amère expérience (en-dehors de Wikipédia) que cela apporte des tonnes de bugs de compatibilité et coûte très cher en maintenance, sans compter que cela surcharge souvent très fort le nouveau code.

Merci aussi pour le conseil pour les brouillons. J'utilise ma page de brouillon comme vous m'avez suggéré pour faire des tests, avec deux pages de brouillon supplémentaires pour contenir les deux modèles. Pour les modules, on ne peut pas en faire dans son espace perso, il faut utiliser Module:Bac à sable qui est commun à tout le monde. Heureusement on peut l'éditer, copier du code, le tester puis annuler sans jamais le publier et donc sans gêner les autres utilisateurs. Alserv (discuter) 6 juillet 2022 à 18:28 (CEST)

Je ne suis pas non plus très chaud pour la réutilisation d'un nom de modèle en général, sauf s'il est désuet depuis très longtemps. Mais il faut quand même que le modèle soit bien nommé (titre précis, sans surprise). Donc dans certains cas, pourquoi pas ? Avec une grosse dose de pédagogie pour les rédacteurs habitués aux deux modèles, une bonne préparation de la transition et une adaptation des documentations associées à ces modèles (y compris en pages de discussion, aides aux contributeurs, pas seulement la sous-page de documentation du modèle). Comme l'indiquait Tractopelle-jaune au cours d'une autre discussion sur la présente page en mai 2022, le besoin de rétro-compatibilité est relatif.

En l’occurrence pour {{Souverain-|Louis II}}, il n'y aurait rien à changer dans l'article puisque ce modèle ne doit pas introduire de lien interne. Le seul intérêt du modèle est l'insécabilité entre le nom et le numéro, soit un rendu équivalent à {{nobr|Louis {{II}}}}. On n'est pas obligé de faire entrer le complément « d'Italie » dans le modèle.

Remarque connexe sur l'avantage de la syntaxe proposée pour le nouveau modèle par rapport aux syntaxes initiales rappelées ci-dessus par SyntaxTerror. En cas de renommage d'un article de souverain, afin de transformer ce dernier article consacré à un homonyme éclipsant l'initial ou de le transformer en page d'homonymie, serait rendu plus facile le repérage des pages ayant besoin d'un changement. En effet, le titre complet de l'article serait entier dans un seul paramètre et pas dispatché sur plusieurs paramètres (prénom de règne, ordre, complément de lien). D'ailleurs, la possibilité de mise en forme (italique) dans le paramètre du modèle Souverain3 ne doit pas faciliter la maintenance par bot, dans de telles situations.

Une question à se poser par exemple pour {{Modèle|Louis II d'Italie}}, quel serait le libellé du lien par défaut : « Louis II » comme avec Souverain2 ou « Louis II d'Italie » comme avec Souverain3. Le premier semble plus simple (se distinguant de {{Modèle|Louis II d'Italie|d'Italie}}) mais n'est pas forcément le plus logique pour l'utilisateur final. Il pourrait être intéressant d'autoriser une syntaxe particulière {{Modèle|nom de l'article|libellé=libellé complet}} le modèle mettrait en forme (insécabilité devant les numéros, infobulle) tout le libellé (exemple : |Philippe V le Long|libellé=Philippe V dit « le Long » ou Philippe II de Navarre}}). D'un autre coté, pour ces cas particuliers, on peut aussi préconiser la syntaxe classique entre doubles crochets et l'usage du {{nobr}}. — Ideawipik (discuter) 6 juillet 2022 à 20:36 (CEST)

+1 pour le renommage d'un article, je n'y avais pas pensé.

Pour la conception du modèle, j'ai essayé de faciliter autant que possible la conversion d'un nom d'article en un appel de modèle, ce qui se rapproche le plus de Souverain3, en supprimant le texte entre parenthèses dans l'affichage, mais sans les modifications du nom d'article faites par Souverain3, comme vous le faites si bien remarquer : le premier argument est strictement le nom de l'article. Puis seulement après j'ai repris les idées de Souverain2 pour le deuxième argument. Donc pour {{Modèle|Louis II d'Italie}} la mise en forme serait « Louis II d'Italie », ce qui me semblait en effet le plus logique, je suis d'accord avec vous. On peut ajouter un second argument avec un seul tiret {{Modèle|Louis II d'Italie|-}} pour obtenir « Louis II », le second argument indiquant toujours que le texte affiché s'écarte du nom de l'article.

Quant à une syntaxe particulière, pas besoin : si le deuxième argument contient un numéro en chiffres romains, seul le deuxième argument est utilisé pour l'affichage, le premier argument ne servant qu'à générer le lien. Donc on peut écrire |Philippe V le Long|Philippe V dit « le Long » ou Philippe II de Navarre}} sans syntaxe particulière. Par contre, j'adore votre exemple, je n'avais pas pensé qu'il pouvait y avoir PLUSIEURS nombres en chiffres romains dans le deuxième argument. Je vais essayer de réviser le code pour les traiter tous. En plus je crois bien que cela simplifierait le code, merci pour la remarque. Et si le libellé ne contient pas de chiffres romains, à quoi bon s'embarrasser d'un modèle ?

Un grand merci pour cette discussion très fructueuse et pour toutes vos idées. Alserv (discuter) 6 juillet 2022 à 21:20 (CEST)

 Ideawipik et Alserv : pour tester les modules, j'avais créé Module:Utilisateur:SyntaxTerror, Module:Utilisateur:SyntaxTerror/2, etc. ça n'a jamais gêné personne et ça fait des années qu'ils sont là. Şÿℵדαχ₮ɘɼɾ๏ʁ 6 juillet 2022 à 21:59 (CEST)

@Alserv. Astucieux le paramètre 2 à la valeur « - ». On pourrait même accepter une valeur « + » pour afficher aussi l'éventuelle parenthèse d'homonymie.

Si j'ai compris ta proposition, |Louis XV|le Bien-Aimé}} est censé afficher en libellé « Louis XV le Bien-Aimé », |Louis II de Germanie|de Bavière}} « Louis II de Bavière » et |Charles II (roi d'Espagne)|l'Ensorcelé}} « Charles II l'Ensorcelé ». Mais un utilisateur pourrait s'attendre à voir cette syntaxe donner simplement « l'Ensorcelé » (dans ce cas précis, il vaut mieux qu'il utilise [[Charles II (roi d'Espagne)|l'Ensorcelé]], mais on trouvera inévitablement de telles utilisations superflues du modèle au fil du temps, par mimétisme). C'était le sens de la question relative au paramètre sur le libellé complet. Sur quelle base le modèle changera-t-il son comportement entre ajout/remplacement d'un complément et affichage du second paramètre uniquement ?

Autres cas envisageables :

• numéro uniquement dans le libellé |Mélèce Métaxakis|Mélèce IV}} ou |Jeanne d'Albret|Jeanne III de Navarre}} (avec éventuellement une parenthèse d'homonymie). Cela correspond aux cas « Avec un autre numéro » du brouillon ;
• avec un prénom différent. Concrètement, je n'ai pas d'exemple d'article mais on pourrait avoir un |George VII (roi d'Angleterre)|Charles III}} ou |Karol Wojtyla|Jean-Paul II}}. En pratique, par l'intermédiaire de redirections on devrait pouvoir s'éviter ce genre de gymnastique, mais sait-on jamais… Ai trouvé un exemple simple : |Charlemagne|Charles Ier}}. — Ideawipik (discuter) 6 juillet 2022 à 22:46 (CEST)

Malin le « + », j'adopte. Si le nom de l'article se présente comme « nom numéro complément (homonymie) », le comportement standard avec un seul argument affichera « nom numéro complément ». Un « - » comme second argument retranchera le complément pour afficher « nom numéro » alors qu'un « + » comme second argument ajoutera l'homonymie pour afficher « nom numéro complément (homonymie) ». On fait des maths, plus ou moins.

Les exemples sont exactement comme tu l'indiques. Le comportement change selon qu'on détecte ou non des chiffres romains dans le second argument. Si pas de chiffres romains, ajout du second argument au nom et numéro tirés du premier argument. Si chiffres romains, affichage du second argument uniquement.

Pour les autres cas envisagés, il affichera donc toujours uniquement le second argument puisqu'il contient des chiffres romains. Et il ne se plaindra pas s'il n'y en a pas dans le premier. Alserv (discuter) 7 juillet 2022 à 08:20 (CEST)

Merci à tous pour cette discussion fructueuse et vos interventions de qualité. Je vais essayer de résumer :

• L'accent est mis sur une utilisation aussi simple et intuitive que possible. Une compatibilité avec les anciens modèles n'est pas garantie, et il n'y a pas de demande à un bot de convertir les appels aux anciens modèles en appels au nouveau ;
• Le premier argument est strictement le nom de l'article (s'il existe) pour faciliter le travail des bots ;
• Un « + » comme second argument affiche aussi l'homonymie ;
• Il peut y avoir plusieurs nombres en chiffres romains, qui doivent être mis en forme individuellement.

-- Alserv (discuter) 8 juillet 2022 à 11:24 (CEST)

Recherche pour les nouveaux

Un modèle, lorsqu'on l'utilise, doit être précédé de "{{" et suivi de "}}".

Quelqu'un de nouveau sur Wikipédia ne sait pas cela.

Ne pourrait-on pas faire que ce soit possible de faire une recherche avec ces accolades.

Exemple : quelqu'un fait une recherche sur "{{article}}" il ne trouvera rien, ce n'est qu'en cherchant, qu'il arrivera à trouver qu'il faut taper modèle à la place des accolades et donc taper "modèle:article". Io Herodotus (discuter) 8 juillet 2022 à 08:11 (CEST)

Bonjour . En effet, ce n'est pas intuitif sans avoir lu un minimum d'aides…

Je pense que la bonne réponse à ta demande est de poster une demande sur Phabricator.

Là tu risque d'avoir la réponse que l'outil de recherche te permet déjà de trouver le bon résultat à condition de sélectionner l'espace de nom "modèle", après avoir fait plusieurs clics… Encore faut-il le savoir.

J'ai bien peur qu'à notre niveau nous ne puissions rien faire.

--FDo64 (discuter) 8 juillet 2022 à 09:03 (CEST)

Il est possible de rechercher un modèle spécifique, par exemple hastemplate:"tonmodèle" dans la barre de recherche. Bouzinac (discuter) 8 juillet 2022 à 12:43 (CEST)

Bonjour Io Herodotus. Il y a deux cas : la recherche d'un modèle et la recherche des pages portant un modèle donné.

Pour la recherche d'un modèle.

• Si le nom exact du modèle est connu : une recherche Modèle:lemodèle (l'auto-complétion facilite la recherche).
• Si le titre exact du modèle n'est pas connu, une recherche de mot dans la page :
  • soit Modèle: "expression cherchée".
  • soit "expression cherchée" en restreignant la recherche à l'espace des modèles (case à cocher).
• Variantes en connaissant une partie du titre avec intitle:/expression cherchée/i ou une partie du code source de la page avec insource:/expression cherchée/i ; le i final est facultatif selon que la casse soit exacte ou que la recherche doive être souple.

Pour la recherche d'articles utilisant un modèle donné, il existe plusieurs méthodes :

• La méthode proposée plus haut dans l'outil de recherche hastemplate:"lemodèle" que l'on peut combiner à d'autres critères de recherche ;
• Alternative qui sera peut-être moins complète (pour des mises en forme particulières) mais permet de rechercher des motifs parmi les paramètres insource:/\{\{\s*[Ll]emodèle\s*\|/ ;
• Spécial:Pages liées en affichant uniquement les inclusions (pas les liens et les redirections) ;
• wstat.fr qui permet aussi des recherches de motifs (expressions régulières) pour le modèle complet et pour chaque paramètre. Site externe développé par le contributeur Orlodrim avec une mise à jour bimensuelle à partir de dépots.

Comme FDo64, je pense que l'important est la documentation et l'aide pour les nouveaux. Un néo-contributeur est en général assez rapidement amené à côtoyer des modèles. Une suggestion : créer la page « Aide:{{ » en tant que redirection vers Aide:Modèle. La seule suggestion que je vois pour Phabricator serait l'ajout d'un raccourci « {{ » à la place du mot « Modèle » dans l'outil de recherche. — Ideawipik (discuter) 8 juillet 2022 à 16:04 (CEST)

Je me mettais à la place d'un nouveau, ne sachant pas ce qu'est un modèle.

Créer la page « Aide:{{ » pourrait probablement aider.

Mon idée était que si un nouveau, voyait «{{article}}» sur une page, ne sachant pas ce que c'est, faisait une recherche sur «{{article}}» ; celle-ci aboutisse directement à « modèle:article ». Io Herodotus (discuter) 8 juillet 2022 à 16:35 (CEST)

Bonjour Io Herodotus. C'est au niveau du logiciel MediaWiki qu'il faut demander ça, on ne peut rien faire depuis Wikipédia.

« On finit par s'y habituer, et en fait, je vois même plus le wikicode : tout ce que je vois, ce sont des bandeaux, des palettes, des modèles biblio... »

Sinon, sans même demander, il ne me semble pas que ça soit faisable, car certains caractères ne sont tout simplement pas reconnus par la barre de recherche (dont { et [ par exemple).

Certains signes de ponctuations sont des redirections, par exemple ( vers Parenthèse, mais pas [[{]], qu'il n'est d'ailleurs pas possible de créer (et que le logiciel de rendu ne peut même pas afficher comme un lien, même rouge), ni [[Aide:{{]] d'ailleurs.

On ne peut malheureusement pas tout simplifier, il faut un minimum de connaissances pour contribuer de manière un peu avancée... D'ailleurs maintenant avec l'éditer visuel ce genre de problème avec le wikicode ne devrait plus arriver (y'a plus que les vieux coûtons de Wikipédia comme moi qui ont l'audace d'encore éditer en mode source ).

Sinon, le moyen le plus facile de trouver un lien vers la page du modèle est d'aller voir en fin de page en mode édition : il y a une liste des « Modèles utilisés par cette page » (d'où on devrait d'ailleurs retirer les modules pour les mettre dans une liste a part, car pas grand monde sait comment les éditer ou même s'en servir). Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 8 juillet 2022 à 17:34 (CEST)

Effectivement, l'accolade fait partie des caractères interdits dans les titres de page, tout comme les crochets, barre verticale ou dièses qui ont un rôle propre (d'ailleurs un script de maintenance que j'ai écrit pour contrôler les paramètres du modèle Lien détecte la présence de ces caractères problématiques). Néanmoins, on peut observer que la recherche simpliste de { dans le moteur de recherche mène à l'article Symboles typographiques japonais qui contient les caractères « ｛ » et « ｝ », des accolades unicode U+FF5B et U+FF5D (avec une espace large précédant ou suivant nos accolades classiques U+007B et U+007D). Donc si on introduit « ｛｛ » et « ｝｝» quelque part (si besoin de façon "cachée") dans l'aide:Modèle, une recherche dans l'aide générale de {{ ou }} devrait conduire à la page d'aide souhaitée. Attention toutefois à ne pas utiliser ces caractères pour appeler des modèles car cela ne fonctionnerait pas.

La découverte des modèles est assez rapide pour un débutant. Une page comme Aide:Syntaxe évoque les modèles et possède de nombreux liens vers certains d'entre eux.

Contrairement à ce qu'il semble croire, SyntaxTerror n'est pas le seul à ne pas se servir de l'éditeur visuel, si tant est qu'un éditeur de code source ne soit pas "visuel". La plupart des pages de discussion sont éditable uniquement en « mode source ». Ou alors, il y a beaucoup de « vieux croûtons ». — Ideawipik (discuter) 8 juillet 2022 à 18:41 (CEST)

Merci.

C'est l'explication que j'attendais.

PS Je suis aussi un vieux croûtons. Io Herodotus (discuter) 9 juillet 2022 à 13:48 (CEST)

(274301) Wikipedia dans les articles liés?

En regardans dans la catégorie des articles liee du portail je trouve cet article qu’il n’a aucun rapport avec les langues et n’a pas le portail langue…Bug? TYURZ🗣Parler de Wiki?🗣 14 juillet 2022 à 13:52 (CEST)

Le pire c’est qu’on ne peut pas modifié la catégorie TYURZ🗣Parler de Wiki?🗣 14 juillet 2022 à 13:53 (CEST)

1Lib1Ref;3/24; aussi je pense qu’il n’y a encore beaucoup TYURZ🗣Parler de Wiki?🗣 14 juillet 2022 à 13:56 (CEST)

J’ai fouillé et ne comprend pas.

3/24 est lié au portail:Langue catalane. Mais pour les autres exemples, je ne peux mettre en cause ni portail, ni palette.

— Sernin SC _(discussion) 14 juillet 2022 à 15:07 (CEST)

Moi aussi je n’y comprends rien TYURZ🗣Parler de Wiki?🗣 14 juillet 2022 à 15:21 (CEST)

Les 404 pages de la catégorie:Portail:Wikimédia/Articles liés sont incluses dans la catégorie:Portail:Langues/Articles liés.

Mais je ne comprends pas encore pourquoi.

— Sernin SC _(discussion) 14 juillet 2022 à 15:29 (CEST)

┌─────────────────────────────────────────────────┘

J'ai recopié la conversation depuis le café des linguistes, car je pense que c'est sans doute une histoire d'infobox ou de palette, mais je n'ai pas réussi à trouver quoi.

En tous cas, les gens ici seront plus à même de trouver d'où vient le problème. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 14 juillet 2022 à 23:23 (CEST)

Bonjour TYURZ, Sernin SC et SyntaxTerror. Une recherche Spécial:Recherche/incategory:"Portail:Wikimédia/Articles liés" -hastemplate:"Portail Wikimédia" semble montrer que toutes les pages concernées portent le bandeau du portail:Wikimédia, indépendamment de tout autre portail. Une recherche Petscan:22459908 le confirme. Donc la catégorisation paraît logique ou tout du moins techniquement cohérente. En effet, le Modèle:Portail Wikimédia catégorise à la fois dans Catégorie:Portail:Wikimédia/Articles liés et dans Catégorie:Portail:Langues/Articles liés et également dans les articles liés au Portail:Internet et au Portail:Associations. Si ce n'est pas pertinent, c'est ce modèle qu'il faut modifier. Ensuite des modifications nulles seront peut-être nécessaires afin de purger la catégorie. — Ideawipik (discuter) 15 juillet 2022 à 00:28 (CEST)

Merci d'avoir trouvé la source du problème Ideawipik. Je viens de retirer la Catégorie:Portail:Langues/Articles liés de ce modèle, car ce n'est effectivement pas pertinent d'ajouter en masse comme ça des articles liés. Si certains articles doivent vraiment être ajoutés, ça doit être fait « à la régulière ».

J'ai fait un null edit dans la catégorie au cas où. merci de ton aide, cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 juillet 2022 à 00:58 (CEST)

Merci pour l’information. Je n’avais pas pensé à regarder le modèle portail !? — Sernin SC _(discussion) 16 juillet 2022 à 18:22 (CEST)

Erreur de Lint div-span-flip

Bonjour. Les pages qui sollicitent le modèle:Location map~ avec des balises <div> dans le paramètre label (sur wstat) du modèle déclenchent une erreur de Lint « div-span-flip » (Spécial:LintErrors/misc-tidy-replacement-issues) en raison de l'imbrication <span>…<div>…</div></span> Une solution pourrait être de remplacer dans le code du modèle les « span » par des « div » mais cela risque de modifier les positions actuelles de ces annotations sur les cartes sollicitant le modèle {{Location map~}} dans les articles. Quelle est la meilleure correction à votre avis ?

PS : On remarquera aussi que l'affichage n'est pas forcément idéal/homogène si plusieurs éléments sont présents dans le paramètre (le modèle génère des <p> au milieu mais pas au début de l'ensemble affiché).
— Ideawipik (discuter) 21 juillet 2022 à 00:23 (CEST)

Problème Liste des chapitres de Kingdom

Bonjour au projet

Existe-t-il un moyen de régler le problème d'un trop grand nombre de modèles sur une page ? L'article Liste des chapitres de Kingdom ne peut pas afficher l'intégralité de la page : « Attention : cette page contient trop d’inclusions de modèles. Certaines inclusions ne seront pas effectuées. »

Merci pour votre aide VKaeru ^crôa ? 23 juillet 2022 à 13:11 (CEST)

Apparemment ce n'est pas la nombre d'inclusions de modèles qui pose problème, c'est la « Taille d’inclusion après expansion » qui a atteint sa limite (2 097 152 octets). La meilleure solution semble donc de scinder la page. Alserv (discuter) 23 juillet 2022 à 15:38 (CEST)

Une solution à plus long terme serait sans doute de recoder le Modèle:Japonais en Lua. Le modèle n'est pas gros mais contient de multiples expansions de ses arguments, d'où sans doute le problème. Le modèle contient aussi beaucoup de #if, le Lua aiderait. Il contient aussi beaucoup d'appels au Modèle:Langue qui est déjà écrit en Lua et qui pourrait être appelé directement à partir d'un code Lua.

Mais les choses ne sont pas toujours aussi simples qu'il y paraît au premier abord, la question nécessiterait d'être analysée plus en détail.

-- Alserv (discuter) 23 juillet 2022 à 15:55 (CEST)

Le problème est la taille de la page finale. Recoder le modèle en Lua ne changerait rien au problème. (edit : en fait si, la taille calculée est actuellement démultipliée, voir messages suivants)

La première piste serait de réduire la quantité de markup généré. Par exemple, chaque petite icône d'aide avec son CSS inline, pèse 491 octets. Cependant, je n'ai pas étudié si réduire cela serait suffisant, ou s'il y a d'autres éléments de la page qui pèsent encore plus lourd.

Donc avant d'essayer d'alléger le markup, il faudrait déjà faire une estimation pour voir si cette approche serait suffisante pour permettre d'afficher la page, et sinon, il faudrait directement procéder au scindage de la page.

od†n ↗^blah 24 juillet 2022 à 05:28 (CEST)

Pendant que je rédigeais mon message, Ideawipik a justement traité le problème : 195551465. od†n ↗^blah 24 juillet 2022 à 05:35 (CEST)

Et effectivement, les #if imbriqués multiplient la taille calculée : en:Wikipedia:Post-expand include size. od†n ↗^blah 24 juillet 2022 à 05:38 (CEST)

Et si on en croit 159343299, ce n'est pas la première fois qu'il y a des problèmes de poids avec ce modèle (bien entendu s'il est utilisé un grand nombre de fois sur la page). Aussi, il pourrait effectivement être judicieux de l'écrire en Lua, car il serait préférable d'avoir un seul require 'Module:Langue' suivi de plusieurs Langue.langue(), plutôt que actuellement plusieurs {{Langue}} qui iront exécuter plusieurs {{#invoke:Langue|langue}} (c'est-à-dire plusieurs chargements du module Langue). od†n ↗^blah 24 juillet 2022 à 17:21 (CEST)

Bonjour od†n. Effectivement, entre les #if et les appels en cascade actuels, ce serait avantageux sans aucun inconvénient. Dans cette situation, on pourrait penser qu'il est préférable de traiter de la même façon les modèles équivalents parmi la catégorie:Modèle pour les langues en définissant une fonction commune, avec un paramètre de langue. Mais, en réalité, on a des paramétrages si différents et des rendus si disparates qu'il est difficile de l'envisager sans une remise à plat généralisée sur l'usage de ces modèles dont le nombre reste assez faible. Curiosité personnelle : si cela avait été le cas et afin de ne pas (trop) impacter d'autres modèles sollicitant le module — question de chargement —, où aurait-il été opportun de définir la fonction "principale" mutualisée : dans Module:Langue ? dans une sous-page du module Langue ? dans un autre module, séparé ?

En l'occurrence, souhaites-tu créer un Module:Japonais ? — Ideawipik (discuter) 24 juillet 2022 à 18:17 (CEST)

Je ne sais pas quel aurait été le meilleur endroit pour ajouter une telle fonction, c'est à voir au cas par cas, selon comment la situation se dessine ; et à la rigueur c'est toujours relativement simple à déplacer ultérieurement (sous réserve que le code ne se soit pas retrouvé à être utilisé un peu partout dans tous les sens au fil du temps).

Pour ce qui est de créer le module, c'est tentant mais je n'en ai guère le temps… Mais si on s'en tient à un module réimplémentant seulement le modèle {{Japonais}}, cela devrait être relativement simple.

od†n ↗^blah 25 juillet 2022 à 00:52 (CEST)

Réponse pour assouvir la curiosité du demandeur. Si trop long, aller directement au PS.

Bonjour VKaeru. La raison est que l'intégralité du contenu de cet article (sauf les trois phrases introductives) est inséré via un modèle. Donc la taille d'expansion des modèles est énorme. Pour faire une analogie, comparons

{{Colonnes|…|1=}}
* A
* B
…
}}

et

{{Début de colonnes|…}}
* A
* B
…
{{Fin de colonnes}}

Ces deux syntaxes ont exactement le même rendu. Avec la première syntaxe tout le contenu de la liste en colonnes est compté comme insérée par un modèle. Avec la seconde, seulement le début de la section et la fin (balises de mis en colonnes) sont insérés par modèle. Ce qui peut aboutir à une grande différence sur la « Taille d’inclusion après expansion ». C'est le type d'économies faciles à faire. Et en plus on réduit le risque d'avoir un signe égal dans le modèle interprété comme la définition d'un paramètre, si le 1= initial a été omis.

Revenons à l'article soulevé ici, en commençant par des détails peu importants et de fausses bonnes idées

• Dans la version signalée du code de l'article figure un petit problème de syntaxe HTML : des balises non symétriques dans les paramètres chapitre des modèles sollicités sur la fin du document avec des doubles fermetures de div au lieu d'une ouverture et d'une fermeture. La correction, simple, ne coûte rien et permettra de gagner une miette sur la taille totale ; il ne faut pas s'attendre à un gain significatif.
• Idée d'économie de bouts de chandelle non recommandé car le gain est nul : remplacer {{Références}} par <references/> et les appels avec groupe et références définies dans le modèle par <references group="…"><ref name="…">…</ref> … </references>. Dans ton cas, vu que le texte de chacune des références est très court, je proposerais d'entourer la balise <references> d'un div
  <div class="references-small" style="column-width:15em;">…</div> (avec éventuellement un column-count dans l'attribut de style pour fixer un nombre maximum de colonnes mais cela me semble superflu étant donné le grand nombre de références). Mais, je le répète, le gain sur la taille sera quasiment nul, donc ce n'est pas une solution à recommander. La seule différence est que les références individuelles — et encore uniquement si elles ne sont pas introduites via un modèle —, seront lisibles.

Pour une réponse plus satisfaisante, voici des pistes à explorer.

1. Élaguer l'article. Est-ce que certains détails peuvent-être considérés comme superflus ou sans intérêt encyclopédique ? La page n'est autre qu'un catalogue d'ISBN et de titres de chapitres ; les "références", des liens vers le site de l'éditeur, sources primaires et commerciales… En outre chacun de ces liens ne présente pas de liste de chapitre mais seulement un titre de volume, ce dernier n'étant d'ailleurs pas repris sur Wikipédia. D'où sortent donc les noms des chapitres ? Une compilation personnelle ? Pas sûr qu'on rentre dans le cadre de Wikipédia:Wikipédia est une encyclopédie#Listes.
2. Remplacer l'appel des modèles TomeBD par des syntaxes classiques de tableau ou réorganiser partiellement la page. Remarque connexe : le tableau généré par le modèle {{TomeBD}}, avec une structure aux cases fusionnées, n'est pas vraiment accessible.
3. Si ces nombreux modèles sont dans la page depuis longtemps, on peut imaginer qu'à un moment il n'y avait pas de problème d'affichage ni dépassement des limites techniques. On peut regarder, dans le code de {{TomeBD}}, s'il y a eu des évolutions expliquant une augmentation de la taille d'inclusion et tenter de remédier à ce poids.
   • En réalité, Le problème est consécutif à un ajout massif de contenu volumineux (voir point 4) faisant passer la taille d'inclusion après expansion pour l'article de 808 394 à environ 2 350 000 octets.
4. Au niveau du modèle {{japonais}} mêmes considérations.
   • On notera que le modèle japonais insère des infobulles (visibles au passage de la souris sur les éléments : « Japonais », « Transcription Hepburn », « Information complémentaire ». On pourrait envisager un paramètre permettant de désactiver ces infobulles (redondantes dans ce type de liste), afin d'avoir une version allégée.
   • Les balises introduites sont munies d'attributs : <span class="lang-ja" lang="ja"> ou <span class="lang-ja-latn-alalc97" lang="ja-latn-alalc97">. Je ne sais pas quelle est l'utilité de la classe dans ce cas, mais, si elle a une utilité, il est peut-être possible de la surcharger afin d’intégrer la langue dans la classe.
5. Déjà envisagé par Alserv, scinder l'article. Mais selon quel critère ?

Et il y aura sûrement d'autres idées de modélistes.

PS : une petite comparaison des rendus et de la « Post‐expand include size » si on retire infobulles, liens vers Aide:Japonais et éléments HTML invisibles superflus dans la présente situation :

• {{japonais|Le souffle de Bananji|馬南慈の気概|Bananji no kigai}} → 1576 octets
• Le souffle de Bananji ({{Langue|ja|馬南慈の気概}}, ''{{Langue|ja-Latn-alalc97|Bananji no kigai}}'') → 276 octets
• Le souffle de Bananji ({{Langue|ja|馬南慈の気概}}, ''Bananji no kigai'') → 114 octets

J'ai appliqué la deuxième solution dans l'article ; cela laisse un peu de marge avec un retour à 747790/2097152 bytes, tout en restant accessible. Cette syntaxe correspond à ce qui était envisagé au point 4 pour le modèle Japonais. Rien n'empêche de réintroduire des modèles plus lourds/complets sur la première ligne des tableaux dans l'article. — Ideawipik (discuter) 24 juillet 2022 à 06:15 (CEST)

Apparemment j'ai posé la question au bon endroit, merci au projet, vous assurez ;)

Concernant vos solutions, la scission de l'article reste envisageable, sur le modèle de Liste des chapitres de One Piece qui se divise en 4 sous-articles, mais ça ne fait qu'étendre un article limite du point de l'admissibilité, comme souvent les articles de liste. J'ai créé cet article en premier lieu pour décharger la page générale et se concentrer sur les informations sourçables et non WP:BASE, ce genre d'article semblant néanmoins répondre à un grande demande (l'article sur les chapitres recevant tout de même un grand nombre de consultation par rapport à l'article général, et on peut imaginer que de nombreuses lectures du général se font pour parvenir au deuxième). La solution appliquée plus haut par @Ideawipik me semble répondre efficacement au problème, aussi je pense qu'il n'est pas vraiment nécessaire d'aller chercher plus loin.

Merci à tous les membres du projet pour leurs explications et leur aide, bonne continuation

--VKaeru ^crôa ? 24 juillet 2022 à 09:49 (CEST)

span avec IndexCE

Bonjour, 5 articles de chimie (liste via la recherche "Numéro index <span title" -- ex : Rouge congo, Trioxyde de chrome -- ) ont des span apparent qui arrivent via l'utilisation de {{IndexCE}}
Exemple : {{indexCE|028-003-00-2}} => 028-003-00-2
J'ai l'impression que c'est lié à l'utilisation d'un modèle sur la ligne par exemple : 028-003-00-2
Cordialement Drongou (discuter) 24 juillet 2022 à 15:38 (CEST)

Désolé pour le dérangement, ce modèle fait un lien externe vers un site qui à l'air mort depuis très longtemps (10 ans, j'ai l'impression)
Exemple avec un rendu correct mais un lien HS : {{indexCE|601-003-00-5}} => 601-003-00-5
Je vais voir avec le projet Chimie (après mes vacances). Cordialement - Drongou (discuter) 24 juillet 2022 à 16:03 (CEST)

Pas vraiment une solution, mais cela pourrait vous tirer d'affaire provisoirement: dans le Modèle:IndexCE, remplacer les chiffres romains entre double accolades genre {{II}} par les mêmes chiffres sans doubles accolades, genre II.

Pour une explication un peu plus technique: apparemment il y a un problème quelque part dans la génération du texte. Premier exemple qui ne marche pas: [http://fr.wikipedia.org <span title="numéro {{II}}">texte</span>] génère <span title="numéro II">texte avec un texte erroné, alors que [http://fr.wikipedia.org <span title="numéro II">texte</span>] sans les doubles accolades génère texte qui s'affiche très bien. Pour ma part, je n'en connais pas suffisamment pour trouver la vraie cause du problème. Probalement en problème d'interaction entre le code généré par les chiffres romains et les guillements du title= .

Mais peut-être vaut-il mieux attendre des informations de quelqu'un de plus compétent que moi.

Cordialement, Alserv (discuter) 24 juillet 2022 à 17:44 (CEST)

Les double accolades ont été introduites par cette modification.

Le texte devant déjà apparaître dans une infobulle, les chiffres romains devraient alors apparaître dans une infobulle dans l'infobulle ? J'avoue que je ne comprends pas très bien.

Cordialement, Alserv (discuter) 24 juillet 2022 à 18:22 (CEST)

Bonjour Drongou. Alserv a bien identifié le problème, lié à cette modification dans l'ensemble superflue, voire cassant l'affichage avec l'introduction inappropriée des modèles de mise en forme des nombres romains. Ces modèles n'ont pas lieu d'être dans des attributs de balises HTML. Il sont à réserver au texte affiché dans les articles. Les rares choses que l'on peut considérer utiles dans cette modification sont les corrections typographiques comme tout en bas d’ argent → d’argent et l'ajout d'un {{I}} dans du texte affiché uniquement dans la page du modèle (tout en haut) — même si c'est un gadget et qu'idéalement, cela nécessiterait aussi une espace insécable —. Le remplacement des entités HTML dans les attributs, ne change pas le comportement du modèle, comme on pourrait le constater en comparant <span title="cyanure d&#39;hydrogène">Voir l'infobulle</span> et <span title="cyanure d'hydrogène">Voir l'infobulle</span>. En revanche, <span title="élément {{V}} bis">Texte</span> est équivalent à, accrochez-vous, <span title="élément <abbr class="abbr" title="5"><span class="romain" style="text-transform:uppercase">V</span></abbr> bis">Texte</span>. On comprend la raison du dysfonctionnement, l'attribut title devant recevoir du texte "brut" sans certains caractères. Ainsi, un "simple" <span title="A>B">…</span> serait déjà problématique. Dans le modèle cela sert de libellé à un lien externe.. La correction consiste en la proposition initiale d'Alserv. Point positif, le problème ancien a permis de relever un autre problème : l’obsolescence du site externe. — Ideawipik (discuter) 24 juillet 2022 à 19:33 (CEST)

Difficile de se convaincre que c'est comme ça depuis 9 ans mais je pense que c'est la seule conclusion possible. En fait, je pensais avoir déjà cherché du span bizarre mais visiblement jamais cette configuration.
Et donc un autre modèle vainqueur {{DHS}} sur Pully (ma recherche) -- Pour lequel la réponse ci-dessus est aussi valable --

{{DHS|2412|Pully - Du Moyen Age au {{s-|XX}}|auteur=André Schmutz}}
=>
André Schmutz, « <span title="Pully - Du Moyen Age au XX^e siècle en français">Pully - Du Moyen Age au XX^e siècle » dans le Dictionnaire historique de la Suisse en ligne.

mais pour celui-ci ce n'est pas intrinsèque au modèle mais comme plus habituellement dû à une hyper wikification.
Merci à tous les deux :  Alserv et Ideawipik Cordialement - Drongou (discuter) 25 juillet 2022 à 00:33 (CEST)