Discussion modèle:Autre4

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons
[[ et ]] sont en trop.

Pourriez-vous jeter un œil au code ? — Neustradamus () 14 juin 2009 à 04:04 (CEST)[répondre]

UP — Neustradamus () 26 juin 2009 à 12:15 (CEST)[répondre]
Ce n'est pas un bug mais un usage erroné du modèle: celui-ci n'est pas destiné à produire un lien vers wp:en (le [[:en:C|C (en anglais)]] de ton exemple. Seuls des liens vers wp:fr doivent y figurer. --Lgd (d) 27 juin 2009 à 09:24 (CEST)[répondre]
Mais on pourrait apporter la fonction, vu qu'il est possible que l'article n'existe pas en français, en mettant un lien possible vers un autre wikipedia — Neustradamus () 28 juin 2009 à 01:18 (CEST)[répondre]
Dans ce cas, plutôt utiliser {{lien}}. :-) Dodoïste [ dring-dring ] 28 juin 2009 à 01:38 (CEST)[répondre]

utilisation dans Catégorie:Label musée de France, etc.[modifier le code]

Il y a un bug d'affichage dans l'utilisation du modèle en en-tête de la Catégorie:Label musée de France, et de ses des sous catégories (par exemple ici). Peut-être ne doit-on pas proposer de catégorie (comme Catégorie:Musée français) avec ce modèle ? Piero (d) 29 juin 2012 à 10:38 (CEST)[répondre]

Bonjour, est-ce que l'usage de cette catégorie en Autre4 ne fait pas double emploi avec le bandeau Arborescence des musées ? Cordialement, Kertraon (d) 29 juin 2012 à 13:30 (CEST)[répondre]
Bonjour Kertraon. Bonne question. Je constate, en tout cas, que lien avec la catégorie a été supprimé de l'en-tête de l'article Musée de France. On peut donc envisager de supprimer ce lien (avec un robot) de tout les en-tête de catégories en question. Cordialement. Piero (d) 29 juin 2012 à 14:15 (CEST)[répondre]

Fusion de modèles similaires ?[modifier le code]

Bonjour Notification Od1n, Epok et Eru.
Les statistiques des modèles {{Autre4}} (destiné à afficher des liens vers deux articles au maximum) et {{Autre5}} (destiné à en afficher un ou trois) montrent que, pour le second modèle, dans 30% des utilisations avec au moins deux articles, il n'y a pas de troisième article précisé (dernier paramètre) et donc pas d'affichage du mot de liaison « et » entre les deux articles. Inversement, on rencontre une poignée d'appels du premier avec une valeur supplémentaire non affichée. stats Autre4, stats Autre5.

Ne pourrions-nous pas fusionner les deux modèles, en sollicitant le modèle {{Multiparamètres-Lien}} ? Ainsi l'affichage s'adaptera aux circonstances et on participerait à la réduction du nombre de modèles. Je pensais à un truc du genre ceci :

{{#if: {{{1|}}}|Cet article concerne {{trim|{{{1}}}}}. }}Pour {{#if: {{{2|}}}|{{{2}}}|les autres significations}}, voir {{Multiparamètres-Lien|{{#if: {{{3|}}}|{{{3}}}|{{#invoke:String|simpletitle}} (homonymie)}}|{{{4|}}}|{{{5|}}}}}.

Le Module:Multiparamètres ne gagnerait-il pas à voir la fonctionnalité {{lien préfixé avec un deux-points}} être intégrée à sa fonction p.lien ?

Tant pour la dernière proposition que pour la fusion proposée, quel serait l'impact au niveau des performances ? Merci pour vos avis. — Ideawipik (discuter) 10 octobre 2021 à 23:34 (CEST)[répondre]

Salut Ideawipik Bonjour,
Oui, ces modèles posent un problème certain, ne serait-ce que parce que si le nombre de lien change, il faut changer le modèle.
Un appel à un module Lua est généralement la solution la plus simple à ce genre de cas où le nombre des paramètres peut varier d'un appel à l'autre. La question est de savoir : trouvera-t-on notre bonheur dans un module existant, éventuellement avec une légère adaptation comme tu le proposes, ou bien ne serait-il pas plus simple de bâtir un module sur mesure ? Je rappelle qu'un module peut faire appel à un autre module pour ne pas dupliquer les fonctionnalités.
Pour ce qui concerne les performances, si impact il y a, ce sera très mineur considérant la simplicité de la fonctionnalité. Le problème ne se posant qu'à l'édition de la page, même si les perfs sont légèrement impactées ce n'est pas vraiment un problème de mon point de vue. Après, on peut faire des benchs pour connaître l'impact réel si besoin.
Par ailleurs, je pense qu'il faut aller au-delà d'une fusion entre {{Autre4}} et {{Autre5}} : il faut tout fusionner dans {{Autre}}.
Même remarque pour {{Redirect}} et ses dérivés {{Redirect2}}, {{Redirect3}}, {{Redirect4}} et {{Redirect5}}, ainsi que pour {{2autres}} et {{3autres}}. Dans chaque cas, on ne devrait pas avoir à choisir le modèle pour une même fonctionnalité en fonction du nombre de paramètres.
On peut s'inspirer du modèle {{Voir homophones}} qui fonctionne sur le principe que tu proposes.
Epok__ (), le 11 octobre 2021 à 07:52 (CEST)[répondre]
Notification Ideawipik : Très bonne analyse :-) Aucune objection, tant pour la fusion de modèles (bien vu, le coup du Autre5 sans troisième lien) que pour la création d'un "multiparamètres lien préfixé" (je n'y aurais pas pensé). Pas de problèmes de performances non plus, puisqu'on reste sur une unique invocation d'un module Lua léger. od†n ↗blah 11 octobre 2021 à 16:29 (CEST)[répondre]
@Od1n. J'ai modifié le module. N'hésite pas à corriger, retoucher, optimiser, indenter ou même annuler ! Normalement, il ne doit pas y avoir d'appels du module pour des catégorisations puisque les séparateurs introduits n'auraient pas lieu d'être, ni pour des liens interlangues, principalement gérés via Wikidata aujourd'hui. Mais j'ai quelques scrupules devant le nombre de "sub"et tests réalisés pour rien et le nombre de « : » superflus ajoutés un peu partout. Ne pourrait-on limiter l'ajout aux espaces qui le requièrent pour l'établissement d'un lien ?
Pour le modèle {{Autre4}}, pour lequel je n'ai pas les droits, tu peux appliquer la proposition ci-dessus en remplaçant l'invocation du module String par l'appel du modèle dédié {{Titre sans précision}}. {{Autre5}} pourra être transformé en redirection.
@Epok. Techniquement, {{Autre}} sollicite déjà {{Autre4}} (le code est factorisé).
Pour l'utilisateur, il est envisageable de ne conserver qu'un seul modèle pour "Autre" et un seul pour "Redirect", voire un unique modèle pour tout, mais dans les deux cas, il faudrait impérativement se servir de paramètres nommés et non positionnels (ou numérotés), sinon, ce sera incompréhensible/inutilisable parce qu'on a plein de paramètres facultatifs, on se perdra dans le nombre de || vides. De plus, les évolutions éventuelles seraient plus simples. Ainsi, pour les {{Autre…}}, {{Nautres}}, on a :
  1. l'objet du présent article ;
  2. le titre de chaque énième page à lier (sujet ou page d'homonymie) ;
  3. le descriptif/objet relatif à chaque énième page (dans les modèles Nautres) ou un descriptif introductif commun (dans les modèles Autres…).
Il y a aussi un point délicat avec les modèles {{2autres}} et {{3autres}} : les paramètres implicites générés à partir du titre de la page sur les derniers paramètres. Si la fonctionnalité peut s'avérer pratique sur le premier paramètre "article", comme dans le modèle Autre pour une utilisation sans paramètre spécifié*, cette particularité plus loin dans l'ordre des paramètres présente le risque de voir deux fois le même article lié, si on retire un paramètre sans changer de modèle. Cependant, il est logique que ces autres « autres significations » apparaissent en fin de liste. À considérer pour le choix des noms de paramètres. * Objection : dans ce cas un {{Voir homonymes}} est presque aussi bien, la seule différence étant l'amorce (objets du présent article et de la page d'homonymie).
Pour "Redirect", on ajoute les noms des redirections pointant vers la page.
Une autre possibilité serait de passer tout, ou partie, en texte libre, dans le bandeau. Ce qui rendrait les éléments moins manipulables par bot…
Donc je ne sais pas si une fusion sera plus pratique au niveau de la syntaxe, notamment pour les habitués du wikicode. Mais l'idée d'avoir un unique modèle est séduisante, car on se perd dans ces foules de modèles et on perd aussi les néophytes. On voit aussi des articles qui cumulent les bandeaux pour des variantes mineures. Techniquement, la transition pourrait se faire en douceur, surtout si on utilise un nom de modèle inexistant, comme « Autres » ou « Voir autres ». La discussion devrait-être élargie au projet:Modèle.
Ideawipik (discuter) 11 octobre 2021 à 19:54 (CEST)[répondre]
J'ai effectivement vu pour ta modification du module. De mon côté j'avais initialement pensé à ajouter une nouvelle méthode distincte du genre p.lienAvecPrefixeDeuxPoints(), par principe de précaution, pour les performances, et surtout pour ne pas ajouter des deux-points partout. Mais tout compte fait, à modifier la méthode existante, c'est quand même plus simple, je ne vois pas ce que cela pourrait casser, pour ce qui est des performances on ajoute seulement un string.sub() qui reste très léger, le seul problème (tant est que cela en soit un, car ça reste cosmétique) est que cela ajoute des deux-points partout.
J'avais pensé à effectuer une analyse plus poussée du titre de la page, de sorte à n'ajouter le deux-points que si nécessaire. Ça peut se faire, mais il faut voir ce que ça donne au niveau des performances.
Pour ce qui est des bandeaux Autre etc, y a-t-il beaucoup de pages qui utilisent les titres implicites (les « {{Titre sans précision}} (homonymie) ») ?
od†n ↗blah 14 octobre 2021 à 17:37 (CEST)[répondre]
Je viens d'implémenter le préfixage ssi nécessaire : 187142808. Il n'y a notamment pas de recours à mw.ustring, et encore moins à mw.title, donc niveau performances cela devrait rester très correct, même s'il serait certainement possible de nano-optimiser (au prix d'un code plus compliqué). od†n ↗blah 14 octobre 2021 à 18:34 (CEST)[répondre]
Tout compte fait, j'ai préféré revenir à la version plus performante, refs 187287692. od†n ↗blah 27 octobre 2021 à 06:41 (CEST)[répondre]

Retouche orthographe que je ne peux pas faire moi-même[modifier le code]

Bonjour,

Petit souci à signaler dans la phrase « Si les arguments 4 et/ou 5 (articles supplémentaires) sont omis ou vides, il ne s’affichent pas. » : c'est ils si je comprends bien le sens (c'est déjà un peu touffu, autant éviter une aspérité qui distrait la lecture).

Merci pour le travail ! bien cdt — Couleys [कुरा गरौं] 26 novembre 2021 à 18:13 (CET)[répondre]

Bonjour Couleys Émoticône,
La phrase en question est fournie par cette page, tu peux donc bien la modifier toi-même Émoticône.
Wikipédiennement, Epok__ (), le 26 novembre 2021 à 18:40 (CET)[répondre]
Bonjour Epok Émoticône et merci ! toujours sympa de laisser faire l'élève. Du coup j'ai vu qu'il y a un lien en bas de la page de doc, qui pointe vers une autre que celle que tu m'as indiquée ?! compliquée la structure de la machine. J'ai corrigé celle que tu m'indiques et ça modifie les 2 autres, un peu mystérieusement.
Pas grave, on va dire que j'ai assez appris pour aujourd'hui ; bonne continuation — Couleys [कुरा गरौं] 26 novembre 2021 à 20:25 (CET)[répondre]
Notification Couleys : effectivement, la structure n'est pas évidente au premier abord : le modèle {{Autre4}} utilise (comme tous les modèles), le modèle {{Documentation}} pour afficher sa doc. Ce dernier modèle inclus automatiquement la sous-page Modèle:Autre4/Documentation, qui elle-même inclus la page Modèle:Documentation pour "autre" en utilisant celle-ci en tant que modèle (transclusion). Voilà, si jamais ça peut t'aider à comprendre, c'est cool, mais je peux aussi concevoir que tout ceci soit du chinois quand on n'est pas habitué à ces mécaniques...
Wikipédiennement, Epok__ (), le 26 novembre 2021 à 21:07 (CET)[répondre]
Merci Notification Epok ! (j'en profite pour tester une autre formule de notification) Je relirai ça à tête reposée, et je verrai ce que je peux en comprendre. Disons que ça va m'aider à me familiariser petit à petit (sans être informaticien je ne suis pas totalement ignare en matière de code), et effectivement c'est cool. À la prochaine — Couleys [कुरा गरौं] 26 novembre 2021 à 21:17 (CET)[répondre]