Discussion Projet:Modèle

Discussions actives
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)

OOjs UI icon block-destructive.svg Modèles proposés à la suppression

OOjs UI icon articles-ltr-progressive.svg Nouveaux modèles

OOjs UI icon message-constructive.svg Le projet « Modèle » a 1 notification (voir).

Création de modèles et de modules à partir d'autres versions linguistiquesModifier

Bonjour.

  • Lors de la création sur frwiki de modèles ou de modules, par copier-coller depuis des wikis dans d'autres langues, la moindre des choses ne serait-elle pas de l'indiquer, au moins dans le commentaire de création de la page ou en page de discussion du modèle. Quel est l'usage ?
  • Quid de la création de modèles ou modules inutilisés ?
  • Dans quelle mesure les titres doivent-il être francisés ?
  • Attention à adapter le reste du contenu du modèle ! nom des catégories, etc.

Pour prendre un exemple récent : FrenchPower59500 : modules et modèles mais la question est plus générale et ne vise pas un contributeur en particulier. Il n'y a rien en ce sens dans les Aide:Modèle/Aide:Module.
Remarque annexe : il faudra penser à mettre davantage en valeur les quelques conventions sur les titres spécifiques aux modèles (Nom en majuscule et pas de mot « navigation » dans les palettes, etc) et les catégorisations, pour faciliter la vérification qu'aucun « modèle équivalent n’existe sous un titre différent ».
Cordialement. --Ideawipik (discuter) 17 juin 2020 à 16:47 (CEST)

Salut Ideawipik  ,
De mon point de vue :
  1. Oui, et on peut utiliser pour cela le modèle {{Traduit de}} en pdd, comme pour les articles (j'ai déjà vu ce modèle apposé dans la doc, pourquoi pas aussi).
  2. Ils doivent être identifiés, et si vraiment sont inutiles (doublon d'un modèle français, modèle inutile pour notre version linguistique, modèle toujours inutilisé un certain temps après sa création, etc.), supprimés. Une liste de modèles inutilisés existe déjà : y'a du boulot;
  3. Obligatoirement, avec éventuellement une redirection depuis le titre anglais dans le cas où ils sont susceptibles d'êtres utilisés dans des articles par copier-coller entre les versions linguistiques.
  4. Pareil pour les paramètres et catégories : sur WP en français, les modèles doivent être francisés. La seule exception que je vois est le cas d'un mot dans une autre langue couramment utilisé en français (je ne suis pas un intégriste qui refuse l'ajout de mots étrangers dans une langue, loin de là : si le mot est dans l'usage courant, je l'accepte sans problème).
Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ), le 17 juin 2020 à 17:07 (CEST)

Modèle:Élu - Ajout couleur politiqueModifier

Bonjour,

Je viens vers vous pour avoir votre ressenti concernant une modification de Modèle:Élu. En effet, je souhaiterais que l'on ajoute une colonne supplémentaire dans 'Parti' pour afficher la couleur politique du parti en question, sur le modèle 'Infobox Parti politique français/couleurs'. Le modèle actuel est assez triste, terne, et ajouter une pointe de couleur permettrait d'y voir plus clair (et de terminer la tendance politique d'une commune en un coup d'oeil).

Nous sommes deux à faire cette requête (voir Discussion_modèle:Élu), néanmoins la page est assez inactive donc je fais appel à vous. L'on me demande d'avoir un consensus du projet pour pouvoir faire modifier le modèle (Wikipédia:Demande_d'intervention_sur_une_page_protégée#Modèle:Élu_(d_·_h_·_j_·_↵)).

--Julmath (discuter) 30 juin 2020 à 14:33 (CEST)

  Julmath : Bonsoir, notre projet peut principalement donner un avis technique. Ce qui n'est pas le cas de ta question. Personnellement je n'ai pas d'avis, juste te faire constater que cela ajouterait une colonne, alors que   Roland45 tente de le réécrire en ce moment en en supprimant deux.
Peut-être voir avec le projet:Politique ou le projet:Communes de France ?
--FDo64 (discuter) 30 juin 2020 à 22:19 (CEST)
Bonsoir FDo64, je n'ai pas non plus d'avis tranché sur le fond et ai donné exactement la même réponse que toi au requérant sur la pdd du modèle. Techniquement, il n'y aurait pas forcément besoin d'ajouter une colonne. Cf le tableau suivant, avec deux exemples légèrement différents du paramétrage à régler. L'accessibilité ne devrait pas en être affectée.
Remarque hors sujet : Julmath, il est préférable d'éviter les symboles barre verticale (pipe) dans les titres de section ou de discussion. Pas évident à manipuler pour créer des liens internes.
Test : FDo64. Pourrais-tu, STP, me dire si tu a reçu cette notification (doute sur le fonctionnement avec le tableau placé en dessous). Merci.Ideawipik (discuter) 30 juin 2020 à 23:39 (CEST)
  Ideawipik : Les notifs fonctionnent à partir du moment où on ne modifie pas le texte qui précède le nouveau message, et que l'on signe. --FDo64 (discuter) 1 juillet 2020 à 00:24 (CEST)
Hors sujet, notifs
Donc d'après ton expérience, les notifications fonctionnent même si on utilise plusieurs niveaux d'indentations (deux points) dans sa propre réponse, même avec des tableaux intercalés et même si on ne signe pas à la toute fin du message.
Si on répond d'un bloc, en respectant l'indentation et la signature, même avant le dernier message présent, la notification fonctionne bien. Bien reçu celle du message de Julmath écrit après (23:56) et au-dessus du sien antérieur (23:45). Tout ce qui précède est cohérent si on peut se fier à mw:Manual:Echo. Elle marcherait également quand on fait des réponses point par point intercalées dans le message de son interlocuteur, du moment qu'on ajoute des lignes sans nouvelle section et que la notification n'est pas placée dans un modèle. — Ideawipik (discuter) 1 juillet 2020 à 08:46 (CEST)
Fin du hors sujet.
Période Identité Étiquette Qualité
Début Fin Identité Parti Qualité
Début Fin Identité Parti Qualité
Début Fin Identité Parti Qualité
  Ideawipik : Le tableau rend assez bien, le seul problème est que ça obligerait à renseigner les codes couleur à chaque fois en lieu et place des codes parti définis à Modèle:Infobox Parti politique français/couleurs (et qui nous simplifient bien la vie...). Ça fait un peu mal aux yeux avec des couleurs claires également (ex. #ffeb00), le fait de ne pas avoir de fin de case à proprement parler manque un peu.
J'avoue ne pas être spécialiste des règles d'accessibilité, Modèle:Infobox Parti politique français/couleurs contrevient-il à ces règles? Parce qu'on le voit déjà un peu partout, y compris sur des articles récents...
Merci pour l'avertissement sur les barres verticales, c'est une vieille habitude mais je ne pensais pas qu'elle posait problème avec WP ^^ --Julmath (discuter) 30 juin 2020 à 23:56 (CEST)
Hors sujet, pipe
Comme les crochets et les accolades, le caractère « barre verticale » est un élément très utilisé de la syntaxe wiki : dans les modèles (paramètres), dans les fonctions d'analyse, dans les liens internes, dans les tableaux. Pas la peine d'en rajouter ailleurs ni de compliquer les choses quand ce n'est pas indispensable. Par exemple le code [[Discussion Projet:Modèle#Modèle:Élu | Ajout couleur politique|libellé souhaité du lien]] permettrait de créer un lien vers la présente section. Pas forcément intuitif ce code ascii !
Fin du hors sujet.
Le tableau proposé… Il s'agit juste d'une maquette pour minimiser ma première réaction identique à celle de FDo64 et montrer qu'il existe des réponses aux difficultés entraperçues. L'ajout d'une colonne est une astuce souvent mise en pratique dans WP pour ce genre de "fonctionnalité" mais n'est pas vraiment idéal pour l'accessibilité des tableaux. Il existe donc au moins une alternative. Je ne suis pas assez calé pour juger de l'accessibilité des couleurs choisies. L'intégration, dans le fonctionnement du modèle Élu, des couleurs prédéfinies, via {{Infobox Parti politique français/couleurs}} est prévue. Il y aura un choix à faire pour la méthode d'intégration des couleurs. On peut déjà imaginer des possibilités :
  1. un paramètre supplémentaire couleur à renseigner par un code de la liste, avec l'avantage de laisser de la souplesse pour le contenu du paramètre Parti/Etiquette ;
  2. pas d'ajout de paramètre et une utilisation du paramètre déjà existant. On perdrait l'avantage précédent ;
  3. un fonctionnement hybride mais qui pourrait aboutir à un modèle plus complexe et gourmand en ressources, avec un recours à davantage de tests internes
Mais attendons les avis des projets concernés avant d'agir,seulement si un consensus en ce sens est établi.
Ideawipik (discuter) 1 juillet 2020 à 08:46 (CEST)
  FDo64 : Bonsoir, merci pour ta réponse. À vrai dire je me suis un peu mal exprimé, c'est une colonne en plus en termes de data mais stricto sensu c'est plutôt une espèce de division d'une colonne déjà existante, une bordure de case peut-être (cf Élections_municipales_de_2020_en_Seine-et-Marne#Maires_sortants_et_maires_élus, ça sera plus clair).
J'ai posté sur les pages de discussion des deux projets cités et attends une réponse de leur part. --Julmath (discuter) 30 juin 2020 à 23:45 (CEST)
Bonjour à tous. Pour ma part je ne suis pas contre l'ajout d'une couleur au modèle pour définir la nuance sur laquelle est élu le maire, mais ceci ne s'appliquerait qu'aux élections après la Libération, avant cela ne veut pas dire grand chose, et encore moins avant 1884 puisque qu'avant cette date les maires étaient nommés et non élus au suffrage universel. Donc je confirme par ailleurs mon souhait de disposer d'un modèle ne comportant pas cette colonne parti. La présentation des données pourrait être éclatée en deux tableaux : avant et après Libération, ou avant et après 1884, comme on veut. On pourrait donc avoir deux modèles. Cordialement.Roland45 (discuter) 1 juillet 2020 à 14:16 (CEST)
  Roland45 : Bonjour, bonne remarque. Certains articles de commune font déjà la distinction entre l'après- et l'avant-Libération, ça serait quelque chose à généraliser. Avant Libération, la colonne "Parti" est presque totalement inutile car souvent vide dû au manque de disponibilité de la donnée.
Plusieurs exemples pour chaque cas de figure: Moret-sur-Loing possède deux tableau séparés, un pré-44 l'autre post-44; Fontainebleau possède un tableau déroulant pré-45 dans le tableau général; Montereau-Fault-Yonne ne fait la distinction que par rapport à la Révolution, etc... --Julmath (discuter) 1 juillet 2020 à 14:37 (CEST)

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

Bonjour   Amrcmln, Ideawipik, Tyseria, Julmath, FDo64 et Roland45,

Désolé de n'avoir pas pu répondre tout de suite à la notif sur Discussion modèle:Élu#Couleur des tendances politiques, pas eu le temps.

Pour l'accessibilité, je confirme qu'il faut vraiment éviter de créer des colonnes vides pour y mettre uniquement un arrière-plan.

J'ai fait un test avec le lecteur d'écran NVDA, et les colonnes vides sont bien traitées comme des colonnes normales, et annoncées comme telles. Donc cela complique bien la lecture du tableau.

D'autant plus qu'il ne faudrait pas utiliser du balisage HTML, qui a une signification sémantique, pour faire de la mise en forme, qui relève du CSS.

La manipulation de bordures est évidement la première solution à laquelle j'ai pensé, mais le problème, c'est que la modification d'une bordure, par exemple la bordure gauche d'une cellule de la colonne « étiquette », s'applique au centre de cette bordure, soit moitié sur « Identité » et moitié sur « Étiquette ». Le rendu n'est donc pas très esthétique, et peu compréhensible.

Dans le but d'avoir une solution supportées par le plus de navigateurs possibles, pas uniquement les plus récents, j'ai fait quelques tests avec la propriété CSS box-shadow: combinée à un padding-left:. Voici le rendu :

Test {{Élu}}
Période Identité Étiquette Qualité
Début Fin Identité Parti Test modèle {{Élu}} actuel
Début Fin Identité Parti Proposition avec box-shadow:
Début Fin Identité Parti Proposition avec box-shadow:

Cette méthode est parfaitement accessible, reposant uniquement sur le CSS.

L'utilisation de box-shadow: est préférable à linear-gradient(), car mieux supportées par les navigateurs.

Elle est supportée par tous les navigateurs supportant CSS3, soit en gros, tous les navigateurs de moins de 10-12 ans. En pratique, seul Internet Explorer 8 n'est pas compatible (Internet Explorer 6 et Internet Explorer 7 ne peuvent plus consulter les wikis Wikimedia, car non compatibles TLS 1.2, plus de détails sur cette discussion).

Le non support par Internet Explorer 8 et des autres vieux navigateurs n'est pas bloquant dans le cas présent, ces navigateurs n'étant quasiment plus utilisés, et s'agissant d'une information additionnelle. Il n'y a pas de perte d'information réelle en l'absence d'indication de la couleur.

Pour la couleur, elle devrait être gérée soit par un sous-modèle dédié, soit en réutilisant un sous-modèle existant, comme {{Infobox Parti politique français/couleurs}} ou {{Élu2/Couleur}}.

Si vous avez des questions, n'hésitez pas !

--Tractopelle-jaune (discuter) 2 juillet 2020 à 20:43 (CEST)

Honnêtement ça rend plutôt bien! Et correspondrait en plus aux standards d'accessibilité et de compatibilité. Ça me paraît également plus esthétique qu'un dégradé.
Mieux vaudrait faire gérer la couleur par {{Infobox Parti politique français/couleurs}} qui est plus simple d'utilisation et (beaucoup) plus complet. Élu2 ne s'applique qu'aux élections départementales.
J'attends encore une réponse de Projet:Politique et Projet:Communes de France mais j'ai l'impression que les communautés sont assez inactives sur leurs pages de discussion... Néanmoins un tel ajout me paraît relever du bon sens et ne devrait pas rencontrer d'opposition.
J'en profite pour rappeler que ça serait le moment parfait pour effectuer ce genre de modification, dans la mesure où les nouveaux conseils municipaux seront installés dans les jours qui viennent et avec eux viendront tout un tas de mises à jour des articles Wikipédia correspondants.
--Julmath (discuter) 2 juillet 2020 à 22:43 (CEST)
Bonjour. Pas le courage de relire toute la discussion, mais concernant le rendu de la couleur c'est très bien selon moi. Si c'est accessible, c'est excellent ! Est-ce qu'il est aussi prévu qu'il soit utilisé dans les autres tableaux de ce type ? Dans ce cas, est-ce qu'il possible que le code soit plus simple ? Sinon ça va être difficile à imposer comme mode d'affichage.
Je vais déposer un message au Projet:Politique française, p-e plus actif.
tyseria, le 3 juillet 2020 à 16:31 (CEST)
  Tyseria : Pour le code, je comprend pas trop ce que tu veux dire par « plus simple ». Il n'y a que deux propriétés CSS utilisées : style="box-shadow:12px 0 gold inset; padding-left:20px;".
Et le tout est destiné à être géré à l'interne par le modèle. Les contributeurs ne doivent bien entendu pas à avoir manipuler ces propriétés CSS. Il y a deux possibilités :
  1. Ajouter un nouveau paramètre à {{Élu}} pour passer un code compatible avec {{Infobox Parti politique français/couleurs}}. Mais cela complexifie le wikicode dans les articles en ayant à saisir deux fois les partis (une fois le nom au long/code à afficher, et une fois un code autorisé).
  2. Compléter la table de correspondance de {{Infobox Parti politique français/couleurs}} pour gérer également les noms au long courants, avec ou sans lien interne. Et créer un paramètre (par ex. Couleur) optionnel pour les cas inhabituels/non répertoriés, ou pour les nécessités occasionnelles de forcer un code. Deux sous-possibilités :
    • a. La bande de couleur est activée par défaut (si le code/parti est valide, bien entendu), et il faut utiliser Couleur=non pour la désactiver. Peut poser problème quand ce modèle est utilisé dans des articles concernant d'autres pays que la France.
    • b. La bande de couleur est désactivée par défaut, il faut utiliser le paramètre Couleur=oui ou Couleur=CODE pour l'activer. Couleur=oui se baserait sur les couleurs de {{Infobox Parti politique français/couleurs}}. On peut aussi imaginer des paramètres pays-spécifiques.
Je précise que je ne contribue pas au domaine de la politique, ce ne sont que quelques propositions d'un point de vue technique. D'autres possibilités existent.
--Tractopelle-jaune (discuter) 3 juillet 2020 à 18:36 (CEST)
Bonjour. Je confirme ces propositions qui correspondent à celles envisagées supra.
À mon avis, si c'est une solution du type #2b qui est plébiscitée, puisqu'il faudrait spécifier un paramètre dans tous les articles concernés, autant choisir la #1 avec un paramètre couleur à introduire correspondant à l'un des codes définis dans la documentation du Modèle:Infobox Parti politique français/couleurs et éventuellement un code pour les cas indéfinisRemarque.. Cela éviterait d'avoir des paramètres inopérants couleur=oui dans des modèles dont le parti spécifié n'est pas connu du sous-modèle …/couleurs.
Il y a aussi une possibilité :
  • La bande de couleur est activée par défaut si le parti en version longue est connu par le sous-modèle ; désactivable par un paramètre Couleur=non et activable si besoin par un Couleur=CODE valide – ce dernier ayant la priorité sur le fonctionnement par défaut –. En relisant, c'est la #2a me semble-t-il.
Remarque : Même si cela n'est pas très important et dépend de l'option choisie, il faut penser à la gestion des alignements du texte de la colonne dans les cas où l'intégralité ou seulement une partie des lignes du tableau ne contient pas de couleur précisée.
Ideawipik (discuter) 3 juillet 2020 à 20:03 (CEST)

Nouveau modèle BiographieModifier

J'ai créé {{Biographie}} qui permet d'afficher directement la date de décès et de naissance pour une personnalité (exemple Jean Castex (-) ou François Truffaut (-)). N'hésitez pas à me dire ce que vous en pensez et surtout si vous trouver ça utile ou non. --PAC2 (discuter) 9 juillet 2020 à 22:25 (CEST)

Bonjour PAC2. Quelle est la destination de ces modèles ? Voici des remarques, qui se révèlent au final légèrement orientées, mais qui initialement relèvent de réelles limitations techniques objectives plutôt problématiques.
  • Avantages.
    1. On n'a pas besoin d'entrer les dates. Cela dit, ces dates ne changent pas tous les quatre matins.
    2. Dans l'utilisation avec le paramètre Q, si l'article n'existe pas en français mais existe en anglais, on a le lien vers l'article wiki anglophone ; s'il n'existe pas non plus en anglais, lien vers la page Wikidata. Alternative : il existe le modèle {{Lien}}.
  • Critiques et limites du fonctionnement actuel. Potentiellement corrigeable, (pas certain ou à quel prix ?)
    1. La présence des liens internes pour les années de naissance et de mort me semble superflue (point de vue personnel).
    2. Si on utilise le modèle pour un article dont les données Wikidata ne sont pas renseignées, on obtient un lien interne suivi de « (-) »
    3. Le modèle en l'état ne fonctionne pas de façon optimale pour les pages intitulées « Prénom Nom (précision) » ou si on souhaite un libellé de lien différent du nom entier de l'article. Par exemple pour une mise en forme particulière (exposant…).
    4. Si on utilise le modèle pour un article existant mais qui n'a pas d'élément Wikidata associé, alors apparaît un gros message d'erreur.
    5. Si on utilise le modèle pour un article étant une redirection, il y a un message d'erreur, potentiellement pour la même raison que le point précédent. Donc un renommage anodin d'article altère l'affichage dans toutes les pages contenant un lien vers cet article via ce modèle. La correction immédiate de la redirection dans toutes les pages concernées serait nécessaire.
    6. Dans le même genre, avec Q= si un modèle était lié à un élément Wikidata fonctionnel récent ayant un article sur frwiki. S'il s'avère plus tard que cet élément était un doublon sur Wikidata, la fusion dans Wikidata au sein de l'élément le plus ancien entraînera une perte de la détermination du nom de l'article sur frwiki et donc la disparition du lien interne au profit du lien wikidata. Voir la différence : via la redirection WD Q3175768 : « Jean de Wurtzbourg (d) (-) » ; avec l'élément WD cible Q1698791 : « Jean de Wurtzbourg (-) » comme cela serait apparu avec la première syntaxe avant l'action de fusion externe à Wikipédia.
  • Inconvénients :
    1. Une façon de plus d'introduire un lien interne somme toute assez simple pour un apport mineur. Pensons aux nouveaux, pour leur permettre d'assimiler la syntaxe classique des liens internes.
    2. L'ajout d'un modèle va encore compliquer les tâches des contributeurs et des bots qui corrigent/détectent les liens vers les pages d'homonymie et les confusions ou qui remplacent des liens internes suite à des renommages pour homonymie, surtout dans la formulation avec le paramètre Q. Ou bien ces liens ne seront pas maintenus.
Les questions de maintenance et surtout les deux ou trois derniers points critiques, font pour moi pencher la balance (bénéfice)/(complexité, risque). Pour comparaison, introduire des données Wikidata dans un article directement lié à un élément Wikidata propre, comme c'est le cas dans certaines infobox, est bien moins risqué que la proposition faite ici, les renommages ou fusions étant alors directement répercutés d'un wiki à l'autre de façon automatisée presque imperceptible pour l'utilisateur et sans conséquence sur l'affichage des infobox.Ideawipik (discuter) 10 juillet 2020 à 09:31 (CEST)
La critique 6 ressemble à un bug, ça n’a pas l’air normal de pouvoir accéder à la date de naissance sur WD si l’élément est une redirection sur WD mais pas aux articles liés à la redirection. — TomT0m [bla] 11 juillet 2020 à 17:07 (CEST)

Merci pour ce retour détaillé. Je suis d'accord avec la limite no 1 et évidemment conscient des limites actuelles (problèmes de redirection, renommage, etc.)

Effectivement la balance bénéfices inconvénients se discute. Je me donne quelques jours pour y réfléchir

PAC2 (discuter) 12 juillet 2020 à 08:55 (CEST)

Couleur de fond par défaut des modèlesModifier

Bonjour ! Les thèmes sombres sont appréciés par certains utilisateurs pour le confort oculaire qu'ils procurent. Wikipedia n'en propose pas, mais on trouve des CSS personnalisé assez satisfaisants. Avec un thème sombre, le texte a en général une couleur proche du blanc, et il est difficile de s'en éloigner significativement. Le souci est qu'actuellement, de nombreux modèles (en-têtes, infobox, ...) ont un fond blanc et que le texte devient ainsi illisible : si l'on veut les rendre lisibles, on se retrouve à ajouter à son CSS une ligne pour chaque modèle à adapter. J'ai même l'impression que pour certains modèles (comme Modèle:Boîte colorée), ce n'est pas modifiable par CSS.

Comme il me semble que les thèmes sombres ont une certaine popularité, je me demandais :

  • Si, lorsque la couleur de fond d'un modèle est le blanc, on pourrait le remplacer par du transparent ;
  • De même si, lorsque cette couleur de fond est paramétrable, la couleur par défaut pourrait être le transparent au lieu du blanc ;
  • Si cette modification est d'une complexité technique raisonnable (si ça implique d'ajouter 10 lignes de code par modèle, le jeu n'en vaut peut-être pas la chandelle) ;
  • Si vous pensez que la tolérance aux thèmes sombres, et plus généralement aux thèmes utilisateurs, justifient de telles modifications des modèles.

Je suis informaticien, mais je n'ai qu'une connaissance superficielle du CSS. Si ces questions reçoivent une réponse positive, je serais potentiellement volontaire pour modifier les principaux modèles de la manière prescrite. Cordialement, Vincent P. (discuter) 11 juillet 2020 à 01:14 (CEST)

À propos de la catégorie « Modèle par langue »Modifier

Bonjour,
j'ai remarqué une nouvelle venue à la racine de la catégorie « Espace Modèle » : Catégorie:Modèle par langue, créée par   Mywiz en début d'année. Outre le fait qu'il y a là une fantastique arborescence de 11 sous-catégories réparties en 3 branches, tout ça pour casser ultimement un seule et unique catégorie (Catégorie:Palette Écrivain québécois), je ne crois pas vraiment au potentiel de ce classement. De plus, le nom même de la catégorie me semble erroné : il ne s'agit pas de la langue des modèles, mais de modèles relatifs à une langue. Je propose soit de supprimer ce classement, soit éventuellement de le déplacer vers un catégorie de modèles liés à la linguistique, mais en tout cas de le sortir de la racine des catégories de modèles, où elle n'a rien à faire à mon avis.
Votre avis ?
Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ), le 16 juillet 2020 à 09:12 (CEST)

Bonjour, Epok. Pour visualiser, un peu mieux.
J'avoue ne pas comprendre non plus à quoi correspond vraiment cette catégorie. Modèle « par langue », mais par langue de quoi ? Il ne s'agit pas nom plus de modèles « relatifs à une langue » comme on peut en trouver dans Catégorie:Projet:Langues, mais plutôt à des modèles relatifs à un sujet ayant un rapport avec une langue. C'est un pendant à Catégorie:Modèle par pays ; vraisemblablement en ayant à l’esprit uniquement la littérature. Catégorie:Modèle littérature par pays,qui contient de façon abusive (?) Catégorie:Modèle littérature québécoise en dehors de la catégorie canadienne, et Catégorie:Palette Littérature par pays. La volonté de faire aussi une classification par langue peut se justifier compte tenu des pays partageant plusieurs langues, comme le Luxembourg, la Belgique, Suisse, Canada… et pour prendre en compte les langues "régionales". Mais à mon avis, dans le projet Wikipédia, peut-être qu'on peut se contenter d'une telle classification au sein des thématique (Littérature, Musique, Cinéma…) et uniquement si c'est pertinent. Pour une classification de modèles, je ne vois pas l'intérêt de trop catégoriser. J'imagine qu'un contributeur qui chercherait une palette aura la présence d'esprit de faire une recherche par nom ou par thématique/projet (en ajoutant par exemple intitle:/Palette/ à la recherche).
Généralement, le désir de réaliser ce type de catégories « par <une caractéristique> » (« par pays », « par sexe » pour les personnes, ou par type de modèle) entraîne une nécessité de rediviser/préciser toutes les catégories thématiques existantes concernées. Cela conduit dans certains cas à des catégories avec très peu d'éléments. Exemple : Catégorie:Justice dans l'Égypte antique. Le but initial de permettre plusieurs accès à une donnée (ce qui devrait faciliter la recherche) conduit à une architecture moins lisible de la structure de la catégorisation. Une architecture simple avec une méthode adaptée peut s'avérer plus efficace. Il est important de bien définir le contenu des catégories et les relations d'appartenance. Tout comme il ne faut pas regarder les choses sous le spectre de la langue ou du pays. Néanmoins, on peut apprécier une certaine rigueur dans la catégorisation faite par   Mywiz (Bjr).
Quant au contenu de la présente arborescence consistant en deux pages uniquement : une palette {{Palette Mel Gosselin}} et un modèle {{Palette Écrivains québécois}} mal nommé puisqu'il ne correspond pas à une palette au sens éditorial de Wikipédia mais à un outil de navigation entre des pages de listes, à l'image d'un sommaire sur plusieurs pages ou de liens présents sur des pages de Chronologies ({{Chronologie littérature}}). À la limite, serait acceptable le titre « Palette Listes d'écrivains québécois par ordre alphabétique » la précision en petit étant facultative.
Autre point, personnellement, je sortirais Catégorie:Modèle littérature francophone de la catégorie:Littérature francophone cette dernière étant encyclopédique, la première, technique, et déjà accessible via Catégorie:Projet:Littérature francophone et via l'arborescence des modèles. Bref, pas fan de la nouvelle catégorisation. — Ideawipik (discuter) 27 juillet 2020 à 23:58 (CEST)
Hello Ideawipik  . Oui, je pense effectivement que dans certains cas, une catégorisation par langue/pays est utile (j'ai par exemple moi-même créé récemment la catégorie « Modèle transport par lieu » pour y rassembler les catégories par lieu déjà présentes, totalement justifiées lorsque l'on parle des transports d'une ville ou autre). Néanmoins, c'est plutôt la présence de cette catégorie à la racine, et donc en tant que catégorie maîtresse dans laquelle on doit essayer de caser la plupart des modèles, qui me chagrine... Comme tu le dis, cela risque d'exploser toutes les catégories thématiques existantes en sous-catégories pas forcément très fournies. D'autant plus que je ne vois pas vraiment ce que veut dire "par langue", car les modèles sont censés être en français... "Relatifs à une langue" me semblerait plus correct, à condition que la catégorie soit classée dans une arborescence liée à la linguistique (comme la catégorie « Modèle par pays » est située dans la catégorie « Modèle géographie »).
Bref, on est d'accord  
Wikipédiennement, Epok__ (Insultes, éloges, simples discussions : ), le 28 juillet 2020 à 10:05 (CEST)

Module:Biblio/RéférencesModifier

Bonjour. J'ai posté cette requête sur Discussion Projet:Scribunto#Module:Biblio/Références il y a deux semaines, mais pas de réponse. Donc je poste ici en espérant avoir plus de chance.

Sur le bistro du 29 juin j'ai fait une suggestion qui n'a pas reçu énormément de réponse, mais globalement des réponses positives. Il s'agit de modifier l'affichage des numéros de notice BNF, pour harmoniser avec tous les autres numéros (ISBN, OCLC, etc.) :

Avant Après
(notice BnF no FRBNF34063996) (BNF 34063996)

Je sais que ça se passe sur Module:Biblio/Références mais je n'ai ni les droits d'administrateurs pour intervenir sur cette page protégée, ni les compétences suffisantes pour dire exactement comment modifier pour obtenir l'effet voulu. Enfin je pense que ça consiste grosso modo en ça, mais je ne suis pas certain :

function References.bnf( bnf )
	bnf = Outils.trim( bnf )
	if bnf then
		local texte = ''
		local category = ''
		local bnfId = bnf:upper():match( 'BNF(%d+%w)' ) or
			bnf:lower():match( 'cb(%d+%w)' ) or
			bnf:match( '^%d+%w' )
		
		if bnfId then
			-- bnf contient une suite de chiffres qui peut être un ark valide
			local base = bnfId:sub( 1, 8 )
			local arkId = References.arkId( 'cb' .. base )
			if bnfId:len() == 8 then 
				-- il manque la clé, on l'ajoute
				bnf = base .. arkId
				texte = base
			elseif bnfId:len() > 8 and bnfId:sub( 9, 9 ) == arkId then
				-- ark valide
				bnf = bnfId:sub( 1, 9 )
				texte = base
			else
				-- ark qui semble non valide
				bnf = bnfId
				texte = bnfId
				category = '[[Catégorie:Recension temporaire pour le modèle Ouvrage|bnf]]'
			end
		else
			-- le paramètre ne semble pas un ark valide
			texte = bnf
			category = '[[Catégorie:Recension temporaire pour le modèle Ouvrage|bnf]]'
		end
		
		-- dans tous les cas on renvoie l'adresse, on catégorise juste pour vérifier ce qui ne va pas
		local lien = databaseExterne(
			bnf, 
			'[[Bibliothèque nationale de France|BNF]]', 
			'catalogue.bnf.fr/ark:/12148/cb', 
			'.public', 
			texte 
		)
		
		return lien .. category
	end
end

À vrai dire je ne sais même pas comment tester... Quelqu'un ayant des droits d'admin peut-il tester et faire la modification pour moi ? Ça serait sympa. Merci  . — Hr. Satz 16 juillet 2020 à 10:26 (CEST)

Revenir à la page « Modèle ».