Wiktionnaire:Gestion des modèles/2013

Bonjour, vous êtes venu ici pour chercher la signification du mot Wiktionnaire:Gestion des modèles/2013. Dans DICTIOUS, vous trouverez non seulement toutes les significations du dictionnaire pour le mot Wiktionnaire:Gestion des modèles/2013, mais vous apprendrez également son étymologie, ses caractéristiques et comment dire Wiktionnaire:Gestion des modèles/2013 au singulier et au pluriel. Tout ce que vous devez savoir sur le mot Wiktionnaire:Gestion des modèles/2013 est ici. La définition du mot Wiktionnaire:Gestion des modèles/2013 vous aidera à être plus précis et correct lorsque vous parlerez ou écrirez vos textes. Connaître la définition deWiktionnaire:Gestion des modèles/2013, ainsi que celles d'autres mots, enrichit votre vocabulaire et vous fournit des ressources linguistiques plus nombreuses et de meilleure qualité.

Gestion des modèles

N’oubliez pas de consulter les modèles existants :

Outils :

Wiktionnaire:Maintenance et nettoyage (C)
Gestion des catégories | Gestion des modèles | Pages à formater | Pages à fusionner | Questions techniques
Pages à supprimer rapidement | Pages proposées à la suppression | Pages proposées au renommage | Wikidémie


Harmonisation du paramètre 1

La plupart de nos modèles on pour {{{1}}} le code langue, sauf : {{région}}, {{dénominal}}… Je propose donc de modifier ces derniers pour que la langue soit toujours le {{{1}}}. JackPotte ($) 4 décembre 2012 à 11:18 (UTC)

Si tu veux changer l’ordre des paramètres, il sera meilleur de créer un nouveau modèle pour garder les pages dans l’historique. — TAKASUGI Shinji (d) 4 décembre 2012 à 13:59 (UTC)
Il y a aussi {{pron}}. JackPotte ($) 27 janvier 2013 à 18:53 (UTC)
Urhixidur voudrait que {{{1}}} puisse correspondre à nocat mais cela ne va pas dans le sens des observations précédentes. JackPotte ($) 11 mars 2013 à 20:17 (UTC)
Apparemment il n’y a pas tant de modèles qui font exception, mais ces modèles sont largement répandus sur les pages du Wiktionnaire. Est-ce que tu pourrais lister les avantages de replacer le paramètre de langue en premier ? S’il sont jugés par la suite supérieurs aux inconvénients, que penses-tu de la proposition de Shinji qui consiste à créer de nouveaux modèles pour lire les actuels dans l’historique ? Vu la politique du Wiktionnaire de ne jamais supprimer les modèles désuets il serait logique, pour rester cohérent, d’adopter cette proposition également, mais on peut toujours voir les choses autrement, bien sûr. — Automatik (discussion) 1 juin 2013 à 22:56 (UTC)
Je n’avais pas justifié ma proposition, mais l’idée était la simplicité. Comme nous l’avons vu encore récemment il y a un certain nombre de {{région|fr}} pour "régionalismes en français" sur le modèle des autres modèles régionaux ({{France}}…). Dans Catégorie:Modèles étymologiques rien ne permet de distinguer comment paramétrer les modèles sans lire toutes les docs. JackPotte ($) 2 juin 2013 à 09:28 (UTC)
Et pour la question de l’historique ? Automatik (discussion) 2 juin 2013 à 14:20 (UTC)
Autant empailler tous les animaux morts aux dépends de la fourrure. JackPotte ($) 2 juin 2013 à 15:11 (UTC)
0 résultat sur Google pour autant empailler tous les animaux morts aux dépens de la fourrure (et pourtant j’ai corrigé dépends en dépens). Je suppose que cela veut dire qu’on n’a pas à se préoccuper de ce problème ? Automatik (discussion) 2 juin 2013 à 15:41 (UTC)
On ne peut pas mettre systématiquement la langue en premier paramètre sans considération avec ce que fait le modèle. Le modèle {{région}}, par exemple, est générique, donc il faut d'abord préciser de quelle région on parle avant de préciser la langue (sachant qu'un modèle {{région}} sans région(s) précisées n'a pas d'intérêt). Par contre, {{France}} (qui, au passage, utilise le modèle {{région}}) est déjà défini, donc il n'y a besoin de préciser que la langue. Bref, si on a mis la langue en second, c'est qu'il y avait une bonne raison. Le seul modèle qui me semble illogique dans ce cas est {{trad}}. — Dakdada 2 juin 2013 à 15:49 (UTC)
Peut-être que {{lien}} est aussi dans le même cas de {{trad}} ? Automatik (discussion) 2 juin 2013 à 16:15 (UTC) {{lien}} est comme {{pron}} plutôt et pas comme {{trad}}. Je ne comprends pas pourquoi {{trad}} est illogique par contre ? Automatik (discussion) 2 juin 2013 à 18:37 (UTC)
Je suis totalement en désaccord avec Darkdadaah sur la priorité : nous ne publions aucune région qui n’appartienne à aucune langue, c’est le paramètre rédhibitoire. De plus tu ignores totalement les sept entrées de Catégorie:français régional ainsi que les nombreuses {{région|lang=fr}} trouvées et non catégorisées actuellement, ce qui constitue une problématique à régler. JackPotte ($) 2 juin 2013 à 16:47 (UTC)
@Automatik {{lien}} est le pendant de w:Modèle:lang qui prend la langue en premier. JackPotte ($) 2 juin 2013 à 16:49 (UTC)
On a {{Lang}} ici aussi sauf que j’ai fait confusion (mais je suppose que ta proposition concerne aussi {{lien}}, dont le premier paramètre n’est pas le code langue). Automatik (discussion) 2 juin 2013 à 18:37 (UTC)
JackPotte : ce modèle est inutile s'il n'y a aucune région donnée. Il est acceptable s'il n'y a pas de langue précisée, car il est quand même écrit dans l'article sur la ligne de définition. La seule chose que l'absence du paramètre langue empêche est la catégorisation (français régional ne fait que montrer qu'il y a des articles sans région précisée et qu'il faut les corriger... ce qui me donne d'ailleurs plutôt raison). La priorité est donc clairement à l'objet du modèle, non la langue, qui n'est qu'un ajout et n'est pas indispensable, dans l'absolu. Cela est généralisable à tous les modèles génériques qui n'ont pas pour seul paramètre une langue. Je reste sereinement sur ma position.
Automatik : logiquement parlant, {{trad}} devrait être écrit comme {{lien}} : le mot à lier en premier, la langue en second. — Dakdada 2 juin 2013 à 19:09 (UTC)
Et au nom de quoi les mots devraient se superposer à des régions qui ont un nom que l’éditeur doit cerner précisément ? Les frontières ne sont pas si simple. JackPotte ($) 2 juin 2013 à 19:33 (UTC)

Ce modèle est inutile : cette déclinaison est déjà prise en charge par Modèle:la-tab-1f. --Šojić | говорите 8 décembre 2012 à 14:33 (UTC)

Supprimer Supprimer --Diligent (discussion) 9 décembre 2012 à 09:45 (UTC)
Pas d’accord. Il reste la page Mithras où on ne peut pas substituer la-tab-1f à la-décl-nom-a. Avec Mithras le nominatif est incorrect après substitution. Si on arrange ça, on pourra supprimer la-décl-nom-a. Urhixidur (discussion) 8 février 2013 à 17:54 (UTC)
  1. fait Mithras --Diligent (discussion) 11 mai 2013 à 08:14 (UTC)

mod

Il me semble que MediaWiki a changé la fonction de mod aujourd’hui. Maintenant le résultat n’est pas tronqué en entier :

  • {{#expr: 3.2 mod 2}} → 1

Modifiez des modèles utilisant floor si nécessaire.

  • {{#expr: floor (3.2 mod 2)}} → 1

TAKASUGI Shinji (d) 17 décembre 2012 à 16:07 (UTC)

Je ne connaissais aucun modèle qui utilise ce mot d’abord, mais je comprends que s’ils sont prévus pour l’arrondir à l’inférieur, l’ajout de floor devienne notre peine plancher Mort de rire. JackPotte ($) 17 décembre 2012 à 20:43 (UTC)
J’ai trouvé ce changement hier parce que {{hangeul unicode}} ne marchait pas bien, qui utilise mod dans le sous-modèle {{hexadécimal}}. — TAKASUGI Shinji (d) 18 décembre 2012 à 02:12 (UTC)
Maintenant le résultat est tronqué en entier. — TAKASUGI Shinji (d) 28 janvier 2013 à 02:14 (UTC)

Apparemment tes deux exemples ci-dessus donnent le même résultat (à l’heure actuelle) : il y a des chances que cela a été rechangé ? Automatik (discussion) 7 juillet 2013 à 19:56 (UTC)

Requête : créer les modèles pour la langue Lojban

Bonjour, La liste WT:Liste_de_tous_les_modèles/Par_langue ne fournit pas encore les modèles pour la langue lojban. En lojban il n'y a pas de nom, ni de verbe, ni d'adjectif. À la place il faudrait créer les catégories suivantes : gismu, cmene, etc. Vous trouverez la liste complète des types de mots lojban à créer dans le wiktionary anglais. Merci d'avance. BluePrawn (discussion) 27 janvier 2013 à 16:22 (UTC)

Je peux importer ceux d’un autre Wiktionary, mais tu as déjà très bien commencé tout seul : {{-gismu-}}, {{-cmene-}}... JackPotte ($) 30 janvier 2013 à 19:59 (UTC)
J’ai mis aux normes {{-gismu-}} et {{jbo-gismu}} (→ voir gerku), et créé {{-rafsi-}}. Je ne suis pas assez sûr de l’orthographe des autres mots, trop peu recensés en français par Google. — Automatik (discussion) 2 décembre 2013 à 20:17 (UTC)

C’est une tentative de remplacement de {{colonnes}} pour la page Annexe:Pays_et_leurs_gentilés_en_français (voir la section S) qui permette d’une part de garder le nom du pays et le gentilé côte-à-côte mais aussi d’autre part de garder les lignes des colonnes mutuellement alignées (à cause des renvois en exposant). Mais ça me semble lourd, et je pense qu’on va frapper la limite du nombre d’appels de modèles avec cette approche. Quelqu’un a une meilleure idée ? Urhixidur (discussion) 8 février 2013 à 17:48 (UTC)

Bandeaux de protolangues

Bonjour ou bonsoir,

Il existe un modèle pour les bandeaux de protolangues, {{forme reconstituée}}, prenant la langue en paramètre, mais en parallèle il existe aussi des modèles uniques pour ces langues, ne nécessitant pas de paramètre - voir Catégorie:Bandeau de protolangue.

Du coup, je voudrais vous demander : faut-il préférer une des deux solutions ? Un seul modèle nécessitant de connaître son nom et de mettre un paramètre vs un modèle par protolangue nécessitant juste de connaître le nom de la protolangue.

Peut-être aussi serait-il pertinent de renommer le modèle unique en {{forme reconstruite}}, comme le propose Eölen (d · c · b) selon qui ce second terme est plus courant en linguistique.

Merci d’avance pour vos réponses, Automatik (discussion) 5 février 2013 à 21:46 (UTC)

Initialement, j’avais créé {{forme reconstituée}} afin de n’avoir qu’un seul modèle à utiliser. Si on décide d’utiliser {{forme reconstituée}} alors les autres modèles ({{proto-germanique}}, {{proto-wintuan}}, …) n’ont plus de raison d’être. On devrait tous les remplacer par {{forme reconstituée}} avec le paramètre qui correspond. Et puis oui, on en profite pour renommer en {{forme reconstruite}}. Pamputt 5 février 2013 à 21:52 (UTC)
Il me semble que le modèle à paramètre est plus économique, il n’y a pas des centaines de protolangues et les contributions ne sont pas non plus faites par des milliers de personnes. De plus, je trouve que le nom des modèles actuels, comme {{proto-germanique}} entraine une confusion avec le modèle de la langue. Mais d’autres avis sont les bienvenus. Eölen (discuter) 6 février 2013 à 12:29 (UTC)
La remarque d’Eölen me fait repenser à quelque chose. Les modèles du style {{proto-germanique}} devrait en effet concerner les modèles de nom de langue. Il a en effet été convenu (par moi ?) qu’il était plus facile et plus lisible d’utiliser les noms de langues en entier lorsque le SIL ne donne pas de code ISO (exemple avec {{patwin du Sud}}). Du coup, {{proto-germanique}} devrait remplacer l’« incompréhensible » {{proto:gem-pro}}, etc. Mais cela suppose qu’on accepte d’utiliser {{forme reconstruite}}. Pamputt 6 février 2013 à 17:08 (UTC)
Tout à fait. C’est exactement là où je voulais en venir ! Eölen (discuter) 6 février 2013 à 23:57 (UTC)
Super. Vu qu'on semble tous les 3 d’accord, je vais remodeler un petit peu Wiktionnaire:Prise de décision/Code pour les proto-langues et lancer le vote dans le foulée. Si c’est accepté, il faudra qu’un bot fasse tous les changements nécessaires. Pamputt 9 février 2013 à 19:12 (UTC)
OK. À noter que des pages comme en:Wiktionary:About Proto-Indo-European seraient très pertinentes : elles permettraient de changer les simples liens du type proto-germanique en un renvoi vers l’annexe décrivant les aspects théoriques de la protolangue. Automatik (discussion) 9 février 2013 à 20:49 (UTC)

Salut,

Le modèle {{R:JO}} utilisant un lien mort, je propose que soit utilisé à la place {{R:FranceTerme}} qui crée également un lien donnant des définitions du Journal Officiel (c'était le but de R:Jo).

Cependant le modèle {{R:FranceTerme}} n'est pas très pratique : si le titre est composé de plusieurs mots, il faut le réécrire en paramètre avec des « nbsp; » entre chaque mot. Je propose donc que le code du modèle {{R:FranceTerme}} soit changé en : celui-ci. Ce nouveau code gère automatiquement les espaces.

L'inconvénient que je n'ai pas su corrigé, c'est le cas des apostrophes : il faudra toujours réécrire le titre de la page en paramètre avec une apostrophe droite lorsqu'il contient une apostrophe courbe. En effet, FranceTerme utilise les apostrophes droites exclusivement.

Aussi, le modèle {{R:JO-term2000}} n'est qu'à moitié fonctionnel : il pointe vers cette page de FranceTerme : il faut retaper le mot à la main pour avoir le résultat de la requête. Ce n'est pas possible de modifier le modèle pour ne pas avoir besoin de retaper le mot à la main sur ce même site. En effet, le contenu de la boite de recherche n'est pas reporté dans l'url, mais donne automatiquement le résultat sous le même url quel que soit la requête ; l'url est générique pour toutes les requêtes.
Je propose donc également le remplacement de ce modèle par le modèle {{R:FranceTerme}} revu. Ce dernier modèle pointant vers un site « consacré aux termes recommandés au Journal officiel de la République française ».

J'ai testé une dizaine de liens pour chaque modèle à remplacer, ils marchent tous avec le nouveau {{R:FranceTerme}} ; de plus le site vers lequel pointe {{R:FranceTerme}} propose les mêmes définitions que celui vers lequel pointe {{R:JO-term2000}}. Exemple : FranceTerme, Délégation générale à la langue française et aux langues de France (vérification de la conformité aux règles d'interconnexion) vs Journal officiel de la République française, du 22 septembre 2000, Répertoire terminologique 2000 (une fois sur la page, retaper le mot : les informations données semblent être strictement les mêmes).

PS : Si jamais cette proposition est acceptée, je pourrai m'en occuper par AWB dans un délai d'une semaine environ, en différenciant les cas apostrophe courbe/droite. Cela dit pour traiter ces derniers cas, je sais soit : faire les choses à la main en utilisant AWB juste pour passer rapidement d'une page à une autre ; soit le faire de façon + automatisée, mais en deux passages. La question ne se pose plus si un dresseur de bot s'en occupe avant moi bien évidemment.

Merci pour vos réactions et suggestions ! Sourire Automatik (discussion) 20 février 2013 à 12:58 (UTC)

Lu et approuvé. JackPotte ($) 20 février 2013 à 22:37 (UTC)

Je n’ai pas oublié cette proposition, je pense à faire un modèle en lua dès que je serai plus libre. Automatik (discussion) 6 mai 2013 à 16:24 (UTC)

Le module en Lua ayant été créé (Module:FranceTerme), le modèle peut remplacer les deux autres modèles obsolètes qui pointent vers un site qui a migré son contenu. Automatik (discussion) 11 août 2013 à 15:37 (UTC)
fait Fait. Les pages incluant les modèles {{R:JO}} et {{R:JO-term2000}} ont été modifiées. Automatik (discussion) 13 août 2013 à 02:40 (UTC)

Modification de {{fr-conj-1}}

Je propose de modifier {{fr-conj-1}} légèrement pour accepter un cas de figure fréquent, sans pour autant ajouter de paramètre. En ce moment, le paramètre e permet de faire disparaître le 'e' de certaines finales (futur simple, par ex.) lorsqu’il n’est pas prononcé (par ex., crier). Dans bon nombre de cas, cependant, la prononciation de ce 'e' peut se faire ou non, selon le choix du locuteur et du niveau de langage (élocution soignée ou scandée vs. parler rapide familier, par ex.). Si je prends l’exemple de boiser, au futur simple on a je boiserai, /ʒə bwɑ.zə.ʁe/ ou /ʒə bwɑ.zʁe/.

Je propose de modifier certaines lignes, comme celle-ci :

ind.f.1s.pron={{#if:{{{p.futur|{{{2|{{{pron|}}}}}}{{{p.v2|{{{p.v1|}}}}}}{{{3|{{{pc|}}}}}}}}}|<!--

 -->{{{3|{{{pc|}}}}}}{{#if:{{{e|}}}<!--e NON prononcé -->||ə}}.<!--
 -->ʁe<!--

en :

ind.f.1s.pron={{#if:{{{p.futur|{{{2|{{{pron|}}}}}}{{{p.v2|{{{p.v1|}}}}}}{{{3|{{{pc|}}}}}}}}}|<!--

 -->{{{3|{{{pc|}}}}}}{{#if:{{{e|}}}<!--e NON prononcé -->|{{#ifeq:{{{e|}}}|parfois|(ə.)|.}}|ə.}}<!--
 -->ʁe<!--

ou encore, de façon équivalente mais plus lisible :

ind.f.1s.pron={{#if:{{{p.futur|{{{2|{{{pron|}}}}}}{{{p.v2|{{{p.v1|}}}}}}{{{3|{{{pc|}}}}}}}}}|<!--

 -->{{{3|{{{pc|}}}}}}{{#switch:{{{e|}}}|=ə.|parfois=(ə.)|.}}<!--
 -->ʁe<!--

De cette façon, si on a e=parfois le rendu deviendra /ʒə bwɑ.z(ə.)ʁe/. Les verbes utilisant e=non ou qui n’invoquent pas ce paramètre ne seront pas affectés. Les lignes visées sont ind.f.*.pron et cond.p.*.pron.

Commentaires ? Urhixidur (discussion) 1 mars 2013 à 15:36 (UTC)

Moi ça me va.
À terme, il est probable qu’on convertira ces modèles en lua. --GaAs 1 mars 2013 à 15:43 (UTC)
Je ne m'occupe plus de chercher à améliorer les modèles complexes, je préfère préparer leur migration vers Lua. Il serait plus intéressant de préparer une liste des différents cas de figure à faire gérer au modèle réécrit. — Dakdada 1 mars 2013 à 15:47 (UTC)
Pour info, il avait déjà été question de changer la prononciation de l'API dans cette section de la Wikidémie de janvier 2013 : liaison dans les temps composés. Utiliser le raccourci clavier Ctrl+F pour retrouver le texte /ʒ‿a.vɛ.(z‿)ak.ti.ve/ , puis lire ce qui suit. On peut voir en effet que les symboles en API ne permettent pas d'indiquer facilement une alternative, et selon l'Aide sur les prononciations : « la norme API n’a pas de syntaxe pour indiquer un son optionnel (l’emploi des parenthèses notamment est réservé pour une autre utilisation) ; ». Cordialement, Automatik (discussion) 11 mars 2013 à 21:07 (UTC)

Non, il ne faut surtout rien changer, ce paramètre ne sert pas à ça (et c'est expliqué à la fin de la documentation, qui est cachée, on se demande pourquoi). Le paramètre est utile uniquement pour des verbes comme crier, dont le radical (ce qui précède la finale -er) finit par une voyelle. Ce n'est pas le cas de boiser. On ne prononce jamais le e dans je crierai, même en poésie. Lmaltier (discussion) 11 mars 2013 à 21:35 (UTC)

Lmaltier, tu n’as pas compris la proposition. Je proposais un changement qui n’aurait eu d’effet que si le paramètre e était instruit en parfois. Ce que nous n’aurions évidemment pas fait pour crier, par exemple. Le nouveau comportement aurait été un super-ensemble de l’ancien, donc parfaitement patrimonial. Urhixidur (discussion) 19 avril 2013 à 12:12 (UTC)

Problème {{-nom-fam-}}, {{-nom-pr-}}

Regardez à Tremblay : la table des matières ne montre que le nom de famille (dans la section française). Puisque {{-nom-fam-}} et {{-nom-pr-}} sont tous deux des applications de {{-déf-}}, le problème doit être là. J’ai fait une ou deux corrections à {{-déf-}} mais le problème semble toujours présent (difficile d’être certain avec les délais de propagation du changement). Il semble que la présence du param num instruit empêche la production de la balise <span class="mw-headline" id="Nom_…">, ce qui entraîne le symptôme visible. On peut le constater en prévisualisant la page Tremblay après avoir supprimé le |num=1 du premier {{-nom-pr-}}. Quelqu’un de plus féru en HTML que moi doit se pencher là-dessus. Urhixidur (discussion) 27 mars 2013 à 18:02 (UTC)

Une des raisons est qu'on crée directement un h3 via le modèle, donc c'est un peu normal qu'on ait des comportements imprévisibles comme ça. Le problème ne se posera plus quand on aura remplacé les modèles de section, mais pour l'heure il faudrait corriger les modèles. NB : merci de ne pas retoucher les modèles trop souvent, mieux vaut tester un modèle différent ailleurs que de toucher tous les articles en tâtonnant. — Dakdada 27 mars 2013 à 19:08 (UTC)
Voilà, c'était un pipe manquant (il fallait le trouver). Commentaires : au final modifier modèle:-déf- n'aura rien changé (j'espère) ; il faut éviter au maximum de retoucher ce genre de modèle, surtout sans test. L'origine du problème : , et sa résolution : .
Je pense sincèrement qu'il faudrait un système d'aval afin que toute modification de modèle/module important, aussi bénigne soit-elle, quand bien même elle est faite par un contributeur chevronné, soit vérifiée et acceptée par au moins une autre personne. — Dakdada 27 mars 2013 à 19:41 (UTC)
Pour ce qui est du problème et de sa résolution, il semble que la cause ait été le retour de chariot à la fin de l’argument 1. Donc on aurait pu arranger ça avec un commentaire autour du retour de chariot tout autant qu’en déplaçant la barre verticale, comme ci-dessous ? Urhixidur (discussion) 3 avril 2013 à 20:18 (UTC)
{{-déf-|Nom propre|
 type=Noms propres
|code=nom-pr
{{-déf-|Nom propre<!--
-->|type=Noms propres
|code=nom-pr
Oui, c’est possible, mais il y a une plus belle façon :
{{-déf-
|1=Nom propre
|type=Noms propres
|code=nom-pr
TAKASUGI Shinji (d) 19 avril 2013 à 10:58 (UTC)
Vraiment, passer d’un paramètre anonyme à un numéroté aurait aussi réglé le problème ? Urhixidur (discussion) 19 avril 2013 à 12:07 (UTC)
Les espaces ne sont pas nettoyés par MediaWiki pour les paramètres anonymes alors que pour les paramètres nommés ils le sont (si c’est bien ça dont il est question). (Information tirée d’ici) — Automatik (discussion) 19 avril 2013 à 12:28 (UTC)

Comment bien nommer {{accord genre ?}}

En fait je ne sais pas comment nommer {{accord genre ?}} parce que la différentiation {{genre ?}} / {{genre}} serait confuse et l’actuel et les précédents {{mf-m ?}} / {{accord ?}} ne me conviennent pas non plus. Les mots concernés seraient ceux du genre insti et instit classé masculin et féminin identiques alors que certaines personnes font l’accord et que ça ne semble par être fautif de le faire (une instie, une instite), bref si vous avez une meilleure idée je suis preneuse.

Une note ferait peut-être l’affaire en précisant l’orthographe alternative au féminin (une note d’usage avec {{usage}} éventuellement), car « masculin et féminin identiques ou masculin » ne me paraît pas très claire. Automatik (discussion) 19 avril 2013 à 12:34 (UTC)

Bonjour,

Après étude de ces modèles, j’ai pu constater que certains paramètres étaient nommés étrangement. Je propose de les renommer conformément à leur comportement.

Que pensez-vous ? Doit-on effectuer ces changements de nommage des paramètres ?

Je ne serais pas contre une suppression des paramètres de références, qui alourdissent la documentation et ne sont de toute façon utilisés nulle part, sur plus de 10 000 utilisations.

En vous remerciant d’avance pour votre avis, Automatik (discussion) 18 avril 2013 à 14:38 (UTC)

Je suis plutôt pour si tu peux le faire de façon autonome. JackPotte ($) 18 avril 2013 à 20:13 (UTC)
Oui, je peux. Je voulais simplement être sûr de l’absence d’objection. Je vais prévenir les auteurs des modèles. En l’absence d’opposition, j’agirai ensuite. Automatik (discussion) 18 avril 2013 à 21:05 (UTC)
Pour Pour J’ai d’abord pensé que les paramètres de références devraient être gardés, mais si on les supprime de tous les modèles alors on peut s’en tirer néanmoins en donnant ces références dans la section -pron- (qui répéterait les différentes variantes). Urhixidur (discussion) 19 avril 2013 à 12:04 (UTC)
Pour Pour Cette simplification des modèles me paraît des plus raisonnable. Donc : pas d'objection.Gilles MAIRET (discussion) 23 avril 2013 à 01:43 (UTC)
Pour Pour. J’ai rarement utilisé tout ça, mais les nouveaux intitulés me semblent bien plus clairs Sourire Eölen 23 avril 2013 à 09:48 (UTC)
Pour Pour --GaAs 25 avril 2013 à 20:44 (UTC)
Pour Pour Pas de soucis. V!v£ l@ Rosière /Murmurer…/ 8 mai 2013 à 04:40 (UTC)
Ajout à la proposition

Après parcours des entrées, j’ai pu remarquer que le paramètre s2 n’était jamais utilisé ; il sert à indiquer une seconde graphie pour un mot invariable, probablement donc une variante orthographique. Cette info aurait sa place sous {{-var-ortho-}} à priori. Pour cette raison je propose aussi la suppression du paramètre s2 et de ceux qui lui sont affiliés (pas utilisés non plus). Si tout le monde est d’accord, ça permettra de simplifier le wikicode et de simplifier la documentation, dans laquelle abondent des paramètres inusités. Automatik (discussion) 5 mai 2013 à 18:46 (UTC)

Pour Pour aussi Sourire Eölen 5 mai 2013 à 20:08 (UTC)
Pour Pour Certes. Urhixidur (discussion) 6 mai 2013 à 16:17 (UTC)
Pour Pour Pas d'objection. Stephane8888 6 mai 2013 à 18:50 (UTC)
Pour Pour Idem. V!v£ l@ Rosière /Murmurer…/ 8 mai 2013 à 04:40 (UTC)

fait Modèles et documentations simplifiés. Automatik (discussion) 28 mai 2013 à 01:53 (UTC)

Modèle:-prés-

Pour signaler que l’Utilisateur:Sterlka a créé un nouveau modèle de troisième niveau pour le type de mot présentatif. Je ne suis pas sûr d’en voir toutes les répercussions (je pense aux bots en particulier). Il y a déjà les pages d’aides et de recensement de modèles à mettre à jour. What else ? — Unsui Discuter 25 avril 2013 à 20:35 (UTC)

Il n’y a que les admins qui devraient avoir le droit de créer un modèle. D’ailleurs, puisqu’il n’y a que les admins qui ont le droit de modifier les modèles existants, je me demande comment ils ont pu ne pas trouver le moyen d’interdire la création de nouveaux. --GaAs 25 avril 2013 à 20:43 (UTC)
Pour ce type de modèle, je suis d’accord avec toi. — Unsui Discuter 25 avril 2013 à 20:55 (UTC)
La prise de décision sur la protection des pages les plus utilisées est toujours valable, surtout que la dernière fois que nous l’avons adouci ce qui devait arriver arriva. JackPotte ($) 25 avril 2013 à 21:31 (UTC)

Nous sommes en train de parler de ce modèle dans Wiktionnaire:Wikidémie/avril 2013#-prés-. — TAKASUGI Shinji (d) 28 avril 2013 à 07:25 (UTC)

{{préfixe}} et {{suffixe}}

Sur la base de en:Template:prefix, en:Template:suffix créer un modèle pour remplacer {{composé de}}

Le modèle anglais catégorise, ce qui permet de peupler facilement et précisément des catégories comme Catégorie:Mots français préfixés avec scléro-, Catégorie:Mots en français suffixés avec -able (très vide et actuellement fausse : inexpulsable = in-expulsable et non inexpulser-able)

--Diligent (discussion) 11 mai 2013 à 08:21 (UTC)

Aucune objection. Nous pourrions aussi les intégrer comme paramètres : {{composé de|préfixe=}}. JackPotte ($) 11 mai 2013 à 10:26 (UTC)
Ça serait intéressant de catégoriser ainsi, mais pour le rajouter à {{composé de}}, ça compliquerait encore la syntaxe, et je ne suis pas sûr que ça vaut le coup, àmha. Automatik (discussion) 11 mai 2013 à 21:47 (UTC)
Tu penses sérieusement que l’on compliquerait encore la syntaxe en passant de :
  • {{cf|é-|gosier|-iller}}
à
  • {{composé de|p=é-|gosier|s=-iller}}
au lieu de
  • {{préfixe|é-}}, radical '']'' et {{suffixe|-iller}}
? JackPotte ($) 11 mai 2013 à 22:36 (UTC)
En fait je pense que {{composé de}} est tellement compliqué pour les nouveaux contributeurs que rajouter un paramètre ne changera en fait pas grand chose ; il restera obscur. J’ai l’impression toutefois que ces deux nouveaux modèles permettraient d’éliminer {{composé de}}, en tout cas ce serait bien pour les nouveaux, car {{préfixe}} et {{suffixe}} sont très clairs. Est-ce que ces modèles permettraient de détecter les formants comme tu le voulais — si je ne me trompe pas —, ou alors ils ne sont pas assez puissants pour remplacer {{composé de}} ? Automatik (discussion) 11 mai 2013 à 23:17 (UTC)
  • Du radical de '']'' avec préfixe {{préfixe|é-|fr}} et suffixe {{suffixe|-iller|fr}}.
La catégorisation par langue ne se fait pas toute seule semble-t-il, il faut écrire : {{préfixe|é-|fr}} ? Exemple de syntaxe sur en.wikt : {{suffix|kohdentaa|minen|lang=fi}} Stephane8888 11 mai 2013 à 23:04 (UTC)
Le modèle composé de permet de mettre automatiquement en lien et en italique pas seulement les préfixe et suffixe mais également le(s) radical(aux). Et ce, sous une forme rédigée.-- Béotien lambda 12 mai 2013 à 05:46 (UTC)
Je préfère la nouvelle solution proposée par Dilligent composé de est comme étyl, une aberration. V!v£ l@ Rosière /Murmurer…/ 12 mai 2013 à 06:38 (UTC)

Bonjour,

Actuellement, pour générer l’en-tête d’un thésaurus comme Thésaurus:cheval/français, il faut marquer {{en-tête thésaurus|cheval|fr}}. Les informations ajoutées ici en paramètres sont déjà présentes dans le titre. Elles sont donc récupérables (par le modèle) à partir des mots magiques adéquats. Comme la plupart des paramètres renseignés sont une reprise exacte des éléments du titre, je propose de laisser le modèle gérer cela automatiquement. C’est-à-dire permettre d’écrire {{en-tête thésaurus}} pour la page Thésaurus:cheval/français, pour le même résultat qu’actuellement. Il serait toujours possible de personnaliser l’en-tête en choisissant un nom différent que le titre en premier paramètre, comme c’est fait actuellement.

Est-ce que ça va à tout le monde ? Voyez-vous quelque chose que j’ai oublié ?

Cordialement, Automatik (discussion) 13 mai 2013 à 17:47 (UTC)

Pourquoi pas. JackPotte ($) 13 mai 2013 à 18:55 (UTC)
Pas d’objection non plus. V!v£ l@ Rosière /Murmurer…/ 14 mai 2013 à 10:38 (UTC)
Il y a encore quelques jours, nous pouvions mettre « corbeau (oiseau) » comme paramètre à ce modèle, mais depuis qu’il y a un lien {{{]}}} vers l’article, on est obligé de prendre le PAGENAME. Alors oui pourquoi pas. Stephane8888 14 mai 2013 à 11:15 (UTC)
Dans thésaurus:branche d’arbre/français, le paramètre 1 est branche et le lien fonctionne, c’est donc possible de ne pas choisir PAGENAME. On peut aussi écrire du lua pour faire en sorte qu’une précision entre parenthèses ne fasse pas partie du lien. J’ai trouvé quelque chose pour cela, mais ce n’est pas très propre au niveau codage. Si c’est utile cela dit, on peut quand même le mettre. Automatik (discussion) 14 mai 2013 à 18:04 (UTC)
Bien vu ! c’est inutile dans la mesure où le nom de la page apporte déjà la précision. Et du coup, je pense qu’il est pertinent de remplacer Thésaurus:corbeau/français --> Thésaurus:corbeau (oiseau)/français. Car c’est utile, par exemple, dans la section {{-voc-}} de l’article corbeau. Stephane8888 15 mai 2013 à 18:36 (UTC)
Pour "corbeau" ce n’est peut être pas nécessaire. Stephane8888 15 mai 2013 à 21:22 (UTC)

fait, j’ai simplifié ; si on veut inclure des cas spéciaux comme des parenthèses qui ne font pas partie du lien, il suffit de le signaler, on pourra envisager ça. Automatik (discussion) 27 mai 2013 à 22:06 (UTC)

Bonjour,

Ce modèle permettant de créer des liens pour chaque lettre de l’alphabet dans les tables de matière comme {{CatégorieTDMDévanâgarî}} renvoie en haut de la page au lieu de renvoyer directement au niveau des entrées . Cela présente-t-il un inconvénient que l’on fasse comme {{tdmin}} le fait, c.-à-d. en pointant directement vers la liste des pages ? Automatik (discussion) 19 mai 2013 à 02:14 (UTC)

Non, vas-y. JackPotte ($) 19 mai 2013 à 10:08 (UTC)
La modif. étant mineure, je l’ai faite, mais n’hésitez pas à révoquer si elle pose problème. Automatik (discussion) 19 mai 2013 à 14:01 (UTC)

Bonjour,

Que faire des modèles qui utilisent des paramètres obsolètes (qui impliquent l’utilisation de modèles supprimés) et qui sont aujourd'hui inusités ? Ils ne sont plus lisibles dans les historiques si les modèles qu’ils utilisaient au départ sont supprimés aujourd'hui.

Aujourd’hui, si on visualise un historique qui utilise {{mots issus de|fr}}, cela rendrait :

Cette catégorie liste les mots et locutions issus {{{{{fr}}}|type=du nom}}. Voyez Aide:Étymologies pour plus d’informations.

Cela dit, le modèle a normalement été substitué. Du coup, que faire de ce modèle ?

  1. Le supprimer ?
  2. Recréer les modèles supprimés pour qu’on puisse le lire dans les historiques ?
  3. Chercher dans l’historique des modèles supprimés le code utilisé par ce modèle pour l’intégrer au modèle actuel afin de pouvoir lire les historiques ?

En vous remerciant par avance pour votre avis, Automatik (discussion) 24 mai 2013 à 11:57 (UTC)

Les historiques sont déjà peu lisibles en lecture, le mode modification ou les diff pourraient suffire si on n’éprouve pas le besoin de faire le trajet en première classe. JackPotte ($) 26 mai 2013 à 18:22 (UTC)
Merci d’avoir répondu, cela dit, j’avoue ne pas savoir pour quelle option tu penches exactement. Cordialement, Automatik (discussion) 26 mai 2013 à 19:37 (UTC)
Pour ça. JackPotte ($) 26 mai 2013 à 21:31 (UTC)
Ok, ça marche, super Sourire Automatik (discussion) 26 mai 2013 à 21:32 (UTC)

Modèle:lutherie

Bonjour Je cherchais ce modèle pour compléter un article, et ne l’ai pas trouvé. Comme il existe bien plus de cinquante mots dans ce domaine, est-ce que ce pourrait être utile?

D’avance merci pour vos remarques.--JFD63 (discussion) 18 juin 2013 à 08:09 (UTC)

Proposition probablement inutile, j’ai trouvé ceci: (Lutherie) qui semble correspondre à ce que je cherchais. Par contre, je ne sais pas où se cachent ces formes de catégorisation.--JFD63 (discussion) 18 juin 2013 à 08:27 (UTC)
En fait le modèle {{term}} sert à faire apparaitre le lexique employé sur la ligne de définition justement quand il n’y a pas de modèle catégorisant spécifique. Le Modèle:lutherie n’existait pas mais je l’ai créé avec sa documentation pour pouvoir bien l’utiliser, ainsi que la catégorie française affiliée. V!v£ l@ Rosière /Murmurer…/ 18 juin 2013 à 09:16 (UTC)
J’ai commencé à remplir la page, mais ça prend du temps. Je continuerai ultérieurement. Merci à toi! En plus ça me permet d’améliorer ma connaissance du Wiktionnaire.

Fusionner ? Je ne suis pas certain qu'il faille les utiliser tout court, mais en attendant mieux vaut les regrouper. — Dakdada 19 juin 2013 à 20:45 (UTC)

Pour Pour À priori les articles concernés pourraient se voit taxer d’un {{créer-séparément}} conformément aux normes du Wiktionnaire qui veut qu’on crée les locutions à part. Leur suppression me paraît donc justifiée à terme, et leur regroupement en attendant ne me poserait nullement problème, puisqu’ils me semblent désigner la même chose (même si expression est réellement plus large, je ne vois pas qu’on puisse l’utiliser pour dire autre chose qu’« idiotisme » ici). Automatik (discussion) 19 juin 2013 à 21:03 (UTC)
Pour mémoire {{idiotisme}} avait été conservé il y a deux ans, mais c’est étrange qu’il ne catégorise pas. Par ailleurs, qui pourrait expliquer simplement dans les docs la différence entre Catégorie:Expressions en français et Catégorie:Locutions en français pendant qu’on y est ? JackPotte ($) 19 juin 2013 à 22:46 (UTC)
Pour Pour Également. Expressions et locutions même si je vois la différence dans le contenu des catégories je n’arriverais pas à l’expliquer sans que le tout soit extrêmement confus. V!v£ l@ Rosière /Murmurer…/ 20 juin 2013 à 06:34 (UTC)

Je voudrais modifier ce modèle pour ajouter un paramètre qui, lorsqu’instruit, ferait en sorte que le séparateur de la partie invariable (paramètre inv) soit un trait d’union au lieu d’une espace. Ce paramètre serait ajouté aux autres modèles qui s’en remettent à celui-ci de façon à ce qu’ils le transmettent. Ça permettrait de simplifier l’écriture de tableaux comme celui de Andréen-de-l’Est. Urhixidur (discussion) 22 juin 2013 à 16:46 (UTC)

Je préférerais qu'on utilise le modèle de base {{fr-accord-mixte}}, plutôt de faire des contorsions de paramètres :
fr-accord-comp fr-accord-mixte
{{fr-accord-comp
|Andréen|de-l’Est|ɑ̃.dʁe.ɛ̃|də.l‿ɛst
|f1=Andréenne
|pf1=ɑ̃.dʁe.ɛn
|f2=de-l’Est
|mp2=de-l’Est
|fp2=de-l’Est
}}
{{fr-accord-mixte
|ms=Andréen-de-l’Est
|mp=Andréens-de-l’Est
|fs=Andréenne-de-l’Est
|fp=Andréennes-de-l’Est
|pm=ɑ̃.dʁe.ɛ̃.də.l‿ɛst
|pf=ɑ̃.dʁe.ɛn.də.l‿ɛst
}}
Ça me paraît plus simple. Ça donnerait quoi avec {{fr-accord-mixte-rég}} et ce nouveau paramètre ? — Dakdada 22 juin 2013 à 17:32 (UTC)
Quelque chose comme :
{{fr-accord-en
|ms=Andréen
|ɑ̃.dʁe.
|inv=de-l’Est
|pinv=.də.l‿ɛst
|trait=oui}}
Singulier Pluriel
Masculin Andréen-de-l’Est
\ɑ̃.dʁe.ɛ̃\
Andréens-de-l’Est
\ɑ̃.dʁe.ɛ̃\
Féminin Andréenne-de-l’Est
\ɑ̃.dʁe.ɛn\
Andréennes-de-l’Est
\ɑ̃.dʁe.ɛn\
Urhixidur (discussion) 22 juin 2013 à 18:16 (UTC)

Bonjour,

Ce modèle, utilisé 28 fois, fait doublon àmha avec {{ironique}} (utilisé 498 fois) car ironique renvoie par le lien (Ironique) vers le glossaire grammatical qui explique que le terme taxé de ce qualificatif est utilisé par dérision.

Que pensez-vous de rediriger {{par dérision}} vers {{ironique}} histoire de simplifier la vie des nouveaux contributeurs pour les modèles à apprendre ? Automatik (discussion) 24 juin 2013 à 17:57 (UTC)

OK pour moi. JackPotte ($) 24 juin 2013 à 19:25 (UTC)
Je serais plutôt d’avis de l’éradiquer par substitution. Urhixidur (discussion) 28 juin 2013 à 02:42 (UTC)

Les deux ne me semblent pas synonymes : on peut être ironique sans faire preuve de dérision, et tourner en dérision sans être ironique. Lmaltier (discussion) 28 juin 2013 à 06:03 (UTC)

Pareil que Urhixidur. J’ai vérifié les inclusions et toutes (les françaises du moins) peuvent être remplacer par le modèle {ironique}. V!v£ l@ Rosière /Murmurer…/ 29 juin 2013 à 09:51 (UTC)

Bonjour,

J’ai demandé en février le changement de forme du texte de ce modèle afin de l’aligner sur celui de {{thésaurus}} et {{annexe}}, ce dont je suis très content. Je voudrais demander aujourd’hui si il serait possible d’ajouter un paramètre facultatif permettant de ne pas commencer le texte par une majuscule, ce qui parfois peut s’avérer gênant. J’envisageais de faire deux modèles différents {{catégorie}} et {{Catégorie}} mais ça me semble mal venu. Par ailleurs, je ne comprend pas bien la syntaxe utilisée et si c’est possible, j’aimerais bien que quelqu’un s’en charge pour moi. Je veux bien écrire la doc ensuite. Merci d’avance Sourire Eölen 4 juillet 2013 à 15:12 (UTC)

Tu veux dire ajouter un paramètre pour que le "L" de "La catégorie" devienne "l", comme {{{m|}}} dans {{apocope}} ? JackPotte ($) 4 juillet 2013 à 18:11 (UTC)
Exactement. Et je m’excuse mais je ne comprends absolument pas le code utilisé pour apocope et n’ai pas particulièrement envie d’apprendre le code en ce moment. Pourrais-tu voir pour modifier {{catégorie}}, s'il te plais Sourire Eölen 5 juillet 2013 à 23:21 (UTC)
fait JackPotte ($) 6 juillet 2013 à 00:26 (UTC)
Merci beaucoup ! J’ai inversé l’ordre car l’usage d’une minuscule à l’initiale sera vraiment exceptionnel, et j’ai mis à jour la documentation Sourire Eölen 6 juillet 2013 à 01:53 (UTC)

Bonjour,

Après m’être penché quelque peu sur ce modèle, je crois que c’est un modèle inutilement compliqué. Voyez par exemple cette comparaison entre les exemples donnés dans la doc. et l’utilisation de {{fr-rég}} pour ces même exemples :

Wikicode Résultat
{{fr-accord-comp-mf|année|lumière|a.ne|ly.mjɛʁ|
p2=lumière}}
{{fr-rég|a.ne.ly.mjɛʁ|p=années-lumière}}
Singulier Pluriel
année-lumière
\a.ne.ly.mjɛʁ\
années-lumière
\a.ne.ly.mjɛʁ\
Singulier Pluriel
année-lumière années-lumière
\a.ne.ly.mjɛʁ\
{{fr-accord-comp-mf|acide|alcool|a.si.d|al.kɔl|
|ptrait={{liaison}}|ptraitp=.z{{liaison}}}}
{{fr-rég|a.si.d‿al.kɔl|p=acides-alcools|pp=a.sid.z‿al.kɔl}}
Singulier Pluriel
acide-alcool
\a.si.d‿al.kɔl\
acides-alcools
\a.si.d.z‿al.kɔl\
Singulier Pluriel
acide-alcool acides-alcools
\a.si.d‿al.kɔl\ \a.sid.z‿al.kɔl\
{{fr-accord-comp-mf|eau|de-vie|o|də.vi|
p1=eaux|p2=de-vie}}
{{fr-rég|o.də.vi|p=eaux-de-vie}}
Singulier Pluriel
eau-de-vie
\o.də.vi\
eaux-de-vie
\o.də.vi\
Singulier Pluriel
eau-de-vie eaux-de-vie
\o.də.vi\
{{fr-accord-comp-mf|bande|dessinée|bɑ̃d|dɛ.si.ne|
trait=&nbsp;|ptrait=&nbsp;}}
{{fr-rég|bɑ̃d dɛ.si.ne|p=bandes dessinées}}
Singulier Pluriel
bande dessinée
\bɑ̃d dɛ.si.ne\
bandes dessinées
\bɑ̃d dɛ.si.ne\
Singulier Pluriel
bande dessinée bandes dessinées
\bɑ̃d dɛ.si.ne\
{{fr-accord-comp-mf|capote|anglaise|ka.pɔ.t|ɑ̃.ɡlɛz|
trait=&nbsp;|ptrait={{liaison}}|ptraitp=.z{{liaison}}}}
{{fr-rég|ka.pɔ.t‿ɑ̃.ɡlɛz|p=capotes anglaises|pp=ka.pɔt.z‿ɑ̃.ɡlɛz}}
Singulier Pluriel
capote anglaise
\ka.pɔ.t‿ɑ̃.ɡlɛz\
capotes anglaises
\ka.pɔ.t.z‿ɑ̃.ɡlɛz\
Singulier Pluriel
capote anglaise capotes anglaises
\ka.pɔ.t‿ɑ̃.ɡlɛz\ \ka.pɔt.z‿ɑ̃.ɡlɛz\

En plus des octets gagnés avec {{fr-rég}}, vous remarquerez que la syllabation fausse pour acides-alcools est corrigée en plus de gagner des octets. Ajout du 18 juillet 2013 à 13:26 (UTC) : elle ne l’était pas, maintenant elle l’est. Automatik (discussion)

Les seuls cas où on ne gagne pas d’octet, c’est dans la page de flexion, et encore, seulement 10% de plus ici par exemple (mais on utilise quand même moins de paramètre, et la syntaxe est simple).

Que pensez-vous de remplacer ce modèle par {{fr-rég}}, pour ne plus avoir à utiliser ce modèle ? Automatik (discussion) 12 juillet 2013 à 14:59 (UTC)

Mouais. JackPotte ($) 12 juillet 2013 à 17:52 (UTC)
C’est déjà ce que je fais depuis un moment tellement ses paramètres sont imbuvables à celui-là. V!v£ l@ Rosière /Murmurer…/ 12 juillet 2013 à 20:40 (UTC)
Je suis d’accord que {{fr-rég}} est à préférer, mais seulement si la prononciation est unique. Urhixidur (discussion) 18 juillet 2013 à 12:03 (UTC)
Tu as vu que la prononciation du pluriel de acide-alcool était erronée avec {{fr-accord-comp-mf}} ? La prononciation du pluriel est pourtant bien différente du singulier. Et capote anglaise est dans ce même cas. Automatik (discussion) 18 juillet 2013 à 13:23 (UTC)
En fait c'est plutôt {{fr-accord-mf}} qu'il faudrait utiliser. Rappelez-vous que {{fr-rég}} c'est pour les mots dont le pluriel prend un S. — Dakdada 18 juillet 2013 à 12:08 (UTC)
Dans la documentation de {{fr-rég}}, il est indiqué cela : « p=graphie (optionnel) : graphie du pluriel (le défaut suffixe un s à la graphie du singulier) ; surtout utile pour les mots composés avec accords pas uniquement à la fin, mais permet aussi d’indiquer d’autres suffixes du pluriel à un mot simple (par exemple un x). ». Donc visiblement ce modèle est valable pour les mots composés aussi, non ? Automatik (discussion) 18 juillet 2013 à 13:23 (UTC)
Ce modèle a été affublé sans trop de discussions de multiples paramètres au fil des ans pour faire des choses que fr-accord-mf faisait déjà. {{fr-rég}} est pour les mots au pluriel régulier, c'est pour ça qu'il a été écrit, et c'est pour ça qu'il est concis. Si on a besoin de faire des choses compliquées, c'est {{fr-accord-mf}} qu'il faut utiliser. — Dakdada 18 juillet 2013 à 13:34 (UTC)
Pourtant, pluriel régulier ne rime pas forcément avec pluriel en -s. Par exemple pour les mots composés (bandes dessinées est un pluriel régulier) ou les mots en -al (chevaux est un pluriel régulier). Automatik (discussion) 18 juillet 2013 à 13:48 (UTC)
Pour eux il y a des modèles dédiés. Le modèle s'écrivait à l'origine {fr-accord-mf-reg} et a été créé spécialement pour les pluriels en -s ({fr-accord-mf-reg-s} serait plus précis encore), mais c'est une version courte qu'on utilise car elle est sensée être utilisée pour de très nombreux mots. — Dakdada 18 juillet 2013 à 13:53 (UTC)
D’accord, je crois comprendre que le mieux selon nos conventions actuelles aurait été de créer {{fr-accord-mf-rég-s}} vers lequel {{fr-rég}} redirigerait pour être utilisé en pratique (comme {{info}} redirige vers {{informatique}} en fait). Mais quelle condition n’est pas remplie par bande dessinée pour utiliser {{fr-rég}} ? Pluriel régulier, en -s, et mot à un seul genre. Automatik (discussion) 18 juillet 2013 à 14:04 (UTC)
C'est une locution, donc il ne suffit pas de rajouter un -s (c'était le seul but du modèle). Le pluriel d'une locution n'étant pas trivial, il faut un modèle adapté, {{fr-rég}} aurait dû rester simple. — Dakdada 18 juillet 2013 à 14:49 (UTC)

Tout ça montre bien l'importance des noms des modèles : il faut qu'ils soient à la fois simples et qu'ils correspondent parfaitement à ce qu'ils font. Je suis contre la complexification progressive des modèles, mais avoir un paramètre unique p pour traiter les cas du genre pomme de terre, qui peuvent être considérés comme réguliers, ça me semble justifié, et ça ne complique pas vraiment. Quand au modèle dont on parle, fr-accord-comp-mf, c'est une aberration, c'est compliquer pour le plaisir de compliquer. Lmaltier (discussion) 18 juillet 2013 à 20:41 (UTC)

En fait pomme de terre est géré par inv, pas p. Sourire Urhixidur (discussion) 20 juillet 2013 à 12:01 (UTC)
Qu'est-ce que ça change, à part d'être plus compliqué ? Lmaltier (discussion) 23 juillet 2013 à 19:44 (UTC)

Nom verbal en basque

Bonjour,

Tous les verbes en basque donnent un nom verbal. Voir abandonatu et abandonatze. Serait-il possible d'avoir un modèle Modèle:-nom-verb-. Merci. --Euskaltzale (discussion) 23 juillet 2013 à 13:25 (UTC)

Les types de mot décrivent à priori la nature d’un mot. Serait-ce faux dans ce cas précis de préciser dans l’étymologie qu’il s’agit d’un nom verbal, en utilisant modèle:-nom- pour le type de mot ? C’est ce que je ferais, à priori. Automatik (discussion) 23 juillet 2013 à 13:29 (UTC)
Je peux faire ainsi. --Euskaltzale (discussion) 23 juillet 2013 à 13:41 (UTC)
Oui je pense aussi que c’est la meilleure solution. V!v£ l@ Rosière /Murmurer…/ 23 juillet 2013 à 20:19 (UTC)

Bonjour,

Actuellement ce modèle est indifféremment utilisé en début de page (spicilège) ou dans la section des références (passequille). Cependant, il paraît non seulement plus logique de le mettre dans la section références, mais aussi d’être plus précis dans le texte, car le modèle renvoit à priori vers la liste des auteurs de Wikipédia, alors que la page concernée est en général supprimée, le lien d’arrivée ne donne donc pas le résultat souhaité (exemple).

C’est pourquoi je propose de changer le contenu du modèle par ce texte, en déplaçant ce modèle dans la section de références ensuite. Ce modèle est peu utilisé, donc c’est facile à faire, la transition serait très courte.

Qu’en pensez-vous ? Automatik (discussion) 23 juillet 2013 à 18:39 (UTC)

Tu as réinventé {{Source-w}}, mais le modèle bandeau était réservé aux ébauches, surtout dans l’espace Transwiki. JackPotte ($) 23 juillet 2013 à 18:50 (UTC)
La différence avec {{source-w}}, c’est que celui que je propose prend en compte le fait que l’article sur WP n’existe plus, sinon j’aurai remplacé {{Transféré de Wikipédia}} par {{source-w}} tout simplement, mais ça m’a paru être déraisonnable vis-à-vis des droits d’auteur. Donc je ne suis pas contre enlever ce bandeau dès qu’il est en dehors de l’expace Transwiki, mais si on m’assure qu’il n’y a pas de problème vis-à-vis de ça. Automatik (discussion) 23 juillet 2013 à 18:57 (UTC)
Tu veux dire que vérifier régulièrement si des articles sont supprimés et restaurés pour passer de {{Source-w}} à {{Transféré de Wikipédia}} et vice-versa, présente un avantage par rapport au fonctionnement actuel ? JackPotte ($) 23 juillet 2013 à 19:40 (UTC)
Je ne l’aurais fait que pour les pages qui utilisent {{Transféré de Wikipédia}}, mais ok pour être plus simple et utiliser {{source-w}} partout. Automatik (discussion) 23 juillet 2013 à 20:06 (UTC)

Ai-je le droit de créer un modèle pour mon espace utilisateur ?

Tout est dans le titre. Si oui, doit-il être créé différemment d’un modèle concernant l’ensemble du WT ? Mon idée est de mettre un texte commun sur certaines de mes sous-pages en ne créant le texte qu’une fois, de façon à ne pas avoir à modifier chaque sous-page dès que je veux modifier ce texte.--Titruffe (Apprends-moi) 30 juillet 2013 à 02:42 (UTC)

À priori, mieux vaut mettre ton texte commun dans une page de l’espace Utilisateur plutôt qu’une page de l’espace Modèle:. Par exemple, utilisateur:Titruffe/Modèle de navigation. Ensuite, dans toutes les pages où tu veux mettre ton bandeau de navigation, tu écris {{utilisateur:Titruffe/Modèle de navigation}}. Automatik (discussion) 30 juillet 2013 à 03:06 (UTC)
Génial, ça répond parfaitement à mes attentes ! Bravo ! --Titruffe (Apprends-moi) 30 juillet 2013 à 03:12 (UTC)

Liste par langue

On a plusieurs cas où on liste plein de langues avec un lien vers un simple mot de la langue considérée. C'est le cas dans les sections {{-drv-int-}}, {{-noms-vern-}}... Sauf pour les traductions, qui nécessiteront une forme particulière et des exceptions (commentaires par exemple). Il y a moyen pour ces cas-là de faire un modèle général simplifié :

Code actuel Code simplifié
* {{L|sq}} : ]
* {{L|de}} : ]
* {{L|am}} : ]
* {{L|ar}} : ]
* {{L|bg}} : ]
* {{L|ko}} : ]
* {{L|hr}} : ]
* {{L|da}} : ]
* {{L|es}} : ]
* {{L|eo}} : ]
* {{L|gd}} : ]
* {{L|ka}} : ]
* {{L|hi}} : ]
* {{L|id}} : ]
* {{L|ia}} : ]
* {{L|ja}} : ]
* {{L|la}} : ]
* {{L|lv}} : ]
* {{L|mwl}} : ]
* {{L|nl}} : ]
* {{L|ug}} : ]
* {{L|ur}} : ]
* {{L|pap}} : ]
* {{L|fa}} : ]
* {{L|pl}} : ]
* {{L|pt}} : ]
* {{L|ro}} : ]
* {{L|ru}} : ]
* {{L|sr}} : ]
* {{L|sw}} : ]
* {{L|tg}} : ]
* {{L|uk}} : ]
* {{L|vo}} : ]
* {{L|yi}} : ]
* {{L|yo}}  : ]
* {{L|zu}} : ]
{{liste par langue|
sq = kompjuter
de = Computer
am = ኮምፒዩተር
ar = كمبيوتر
bg = компютър
ko = 컴퓨터
hr = kompjuter
da = computer
es = computadora
eo = komputilo
gd = coimpiutair
ka = კომპიუტერი
hi = कंप्यूटर
id = komputer
ia = computator
ja = 
la = computatrum
lv = kompjūters
mwl = computador
nl = computer
ug = كومپيۇتېر
ur = کمپیوٹر
pap = kòmpiuter
fa = کامپیوتر
pl = komputer
pt = computador
ro = computer
ru = компьютер
sr = kompjutor
sw = kompyuta
tg = компютер
uk = компютер
vo = kompütöm
yi = קאָמפּיוטער
yo = kọ̀mpútà
zu = ikompiyutha
}}

En bonus les bons scripts seront utilisés pour afficher ces mots. Ajout : les langues pourront aussi être triées automatiquement : plus la peine de s'embêter à trier les codes langues à la main.

On pourra faire la même chose pour les traductions et les faux-amis, mais il faudra des modèles adaptés aux spécificités de chacun. — Dakdada 15 août 2013 à 14:21 (UTC)

Le fait qu’un nom de langue soit mentionné dans les traductions ne signifie pas forcément qu’il y a une traduction ensuite, donc je serais opposé à ce que {{L}} ajoute Catégorie:Traductions en. JackPotte ($) 15 août 2013 à 14:32 (UTC)
La proposition a pour but de remplacer l'usage de L (ou plus généralement des listes de langue simples), et n'aborde justement pas le problème des traductions qui est plus compliqué. Chaque chose en son temps. — Dakdada 15 août 2013 à 14:36 (UTC)
Si tu veux créer {{liste par langue}} sans tenir compte des traductions (leurs ébauches, leurs transcriptions et translittérations, ancres de liens internes et externes) il faudra probablement tout reprendre à zéro ensuite. 15 août 2013 à 14:47 (UTC)
Ben non, ce sera juste une version améliorée, et surtout plus compliquée. Pourquoi faire compliqué quand on peut faire simple d'abord ? — Dakdada 15 août 2013 à 15:00 (UTC)
J’apprécie ton travail et ce n’est pas pour t’embêter que je brandis les préceptes du chef de projet informatique et de sa méthode de calcul du temps de développement : Constructive Cost Model#Modèle_de_base sur l’encyclopédie Wikipédia . En cahier des charges non déterministe depuis le début, le temps de développement est augmenté d’un coefficient que j’ai pu confirmer par expérience. JackPotte ($) 15 août 2013 à 15:24 (UTC)
Il y a déjà une version test utilisable, cf Utilisateur:Darkdadaah/eau. Le plus compliqué et le plus long ce n'est pas le développement, mais la mise au point du cahier des charges, qui varie selon les commentaires et critiques des autres contributeurs. — Dakdada 15 août 2013 à 15:41 (UTC)
Le cas où on aurait plusieurs codes langue identiques serait aussi géré ? Sinon le principe me plaît personnellement. Automatik (discussion) 15 août 2013 à 16:04 (UTC)
Qu'est-ce que tu entends par plusieurs codes langues identiques ? — Dakdada 15 août 2013 à 16:35 (UTC)
Par exemple si l’on veut ajouter deux noms vernaculaires pour la même langue (je suppose qu’on ajoute deux lignes avec le même code langue ?), comme dans Chordata. L’affichage serait-il géré sur une seule ligne par exemple ? Automatik (discussion) 15 août 2013 à 16:44 (UTC)
En effet, chaque entrée pour une langue quelconque peut compter de multiples mots, avec des indicateurs de genre et nombre, registre, etc. Par ex., à joli on a pour l’{{id}} « bagus, baik, cantik ». À beau, pour l’{{en}} on a « : beautiful (but for a man: handsome), pretty (but for a man: handsome), handsome, fine, lovely, fair » et pour le {{sa}} on a « सुन्दर (sundara) masculin, féminin, neutre ». Urhixidur (discussion) 15 août 2013 à 18:51 (UTC)
Sans parler des traductions littérales de proverbes, ou des registres de langue que l'on trouve parfois dans cette rubrique. JackPotte ($) 15 août 2013 à 19:03 (UTC)
Comme je l'ai dit la proposition ici ne concerne pas les traductions, uniquement les dérivés en d'autres langues et autres. Si on a plusieurs noms possible, il suffirait de séparer les éléments avec des virgules. — Dakdada 15 août 2013 à 20:31 (UTC)

En passant, ce serait inédit d’avoir une liste de paramètres sans pipe entre chacun d’eux. Mais moi ça ne me dérange pas, c’est plus clair pour les néophytes (mais troublant en comparaison avec les autres modèles ne respectant pas cette norme). Au fait, c’est vraiment voulu ? — Automatik (discussion) 20 octobre 2013 à 01:15 (UTC)

Ah... non (en fait c'est possible de faire sans les barres verticales mais c'est probablement à éviter). NB : j'ai fait d'autres essais depuis, notamment un qui utilise une liste à puces et une mise en forme qui correspond presque exactement à ce qui est affiché et utilisé actuellement (Discussion_module:traduction_table). Cela dit je n'ai pas encore de code correspondant pour vraiment tester, et il reste le problème de comment indiquer les traductions existantes/manquantes dans les autres dicos de manière élégante (il faudrait introduire une marque simple pour les mots inexistants). — Dakdada 20 octobre 2013 à 11:35 (UTC)

Bonjour.

Je viens de constater que {{poisson}}{{poissons}} qui catégorise bien en ] affiche ichtyologie. Quel modèle utiliser pour le vocabulaire général de l'ichtyologie par exemple les noms des taxons au-dessus de l'espèce ? --Pjacquot (discussion) 26 août 2013 à 13:30 (UTC)

Il y a aussi {{ichtyologie}} si c’est ce que tu cherches. Automatik (discussion) 26 août 2013 à 13:55 (UTC)

La question n'est pas de chercher un modèle particulier, le problème est que nous avons deux modèles qui commencent l'un comme l'autre par {{term|ichtyologie}} et qui catégorisent vers des catégories différentes. --Pjacquot (discussion) 26 août 2013 à 14:09 (UTC)

Ce type de modèle avait été lancé il y a plusieurs années déjà, {{plantes}} affiche botanique, et {{animaux}} zoologie. JackPotte ($) 26 août 2013 à 14:11 (UTC)
J’avais posé une question similaire sur Wiktionnaire:Wikidémie/avril_2013#Modèle:minéraux et Modèle:minéralogie, et on m’avait répondu que c’était fait exprès. Cela dit je ne suis pas contre enlever l’affichage (ichtyologie) pour les poissons. Automatik (discussion) 26 août 2013 à 14:13 (UTC)
D’un côté ça fait une ancre #poisson à la définition du poisson, de l’autre on ne peut pas afficher le mot poisson avant une définition car il avait été remarqué que ce n’était pas dans l’usage lexicographique (contrairement à zoologie que l’on retrouve dans plusieurs dictionnaires). JackPotte ($) 26 août 2013 à 14:15 (UTC)
Ok c'est donc normal. Je suis soulagé--Pjacquot (discussion) 26 août 2013 à 14:18 (UTC). Cordialement.
Je voudrais faire remarquer qu'il y a de nombreux noms de poissons qui n'ont rien à voir avec l'ichtyologie (par exemple garlèche, mais ce n'est qu'un exemple parmi des quantités d'autres). Ce modèle poissonpoissons est donc très susceptible d'être mal employé. Pour moi, il n'a pas de raison d'être, et il vaut bien mieux rajouter la catégorie à la main. Lmaltier (discussion) 19 septembre 2013 à 19:10 (UTC)
Les 2 seuls systèmes permettant de conserver à la fois tous les avantages c’est-à-dire :
  • l’ancre #poisson (permet de lier précisément, et de faire automatiquement des dictionnaires thématiques),
  • un modèle facile à mémoriser qui catégorise avec la bonne syntaxe,
  • un code propre et lisible : {{poissons|fr}}
Tout en évitant d’avoir :
  • une étiquette inhabituelle et inutile car redondante : (Poisson) Poisson de mer à large…,
  • une étiquette erronée : (Ichtyologie) pour garlèche.
c’est d’avoir un modèle {{poissons|fr}} catégorisant mais sans affichage !
ou bien d’avoir un modèle {{poissons|fr}}, catégorisant, dont l’affichage se confond avec l’hyperonyme de la définition (mais cela obligerait souvent à modifier la définition pour y ajouter cet hyperonyme). Stephane8888 19 septembre 2013 à 20:08 (UTC)
Il ne faut surtout pas se donner des contraintes artificielles sur les définitions juste pour justifier l'emploi d'un modèle. Mais la proposition sans affichage pourrait avoir avoir (dans quelques cas seulement, par exemple perche) l'intérêt de mettre l'ancre. Mais c'est la première fois que j'entends cet argument, et je ne pense pas qu'il y ait actuellement des liens du type perche#poisson|perche... Cela me semble une proposition toute nouvelle. Mais même si on l'adopte, il ne faut pas que ça dissuade de mettre des catégories en clair, il y a des cas où c'est incontournable. Lmaltier (discussion) 20 septembre 2013 à 05:54 (UTC)
Sur ce coup je suis d’accord avec Lmaltier, je préfère mettre le modèle de la catégorie parente avec un nocat puis ajouter la catégorie en clair plutôt que de recourir à ce genre de modèles qui perturbent les nouveaux contributeurs ainsi que certains anciens… (la preuve en image avec le cas Pamputt ci-dessus). V!v£ l@ Rosière /Murmurer…/ 20 octobre 2013 à 13:17 (UTC)

Modification proposée à une des règles de {{clé de tri}}

La règle que je vise est celle qui se lit :

  • Terme avec tiret ou trait d’union à l’intérieur : Remplacer le tiret/trait d’union par une espace unique

Rappelons que l’apostrophe, lui, est éliminé et non remplacé par une espace. On aura donc la même clé de tri pour :

Mais deux clés différentes pour :

Pourtant la règle telle qu’elle existe est correcte dans des cas comme les toponymes :

  • île du Prince Édouard
  • Île-du-Prince-Édouard

Je propose donc un compromis :

  • Terme avec tiret ou trait d’union à l’intérieur : Remplacer le tiret/trait d’union par une espace unique si la forme est celle d’une locution, sinon le supprimer

Le but poursuivi est que les termes soumis à la règle des mots soudés de la rectification orthographique de 1990 aient la même clé de tri avant et après la soudure. Il existe aussi bon nombre de mots pour lesquels le trait d’union était optionnel bien avant 1990.

Qu’en pensez-vous ? Urhixidur (discussion) 19 septembre 2013 à 18:19 (UTC)

Ça me paraît très bien comme proposition. Stephane8888 19 septembre 2013 à 18:43 (UTC)

Je ne comprends pas du tout quel intérêt il y aurait à ce que ces termes aient la même clé de tri avant et après la soudure, tout au contraire : la seule raison d'être des clés de tri est la recherche dans les catégories, et pouvoir trouver ces mots à deux endroits différents dans les catégories augmente les chances de les trouver, quelle que soit la façon de rechercher du lecteur. Les regrouper au même endroit n'a pas d'intérêt. En plus, ça rend la règle plus compliquée (et sujette à des interprétations subjectives). Il vaut mieux rester simple.

Par contre, je proposerais bien de traiter les apostrophes comme les traits d'union : je n'ai jamais compris pourquoi on les traitait différemment. Lmaltier (discussion) 19 septembre 2013 à 19:03 (UTC)

L’avantage de ranger les variantes orthographiques au même endroit est d’offrir cette vision synoptique aux lecteurs de la catégorie (ce serait davantage neutre). Mais si on considère une catégorie comme un index permettant de trouver un mot ou une locution, alors la solution de Lmaltier est meilleure (c’est davantage utile). Je ne peux pas trancher car je n’utilise jamais les catégories. Je conçois difficilement que certains s’amusent à balayer nos catégories (assez difficiles à trouver) pour y dénicher le mot qu’ils cherchent alors qu’un moteur de recherche leur tend les bras en permanence. Stephane8888 19 septembre 2013 à 19:33 (UTC)
Et pourtant, les catégories peuvent être très utiles, par exemple quand on a oublié l'orthographe précise d'un mot. En fait, les catégories permettent de consulter le Wiktionnaire comme si c'était un dictionnaire papier, certains aiment bien. Les catégories thématiques ou spécialisées sont par ailleurs très utiles quand on a carrément oublié un mot, et qu'on a besoin de le voir écrit pour le retrouver. C'est un énorme plus du Wiktionnaire (même si ce n'est sans doute pas encore un plus très utilisé).
De toutes façons, la modification proposée ne concerne que les utilisateurs des catégories, les autres ne sont pas concernés. C'est donc uniquement à ceux qui les utilisent qu'il faut penser ici. Lmaltier (discussion) 19 septembre 2013 à 20:15 (UTC)
Utilité et simplicité de la règle. Stephane8888 19 septembre 2013 à 20:22 (UTC)
C'est-à-dire ? Je pense qu'effectivement, comme je l'ai expliqué, garder la règle sur les traits d'union inchangée la conserve à la fois plus utile et plus simple. Lmaltier (discussion) 19 septembre 2013 à 20:42 (UTC)
Un avantage de la règle modifiée provient de sa genèse : j’en suis venu à cette conclusion à force de regrouper des paires de tableaux de conjugaisons de verbes ayant subi la rectification de 1990 (disparition du î, surtout) sous la forme d’une seule page avec le {{Onglets conjugaison}} et une transclusion des autres points d’accès. Ça simplifie l’écriture de la paire de tableaux (et permet d’éviter des dérives entre les deux, comme le choix des temps et personnes à griser), ça centralise leur entretien et les onglets permettent à l’utilisateur de comparer plus facilement. Mais lorsque je suis tombé sur les paires de verbes ayant subi la soudure, c’est là que ça c’est mis à clocher. Dans tout dictionnaire papier que j’ai pu consulter, les mots avec et sans soudure étaient toujours côte à côte, aussi je ne crois pas que la règle que je propose soit révolutionnaire. Urhixidur (discussion) 20 septembre 2013 à 01:44 (UTC)
Il ne faut pas comparer avec les dictionnaires papier. Les dictionnaires papier ont une règle simple, de façon générale : ils ne tiennent compte ni des apostrophes, ni des traits d'union, ni des espaces. C'est tout à fait normal, car ils ont très peu de locutions comme entrées, et ce faible nombre ne justifie pas une complication de la règle. Comme nous avons plein de locutions comme entrées, nous avons préféré suivre la philosophie utilisée en général par des listes ayant beaucoup de traits d'union et d'espaces dans leurs entrées, comme par exemple des listes de stations de métro ou de rues : par exemple, pour prendre un cas très courant, les noms en Sainte- sont regroupés, et on ne trouve pas Saint-Eustache entre Sainte-Sophie et Sainte-Victoire, comme ce serait le cas avec les dictionnaires papier. Pour ce qui est de l'argument des pages de conjugaison, je ne comprends pas : normalement, on a des pages de conjugaison différentes selon qu'il y a un trait d'union ou pas, c'est le plus simple pour les lecteurs (et le plus facile à automatiser, d'ailleurs). Lmaltier (discussion) 20 septembre 2013 à 05:43 (UTC)

En parlant de modèles/module, j'ai réécrit Module:clé de tri2 (car Module:clé de tri n'est pas du tout optimal). Vous pouvez tester les règles dans la page de discussion : Discussion module:clé de tri2. Les règles peuvent encore y être modifiées. — Dakdada 20 septembre 2013 à 09:09 (UTC)

NB : d'autant que la clé actuelle créée par Module:clé de tri est incomplète. — Dakdada 20 septembre 2013 à 09:14 (UTC)
« Les dictionnaires papier ont une règle simple, de façon générale : ils ne tiennent compte ni des apostrophes, ni des traits d’union, ni des espaces. » Faux. On y trouve tous les Saint- avant de passer aux Sainte-. Mais on trouve contre-balancer et contrebalancier côte à côte (Quillet-Grolier). Peut-être devrais-je reformuler la règle proposée ?
  • Terme avec tiret ou trait d’union à l’intérieur : Remplacer le tiret/trait d’union par une espace unique à moins que l’orthographe admette (dans les faits ou potentiellement) de le supprimer, auquel cas on le supprime
Dit ainsi, on s’en remet à l’usage, qui veut que certains préfixes ((entre-, contre-, pseudo-, extra-, etc.) puisse s’écrire aussi bien avec que sans trait d’union. La clé de tri ne ferait que refléter cet état de fait. Urhixidur (discussion) 20 septembre 2013 à 11:31 (UTC)
Donc ça veut dire qu'il y a des exceptions chez les dictionnaires papier (mais je pense que sur les dictionnaires de langues, il ne devrait y avoir quasiment pas d'exception). Mais tu ne réponds pas à mon point principal : c'est plus utile aux lecteurs des catégories de séparer les entrées de ce genre que de les regrouper. Lmaltier (discussion) 20 septembre 2013 à 18:43 (UTC)
Pourquoi est-ce que tu considères la séparation des clés plus utile que l’inverse ? J’ai la perception contraire. Urhixidur (discussion) 23 septembre 2013 à 13:40 (UTC)
Quand il y a plusieurs orthographes, ça permet au lecteur de trouver ce qu'il cherche de façon naturelle, quel que soit l'endroit où il cherche (et le lecteur normal ne connait pas le détail des règles qu'on utilise). Regrouper lui donne moins de chance de trouver. Je rappelle que le seul intérêt de la clé de tri, c'est pour les lecteurs qui consultent les catégories. Lmaltier (discussion) 20 octobre 2013 à 15:29 (UTC)
Voici d’ailleurs une autre source qui abonde dans mon sens : Règles du classement alphabétique en langue française. Notez l’introduction, qui mentionne que ces règles sont les règles traditionnelles qu’utilisent entre autres Larousse et le Robert. Urhixidur (discussion) 23 septembre 2013 à 14:15 (UTC)
Oui, mais les règles sont généralement légèrement différentes dans les répertoires de rues ou de stations de métro (par exemple), et il y a des raisons à ça (voir ci-dessus). Lmaltier (discussion) 20 octobre 2013 à 16:22 (UTC)

Hmmm… Comme Stephane, les deux solutions se justifient et peuvent être utiles selon la manière de rechercher un mot dans une catégorie. Je ne peux pas trancher car faire au cas par cas pourrait finalement aussi bien aider la recherche d’un mot de certains que gêner celles d’autres. V!v£ l@ Rosière /Murmurer…/ 22 octobre 2013 à 06:58 (UTC)

Bonjour,

Actuellement {{phyton}} redirige vers {{plantes}}, car il existe le mot phytonyme pour désigner une plante vernaculaire. Cela dit, je l’ai trouvé dans une page, et je n’avais pas compris ce que ça voulait dire. Si vous aussi vous ne le trouvez pas clair comme nom de modèle, alors je me ferai un plaisir de le remplacer dans les pages où il se trouve (par {{plantes}}, donc). — Automatik (discussion) 8 octobre 2013 à 20:02 (UTC)

Par convention certains dictionnaires introduisent leurs définitions par un domaine d'utilisation (dont la phytonymie), mais aucun par un hyperonyme (du moins la dernière fois que cela a été abordé). JackPotte ($) 8 octobre 2013 à 20:20 (UTC)
En fait l’affichage est de toute façon (Botanique), donc il n’est question que de la clarté du nom du modèle (pour les contributeurs, en particulier les nouveaux). De plus la catégorisation est catégorie:Plantes. — Automatik (discussion) 8 octobre 2013 à 20:36 (UTC)
OK, si tu veux supprimer {{phyton}} je n'y vois pas d'objection car une catégorie du même nom serait redondante de Catégorie:Plantes. JackPotte ($) 8 octobre 2013 à 20:41 (UTC)

Ce modèle contient un titre de section de niveau 3 et du contenu supplémentaire. Afin d'homogénéiser notre mise en page et de préparer le passage aux sections modifiables, il va falloir séparer le titre et le contenu de la section. Pour ce faire, je propose l'utilisation d'un modèle de section {{-étym-graphique-}} ou {{-étymologie-graphique-}} et la conservation du modèle {{Étymologie graphique chinoise}} sans la partie section. Un bot pourra se charger de remplacer les occurrences de ce modèle. — Dakdada 23 octobre 2013 à 08:50 (UTC)

Le changement proposé est tout simple :

Actuel Proposé (Version section modifiable)
{{Étymologie graphique chinoise
|...
}}
{{-étymologie-graphique-}}
{{Étymologie graphique chinoise
|...
}}
=== {{S|étymologie graphique}} ===
{{Étymologie graphique chinoise
|...
}}

Dakdada 23 octobre 2013 à 09:31 (UTC)

NB : d'autres modèles devront subir le même sort : {{composition}}, {{sinogram-noimg}}, peut-être d'autres. — Dakdada 23 octobre 2013 à 09:33 (UTC)
Pourquoi on ne passerait pas directement de l'actuel à la section modifiable ? JackPotte ($) 23 octobre 2013 à 11:12 (UTC)
On pourrait, mais encore faut-il qu'on lance la prise de décision, et ça devra attendre la fin du Lexiconcours. — Dakdada 23 octobre 2013 à 11:40 (UTC)
Enfin, pourquoi pas, s'il faut absolument que les sections soient éditables - ça fait plus de volume dans la page, mais de toute manière je remplis ça toujours par des copié-collé. La section est en réalité une section d'étymologie, c'est parce que ça porte sur un caractère chinois que le contenu est bizarre. Micheletb (discussion) 24 octobre 2013 à 05:17 (UTC)

Pour Pour Je donne mon soutien explicite concernant la modification de ce modèle et des autres à venir. V!v£ l@ Rosière /Murmurer…/ 24 octobre 2013 à 05:28 (UTC)

Modèle:blocage

Modèle inutile et catégorie associée supprimée suite à cette requête. V!v£ l@ Rosière /Murmurer…/ 12 novembre 2013 à 05:13 (UTC)

Ajout d'un paramètre dans un modèle

Bonjour, serait-ce possible d'ajouter le paramètre rac-pl dans {{sv-nom-n-er}} ? Pour exemple, ce paramètre est déjà présent dans {{sv-nom-c-or}}. Merci d'avance. Surkål (discussion) 28 novembre 2013 à 22:06 (UTC)

Salut, j’ai ajouté le paramètre, mais je ne suis pas sûr qu'il ait le comportement attendu, car je ne connais pas les intentions du modèle. Peux-tu me préciser ce qu’il faudrait faire au besoin ? Bonne soirée, — Automatik (discussion) 28 novembre 2013 à 22:55 (UTC)
Bravo ! Merci, ça marche. C'était pour land, dans le sens de pays (page en construction). Surkål (discussion) 28 novembre 2013 à 23:25 (UTC)

paramètre conv dans -symbole-

Le modèle de section {{-symbole-}} sous-entend par défaut que le paramètre de langue est "conv" si le paramètre n’est pas donné. Or il y a deux usages actuels dans le Wiktionnaire : la grande majorité est écrite avec le paramètre conv, et seulement une poignée de pages n’ont pas de paramètre (papa, , , `, δρχ, USN). Je propose de rendre obligatoire la précision du code "conv", ce sera bien plus simple.

NB : dans le cas où le code langue est "conv", la catégorisation se fait dans Catégorie:Symboles, et pas Catégorie:Symboles en conventions internationales (qui existe pourtant). Ce serait peut être mieux de mettre tous les symboles "internationaux" dans la catégorie Catégorie:Symboles en conventions internationales. — Dakdada 6 décembre 2013 à 13:59 (UTC)

OK pour moi. C'est d'ailleurs ce que font les lusophones par exemple. JackPotte ($) 6 décembre 2013 à 19:22 (UTC)
Les anglophones aussi font ainsi (en:Category:Translingual symbols), nous n’avions simplement pas le lien interwiki dans notre catégorie:Symboles car elle regroupe ce qui est à la fois dans en:category:Symbols et dans en:category:Translingual symbols. Cette proposition permettrait de corriger cela en séparant les symboles internationaux des symboles des autres langues, si personne n’y voit d’objection. — Automatik (discussion) 7 décembre 2013 à 19:40 (UTC)

J’ai remarqué qu’on a la même question qui se pose pour {{-nom-sciences-}} : il catégorise dans catégorie:Noms scientifiques par défaut, car il n’est fait que pour les conventions internationales. Pour les codes autres que "conv", ce modèle semble avoir été déconseillé en PàS.
D’un autre côté, {{-déf-}} ne s’occupe pas de la catégorisation grammaticale pour les types de mot de code "conv", contrairement aux autres langues : il laisse les modèles de types de mot utilisés dans une section de conventions internationales catégoriser par eux-mêmes. Ainsi {{-nom-|conv}} ne catégorise-t-il pas l’entrée Euchloe insularis dans catégorie:Noms communs en conventions internationales, bien qu’elle existe (mais elle ne regroupe que des sous-catégories).
Un autre exemple d’incohérence pour la gestion des termes en conventions internationales est que certaines pages utilisent une section {{-trad-}} avec {{T}} et {{trad}} pour traduire un nom scientifique dans d’autres langues, tandis que d’autres utilisent {{-noms-vern-}} (avec au choix {{T}}/{{trad}} ou {{L}}/{{lien}}, même si cela devrait être uniformisé logiquement en {{L}}/{{lien}}, si je ne me trompe pas ?). D’autres pages utilisent même {{-noms-vern-}} pour le français et {{-trad-}} pour les autres langues.
Les conventions du Wiktionnaire qui s’appliquent aux sections de conventions internationales sont probablement les moins bien définies/gérées, et il serait bon qu'on s’en occupe. — Automatik (discussion) 14 décembre 2013 à 18:56 (UTC)

Bonjour,

Il y a quelques cas où l’on trouve le modèle {{term}} utilisé pour générer un texte à mettre dans la ligne de forme (ex : les modèles {{contraction}}, {{irrégulier}}, {{diptote}}, et peut-être d’autres). Je ne sais pas pourquoi puisque ce dernier met automatiquement la première lettre du mot en majuscule (pas beau ni justifié dans la ligne de forme), et est fait pour indiquer un domaine d’utilisation ; c’est-à-dire qu’à priori il devrait être utilisé pour des modèles qui sont dans la catégorie:Modèles de domaine d’utilisation.

Je propose donc de réécrire ces modèles pour qu’ils soient adaptés à une ligne de forme. Pour info, voici leurs utilisations :

  • {{contraction}} alias {{modl|contr}} : 71/74 utilisations dans la ligne de forme
  • {{irrégulier}} alias {{irrég}} : 556/566 utilisations dans la ligne de forme
  • {{diptote}} : 2/2 dans la ligne de forme

Ça me paraît donc un changement évident, je précise donc que je le ferai sous peu sauf opposition. — Automatik (discussion) 13 décembre 2013 à 03:09 (UTC)

Effectivement la contraction relève de l'étymologie et certains la préfère sur la ligne de forme, mais pas sur celle de définition. JackPotte ($) 13 décembre 2013 à 08:07 (UTC)
Ça me parait logique. En passant, ce serait bien d’avoir un modèle de base pour les modèles de la ligne de forme, comme {{term}} et les autres pour la ligne de définition. Actuellement tous les styles sont écrits en dur (couleurs notamment), ce qui n’est pas très pratique. — Dakdada 13 décembre 2013 à 16:23 (UTC)

faitAutomatik (discussion) 14 avril 2014 à 16:10 (UTC)

Bonjour,

Ce modèle prend le code langue "conv" par défaut si on n’en renseigne pas. Ne préférez-vous pas que le code langue soit systématique, par homogénéisation et pour faciliter la maintenance (ça permettrait de le réécrire comme les autres modèles de domaine d’utilisation avec les différents paramètres de {{term}}) ? Il n’est utilisé que dans 14 pages. Une modification pas très importante mais qui permet de repartir sur de bonnes bases pour de futurs changements — qui arrivent naturellement au fur et à mesure que le Wiktionnaire évolue. — Automatik (discussion) 13 décembre 2013 à 03:16 (UTC)

D'un autre côté la ponctuation pourrait être une sous-catégorie de Catégorie:Symboles, par exemple avec {{-ponctuation-}} ou {{-symbole-|ponctuation=1}}. JackPotte ($) 13 décembre 2013 à 08:14 (UTC)
Apparemment il y a au moins une entrée de Catégorie:Signes de ponctuation en conventions internationales qui ne pourrait pas être considérée comme un symbole, il me semble : ... (trois points distincts). — Automatik (discussion) 13 décembre 2013 à 10:39 (UTC)
Les points de suspensions sont pourtant catégorisés dans les caractères. JackPotte ($) 13 décembre 2013 à 13:33 (UTC)
Ceux-là : , oui, mais pas ceux dont je parlais (suite de trois caractères). — Automatik (discussion) 13 décembre 2013 à 13:36 (UTC)
Une section pour les signes de ponctuations me semble raisonnable : ce sont des symboles bien particuliers (donc en sous-catégorie aussi). Pour le modèle, « signe de ponctuation » est plus correct que « ponctuation », même si c’est plus long. Je l’ajouterai aussi à Module:types de mots/data selon ce qu'on décide. — Dakdada 13 décembre 2013 à 16:16 (UTC)

Bonjour,

Ce modèle affichait à ses débuts le simple symbole ®, et il était donc utilisé certaines fois juste après le nom d'une marque commerciale, sans espace. Depuis, il a été changé pour rendre (Marque commerciale) (cf. ), sans forcément que les pages liées aient été traitées. Aujourd’hui ce modèle est utilisé un peu partout indifféremment de son rendu et je voudrais donc proposer de remplacer ses utilisations par un texte adapté à chaque endroit où il est placé, en gardant toutefois le modèle pour l’usage le plus répandu actuellement.

Après analyse, voici les utilisations actuelles du modèle — il peut y en avoir plusieurs différentes dans une même page :

  • Sur la ligne de forme : 75/167 pages concernées (ex. : duplicate Scrabble)
  • Dans la section étymologie : 33/167 pages concernées (ex. : frigolite)
  • Au début de la définition : 26/167 pages concernées (ex. : critérium)
  • Ailleurs, par exemple dans une liste de synonymes

Que pensez-vous de remplacer les utilisations de ce modèle :

  • dans la ligne de forme par « marque commerciale » en réécrivant le modèle pour cela (une fois les pages liées traitées)
  • dans la ligne de définition utiliser un modèle {{marques commerciales}} qui afficherait ce qu’affiche actuellement le modèle {{marque}} soit « (Marque commerciale) »
  • dans la section d’étymologie et ailleurs, par simplement « (marque commerciale) », sauf cas où la majuscule serait justifiée

?

En vous remerciant par avance pour vos avis sur la question, — Automatik (discussion) 17 décembre 2013 à 21:41 (UTC)

Bonjour,

Le modèle {{interwiktionnaire}} contient actuellement une puce, ne faudrait-il pas plutôt l’enlever pour la mettre en dehors, comme pour les autres modèles de ce genre ({{WP}}, {{Catégorie langue}}, etc.) ? — Automatik (discussion) 21 décembre 2013 à 21:31 (UTC)

Pourquoi pas. JackPotte ($) 21 décembre 2013 à 22:15 (UTC)
Une des raisons pour laquelle je proposais cette modification est de pouvoir homogénéiser la présence des puces dans une section "Voir aussi". Exemple :
{{-voir-}}
* {{Catégorie langue}}
{{interwiktionnaire|bg}}
* {{WP}}
pourrait être :
{{-voir-}}
* {{Catégorie langue}}
* {{interwiktionnaire|bg}}
* {{WP}}
Donc voilà, si tout le monde consent, je le ferai plus tard. — Automatik (discussion) 6 janvier 2014 à 20:26 (UTC)
Si tu veux. JackPotte ($) 6 janvier 2014 à 21:42 (UTC)
En fait le modèle {{interwiktionnaire}} utilise une classe noprint autour du rendu, afin de cacher la ligne qu’il génère dans la version imprimable. Ce ne serait pas possible à ma connaissance de garder cet effet si on sépare l’élément de liste de son contenu. — Automatik (discussion) 3 février 2014 à 14:05 (UTC)
Pourquoi donc noprint est-il utilisé ? — Dakdada 3 février 2014 à 14:59 (UTC)
Je serais d’accord pour le supprimer. Il a été recopié de la version anglophone ({{Interwiktionary}}), qui elle utilise un bandeau. Et elle met aussi "noprint" sur {{Wikipedia}}, donc sur les autres bandeaux de ce type apparemment. Mais pas sur les modèles de liste comme {{PL:pedia}}. Donc pas de raison de le distinguer des autres modèles de liste sur ce point. Sauf avis contraire, j’enlèverai cet attribut. — Automatik (discussion) 3 février 2014 à 15:24 (UTC)
fait. Il y avait déjà plus d’un tiers de {{interwiktionnaire}} avec une puce devant, même si ça ne gênait pas l’affichage. — Automatik (discussion) 18 février 2014 à 18:25 (UTC)