Wiktionnaire:Gestion des modèles/2008

Bonjour, Je suis en train de fusionner l'article jeunesse et il y a dans l'article du DAF, une précision sur la relation entre sens que je ne retrouve pas comme modèle sur le wiktionnaire. Faudrait-il le rajouter ou c'est trop rare que pour en faire un modèle (ou vous avez une autre idée pour préciser cette nuance). Merci, Jona 23 février 2008 à 08:28 (UTC)

J’utiliserais tout bêtement {{sing}} (donnant « (Au singulier) »), puisque le sens collectif est immédiatement apparent puisque la définition commence par « Ceux... ». Urhixidur 23 février 2008 à 15:01 (UTC)

Sauf erreur, il n'existe pas de modèle équivalents à {{Adjectifs substantivés}} (ou en tout cas, je n'ai pas trouvé).
J' ai créé dernièrement carpé ou j'en aurai eu besoin. Une recherche sur adjectif substantivé m'a permis de voir qu'il pourrait être utile dans de nombreux articles → voir gros → voir glouton.
Ne pourrait-on créer un modèle du style

• Modèle:-adj-subst- que l'on pourrait mettre par exemple après le genre sur la ligne d'introduction. Ce qui donnerait (par ex.) :

  Nom commun

  carpé masculin (adjectif substantivé)

  1. (Sport) Au cours duquel le corps doit être fléchi aux hanches, ...

-- ou encore --

• Modèle:-nom-adj-subst-

  Nom commun (adjectif substantivé)

  carpé masculin

  1. (Sport) Au cours duquel le corps doit être fléchi aux hanches, ...

Eric-rogliano 28 février 2008 à 10:53 (UTC)

Cette information est d'ordre étymologique, et doit être mise dans la section {{-étym-}}. → voir carpé Si ce type d'information est donné sur la ligne de forme, ou dans le bandeau "Nom commun", on devrait aussi précisé les adjectifs issus des participes (tassé, etc), les verbes substantivés (déjeuner, etc). Stéphane8888 discuter 28 février 2008 à 13:06 (UTC)

Mais c'est bien sur ! Ça se défend et c'est même très logique ! OK Eric-rogliano 28 février 2008 à 15:14 (UTC)

Pour ce qui est du lien vers les autres wiktionnaires, les modèles trad et trad- se comportent de façon incorrecte quand le wiki ciblé n’existe pas. Par exemple, {{trad-|en|beding}} (beding (en)) aboutit correctement sur la page de recherche du Wiktionary, mais {{trad-|prv|beding}} (beding (prv)) aboutit à la page « prv:beding » du Wiktionnaire français...Peut-on corriger cela ? Urhixidur 29 février 2008 à 16:49 (UTC)

Faisant suite à une discussion ci-avant, je vous propose de vous exprimer : ici. Merci par avance. Stéphane8888 discuter 23 mars 2008 à 18:31 (UTC)

Pour éviter de se répéter maladroitement en répondant aux lecteurs égarés, je propose ce petit modèle {{hors sujet}}. Merci de me dire s'il vous convient. Et n'hésitez pas à l'améliorer. Stéphane8888 discuter 16 juin 2008 à 20:51 (UTC) Voir cet exemple d'utilisation. Stéphane8888 discuter

Je pensais à une modification permettant d’afficher le code langue du mot cible, comme il apparaît dans les sections Traductions, dans le cas où on connaît la langue du mot recherché cela peut aider, mais pour les pages où il y a une brassée de mots, de différentes langues avec une graphie identique ça va faire une liste interminable de codes langues, qu’en pensez-vous ?? Serpicozaure(discuter) 9 juillet 2008 à 09:32 (UTC)

Tu imaginerais donc quelque chose comme bi^{(conv, fr, bm, vo)} avec des liens séparés pour bi, bi#Convention internationale, bi#Français, bi#Bambara, et bi#Volapük ? Ça serait très lourd, surtout au niveau des paramètres. On aurait quelque chose comme {{voir|bi|l1.1=conv|l1.2=fr|l1.3=bm|l1.4=vo}} ! Urhixidur 13 juillet 2008 à 16:35 (UTC)

Autre proposition : Modifier le modèle afin qu’il supprime automatiquement toute auto-référence (c.-à-d. que si un argument correspond à {{PAGENAME}}, il serait omis). Cela permettrait de gérer les longues listes (par ex. {{voir|BI|Bi|bi|bí|bì|bĩ|bỉ|bi-|bì-}} ) à travers une sous-page. Ainsi, la page BI commencerait par {{:bi/Voir}} et cette sous-page commune à tous les articles en bi contiendrait simplement {{voir|BI|Bi|bi|bí|bì|bĩ|bỉ|bi-|bì-}} . Cela simplifierait considérablement l’ajout d’une autre graphie. Par exemple, ajouter b.i. se limiterait à modifier bi/Voir, plutôt que de modifier une à une les pages BI, Bi, bi, bí, bì, bĩ, bỉ, bi- et bì-. Urhixidur 13 juillet 2008 à 16:35 (UTC)

Voilà c’est fait : voir mo. Urhixidur 16 juillet 2008 à 01:28 (UTC)

Pour info et que ça ne serve pas qu’à moi, j’ai bricolé le petit utilitaire {{w}}. Pour un lien identique à son étiquette :

]

on peut maintenant mettre juste :

{{w|Long titre d’article}}

Et il y a lang= si besoin d’une langue (détails sur la doc). Rien de sorcier, voilà. 62.147.39.219 17 juillet 2008 à 03:20 (UTC)

Pourquoi pas, mais note que pour obtenir

]

il suffit de taper

]

--Szyx 17 juillet 2008 à 06:22 (UTC)

Oui mais c'est developpé quand la page est publiée et après on se retrouve quand même avec des semi-remorques comme
]
dans le texte (c'est pour ça qu'il existe généralement un modèle pour le gérer, comme w:en:Template:Wpd qui est partagé sur la plupart des projets anglais, ou le cousin en:Template:w). Enfin, chacun son truc ;-) 62.147.39.219 17 juillet 2008 à 10:30 (UTC)

Et en plus ça ne fonctionne pas s'il y a en plus une spécification de langue. ;=) --Szyx 17 juillet 2008 à 10:40 (UTC)

Ah oui, c'est vrai qu'en plus ] n'est pas correctement développé ; avec une langue il faut vraiment l'un ou l'autre :

]
{{w|lang=en|The Little Prince}}

The Little Prince

The Little Prince

Raison de plus, donc. (Bien qu'à dire vrai, 99% des besoins de {{w}} sont pour lier vers la Wikipedia française.) 62.147.39.219 17 juillet 2008 à 11:09 (UTC)

Il existe par exemple un article se tirer, avec une page de conjugaison Annexe:Conjugaison française/se tirer. Mais cette dernière commence par « se tirer, verbe réfléchi (...) », qui renvoie vers tirer et non se tirer. Ne faudrait-il pas modifier {{fr-conj-1}} et les autres pour qu'ils renvoient à la bonne page ? --Szyx 29 juillet 2008 à 07:09 (UTC)

J’ai plutôt l’impression que s’est se tirer qui est en faute. À mon avis, ça nbe devrait être qu’une page minimale, renvoyant à tirer. Aucun dictionnaire qui se respecte n’a d’entrées classées sous « se... ». Urhixidur 31 juillet 2008 à 12:58 (UTC)

Je ne peux pas dire le contraire, mais il m'avait semblé que sur le Wiktionnaire si : j'ai déjà trouvé des {{créer-séparément}} sur ce genre de sections. --Szyx 31 juillet 2008 à 13:06 (UTC)

PS : juste pour information (pas pour soutenir une opinion) : Special:Index&from=se

ça ne me gène pas qu'il y ait des articles séparés (comme se tirer) et que la définition de tirer comme verbe réfléchi pointe dessus. Au lieu de changer le modèle, on peut (mais c'est plus laborieux) ne changer que la page d'annexe (?). Stéphane8888 discuter 31 juillet 2008 à 21:34 (UTC)

Le plus simple (mais peut-être pas le plus élégant), c’est d’ajouter en tête de l’annexe :

{{cf|se tirer}}<br clear="all">

On peut voir le résultat à Annexe:Conjugaison française/se tirer. Urhixidur 4 août 2008 à 17:47 (UTC)

Les tableaux jusqu’ici gérés plus ou moins maladroitement par les modèles {{(}}, {{-}} et {{)}} pourraient bénéficier de cet élément de code que j’ai découvert récemment :

<div style="-moz-column-count:2">
</div>

Dans ce code on peut substituer un autre nombre de colonnes à "2". Ça permettrait de régler le problème fréquent des colonnes débalancées. Exemple :

<div style="-moz-column-count:2">
* un
* deux
* trois
* quatre
* cinq
</div>

Donne :

Quelqu’un veut-il intégrer ceci aux modèles existants ? Urhixidur 7 août 2008 à 12:13 (UTC)

Le problème c'est que ce n'est pas un code standard (CSS), le "moz" indique qu'elle est au moins prise en compte par Mozilla (et Firefox), mais pas forcément les autres (Opera, IE, Safari, ...). Dans ces autres cas, il n'y aura qu'une seule colonne (ce qui risque d'être le cas de pas mal de personnes, notamment sous IE). - Dakdada (discuter) 7 août 2008 à 16:00 (UTC)

Ah oui, en effet, si je fais basculer Firefox en mode IE, je n’ai plus qu’une colonne. Dommage. Urhixidur 7 août 2008 à 18:39 (UTC)

Note aussi que cette propriété CSS non standard pourrait disparaître à tout moment, si le W3G décide d'approuver l'extension (ce qui semblerait être le cas dans la proposition CSS3 actuelle en cours d'implémentation partielle), sachant que les autres navigateurs n'utiliseront pas ce code d'extension "-moz-" obsolète mais le code approuvé; d'autre part la spécification des colonnes pourrait être différente et pas totalement compatible avec ce qui a été écrit dans le moteur HTML/CSS "Gecko" de Mozilla (utilisé par Firefox). C'est vrai que c'est dommage que tous les navigateurs n'aient pas une extension multicolonnes utilisable, sachant que c'est un élément de base de mise en page dans nombre de publications. verdy_p 6 novembre 2008 à 18:40 (UTC)

Note : il y a toujours en bogue en cours de résolution concernant le rendu par WebKit (par ex. avec Safari, Google Chrome, le navigateur KDE sous Linux, etc.): la position verticale de la cible des notes est calculée en ignorant le fait qu'elles renvoient vers des parties affichées en multicolonnes, donc si la cible est dans la deuxième colonne ou plus, on se retrouve trop bas. C'est un bogue généralement mineur mais qui peut être perturbant s'il y a beaucoup de références de notes, essentiellement sur Wikipédia. Ce bogue est en cours de résolution mais ne devrait pas nous géner. Voir ce qu'il en est sur le modèle w:en:Template:reflist de la Wikipédia anglophone où ce bogue est signalé avec une page de démonstration pour comprendre.

Ce n'est pas un problème de rendu, seulement de positionnement dans la page en cliquant un lien mentionnant une ancre dans la page ; cela n'empêche pas la lecture de l'article ni son impression, mais cela empêche par exemple l'affichage des listes de catégories d'utiliser le rendu multicolonnes automatique, ainsi que l'utilisation de la technique pour améliorer la présentation des portails (l'équilibrage des colonnes doit encore se faire manuellement via un tableau ou des <div> flottants à droite ou gauche, une solution "meilleure" pour ceux qui ont des écrans moins large, par exemple pour le rendu sur l'écran d'un téléphone mobile ou mobile GPS avec connexion Internet mobile, mais encore trop imparfaite). C'est vrai que le web attend avec impatience le support correct du rendu multicolonnes automatique (comme pour les journaux et livres) dans les principaux navigateurs et moteurs de rendus HTML (IE, Mozilla, WebKit).

En attendant une meilleure solution pérenne, il vaut mieux ne rien toucher à ces modèles qui sont un compromis (malgré ses limites concernant la difficulté de maintenance de l'équilibrage et un usage possible qui ne facilite pas la lecture sur écrans peu larges: ne pas mettre trop de colonnes, vérifier que ça s'affiche sans défilement horizontal avec une largeur de 640 pixels environ).

verdy_p 25 novembre 2008 à 11:23 (UTC)

Son paramètre 2 a-t-il vraiment une raison d’être ? Il n’y a aucun exemple de substitution qui me vienne à l’esprit. Urhixidur 10 août 2008 à 19:02 (UTC)

Bon, je le supprime. Le paramètre, pas le modèle. :-) Urhixidur 14 août 2008 à 13:11 (UTC)

Le paramètre titre de {{fr-accord-mixte}} ne fonctionne pas. Je n’ai pas réussi non plus à transplanter le code (pourtant fonctionnel) de {{fr-accord-mf}} à {{en-conj-irrég}} (et en plus le fait d’instruire titre dans ce dernier casse l’alignement du contenu des cellules). Quelqu’un peut-il s’assurer que titre fonctionne ? Moi, je vais me coucher... Urhixidur 15 août 2008 à 03:39 (UTC)

Exemples :

{{fr-accord-mf
|titre=Les barils
|s=baril
|p=barils
|pron=ba.ʁi
|pron2=ba.ʁil
}}
<br clear="all">
{{fr-accord-mixte
| titre=Les pas-barils
| ms=homme
| fs=femme
| pm=ɔm
| pf=fam
}}
<br clear="all">
{{en-conj-rég-s|titre=GB vs. US|pass|inf.pron=pɑːs|inf.pron2=pæs|pp.psuf=t}}

Donne :

Bon, c’est maintenant corrigé. il semble que <br /> et <nowiki /> ne soient pas équivalents. Urhixidur 15 août 2008 à 13:05 (UTC)

Depuis les modifications d'Urhixidur, ces modèles peuvent potentiellement être utilisés pour toutes les langues. Je l'ai par exemple utilisé sur escapar#es-verb, en mettant {{1ergroupe|es}}.

Mais en conséquence, les anciens modèles existants, comme {{1ergroupe-es}} (avantageusement remplacé par {{1ergroupe|es}}) deviennent inutiles.

Devrions-nous entériner cette modification, c'est-à-dire :

1. recatégoriser {{1ergroupe}}, {{2egroupe}}, {{3egroupe}} pour bien montrer qu'ils ne sont pas limités au français ?
2. procéder au remplacement systématique des anciens modèles dédiés à une langue ?

--Szyx 20 août 2008 à 14:49 (UTC)

Moi je suis d’accord, cela va sans dire... Urhixidur 28 août 2008 à 13:15 (UTC)

Bonjour ; le Modèle:Références n'est pas à jour, il ne gère pas le paramètre groupe=. Pour faire des références liées à la partie "Français" de yogi, j'ai dû coder à la main :

Citation.<ref group=fr>Référence</ref>
...
Citation.<ref group=fr>Référence</ref>
...
{{-réf-}}
<references group=fr/>

Mais normalement on utilise {{Références|groupe=fr}} pour faire cela, cf. w:Modèle:Références et w:Aide:Note. 62.147.38.50 22 août 2008 à 22:06 (UTC)

Si je comprends bien, ce paramètre permettrait d’avoir des blocs de références distincts pour chaque langue ? Je vais voir ce que je peux faire... Urhixidur 28 août 2008 à 13:17 (UTC)

J'utilise plutôt {{réf}} et {{RÉF}} que je trouve plus facile à manipuler (on place les références où l'on veut). --Szyx 28 août 2008 à 15:41 (UTC)

D’après la version française officielle d’ISO 639-2, ce code devrait pointer sur oumboundou et non umbundu (graphie anglaise). On corrige ? Il y aurait quelques autres cas du genre, tous faciles à régler car peu de pages sont affectées. Urhixidur 28 août 2008 à 15:17 (UTC)

De 1976 à 1994, l’émission « Yeva Ondaka », un programme chrétien de 15 minutes en oumboundou, a été diffusée chaque semaine par l’émetteur à ondes courtes TWR du Swaziland. . Donc cela me parait juste (et cela fait un exemple pour le futur article :-). --Szyx 28 août 2008 à 15:39 (UTC)

{{umb}} fait. Il y aurait encore (codes a..e, le reste à suivre plus tard) :

• ace : achinais ou atjihais
• ach : acoli ou atcholi
• arn : mapuche → mapoutche
• bas : basa → bassa
• bh : → bhodjpouri

  pas du tout! bh est un code collectif pour le bihari (qui désigne donc un groupe de langues); le bihari comprend entre autres langues le bhodjpouri qui a son propre code bho en tant que langue individuelle ! Voir le site sil.org (ISO 639-3) ou les sites de maintenance de l'ISO 639 pour les détails (et ne pas oublier de consulter les notes concernant les codes modifiés ou retirés, surtout pour l'ISO 639-3 qui est encore jeune et a plein de modifs!). verdy_p 5 novembre 2008 à 04:25 (UTC)

• bi : → bêche-de-mer
• bin : édo → bini
• bla : pied-noir ou siksika
• bug : bugi → bougui
• ceb : cebuano → cébouano
  • ( Réglé Urhixidur 30 août 2008 à 15:31 (UTC) )
• chg : tchaghataï → djaghataï
• cho : choctaw ou chacta
• crg : michif ; on rencontre aussi parfois la graphie mitchif
• del : lenape → lénappé
• doi : dogri ou kangri
• dv : divehi → divéhi
• dz : dzongkha ou bhoutani
• ee : éwé ou éhoué

Il faut décider lesquels changer et lesquels marquer simplement comme orthographes alternatives. Urhixidur 29 août 2008 à 11:59 (UTC)

• alq : algonquin : le code serait plutôt alg
  • ( alq remplacé par {{alg}} Urhixidur 30 août 2008 à 02:18 (UTC) )
    • ERREUR ! L’algonquin c'est bien le code {{alq}}. Le code {{alg}} est un code collectif pour les langues algonquiennes (dont l'algonquin, mais pas seulement, ces langues sont très nombreuses !) verdy_p 6 novembre 2008 à 18:33 (UTC)
    • Corrigé. Urhixidur 7 novembre 2008 à 15:40 (UTC)
• chu, cu : vieux slave : réduire au seul code chu ?
  • ( privilège aux codes de deux lettres : chu redirige sur cu ) Urhixidur 11 septembre 2008 à 02:53 (UTC)
• chv, cv :  : réduire au seul code chv ?
  • ( privilège aux codes de deux lettres : chv redirige sur cv ) Urhixidur 11 septembre 2008 à 02:53 (UTC)
• gil : gilbertin → gilbertais ou kiribatien
• gu : goudjarati ou goudjerate
• gwi : gwich’in ou loucheux
  • ( privilège aux codes de deux lettres : hat redirige sur ht ) Urhixidur 11 septembre 2008 à 02:53 (UTC)
• haw : hawaiien → hawaïen
  • Fait, car la forme « hawaïen » est plus ancienne et plus fréquente d’utilisation. Urhixidur 8 septembre 2008 à 19:43 (UTC)
• hil : hiligaynon → hiligaïnon
• hup : hupa → houpa
• ilo : ilocano ou iloko
• ik, ipk : inupiaq ou inoupiak
• ki : kikuyu → kikouyou
• kj : kuanyama ou ochikouanyama
• kl : kalaallisut ou groenlandais
• kn : kannara ou canara, kannada
• kos : kosrae → kosraéen
  • réglé Urhixidur 31 août 2008 à 12:48 (UTC)
• kpe : kpellé → kpèllé
• ks : kashmiri → cachemiri
• kum : koumyk ou koumouk
• lez : lezghien → lezguien
• lo : laotien ou lao
• lua : luba-lulua → louba-louloua
• luo : luo → louo
• lv : ou lette
• mai : maithili → maïthili
• mal, ml : malayalam : réduire au seul code mal ?
  • ( privilège aux codes de deux lettres : mal redirige sur ml ) Urhixidur 11 septembre 2008 à 02:53 (UTC)
• mas : masaï → massaï
• mic : micmac ou souriquois
• min : minangkabau → minangkabao
• moh : mohawk ou agnier
• mus : muskogee ou mouskogui
• na : nauruan ou nauri
• new : newari → néwari
• nso : sotho du Nord ou soutou du Nord, pédi
• nv : navajo → navaho
• ny : nyanja → nyandja (ou tchitchéwa)
• nym : nyamwezi → nyamwézi
• oj : ojibwa → odjibwé (ou saulteux, sauteux, saulteaux)
• om : oromo ou galla
• orm : oromigna : ce code est aussi le code de l’oromo — est-ce la même langue ?
• pal : pehlevi → pèhlevî
• pam : kapampangan ou pampangan ou pampangueño
• pau : palau → palauan
• ps : pachto → pachtou
• qu : quechua → quéchua ou kitchoua
• rap : rapanui → rapanoui (ou pascuan)
• rar : rarotongien ou rarotongan
• rn : kirundi → roundi, kiroundi
• rom : romani ou tsigane
• sa : sanskrit → sanscrit
• sat : santal → santali
• sco : scots ou écossais
• se : sami du Nord ou sâme du Nord, lapon du Nord
• ses : songhaï ou songoï
• si : cingalais ou singhalais
• sid : sidamo ou sidama
• slv : slovio : ce code appartient au slovène (il n’existe pas de code pour le slovio ; faudra utiliser {{slovio}})
  • ( slv remplacé par {{slovio}} Urhixidur 30 août 2008 à 02:02 (UTC) )
  • ( privilège aux codes de deux lettres : slv (slovène) redirige sur sl ) Urhixidur 11 septembre 2008 à 02:53 (UTC)
    • ERREUR ! le slovio n’est pas le slovène, mais une langue construite (nouvelle) sur une base pan-slave et destinée à être comprise (dans sa forme écrite principalement) par tous les locuteurs de langues slaves qu’elles soient écrites en alphabet latin (comme le slovène, le slovaque, le tchèque, le croate, le serbe, le bosnien, voire aussi le polonais) ou en alphabet cyrillique (comme le serbe, le macédonien, le bulgare, l’ukrainien, le russe), et qui peut être écrite dans les deux alphabets grace à une règle de conversion orthographique bidirectionelle à priori simple et automatisable sans dictionnaire d’exceptions. verdy_p 25 novembre 2008 à 12:33 (UTC)
• sma : sami du Sud ou sâme du Sud, lapon du Sud
• smi : sami ou sâmes, langues laponnes
• smj : sami de Lule ou sâme de Luleå, lapon de Luleå
• smn : sami d’Inari ou sâme d’Inari, lapon d’Inari
• smo, sm : samoan : réduire au seul code smo ?
  • ( privilège aux codes de deux lettres : smo redirige sur sm ) Urhixidur 11 septembre 2008 à 02:53 (UTC)
• sms : sami skolt ou sâme skolt, lapon skolt
• sn : shona ou chona
• ss : swazi ou siswati
• st : sotho du Sud ou soutou du Sud, sésoutho
• sw : swahili ou souahéli
• taq : tamasheq : le code serait plutôt tmh (taq est le code SIL)
  • ( taq remplacé par {{tmh}} Urhixidur 30 août 2008 à 02:09 (UTC) )
    • TAQ (normalement écrit en majuscules pour montrer la distinction) est l’ancien code SIL (utilisé aussi dans l’ancienne édition de The Ethnologue). Ces codes SIL sont définitivement obsolètes, les deux sites utilisant l'ISO 639 exclusivement (avec toutefois quelques codes restants, notamment sur ethnologue.com, qui depuis ont été retirés de l’ISO 639 ; le site de l’ISO 639-3/MA hébergé par SIL.org reste la référence pour la codification, et liste les autres codes ISO 639-1 et ISO 639-2 des langues individuelles ou macrolangues; les sites de l’ISO 639-1/MA, un peu caduque, et de l’ISO 639-2/MA restent en référence pour les codes ISO 639-1 et ISO 639-2/T, ou les codes 639-2/B non utilisés ici, notamment pour les collections de langues bien que la norme ISO 639-5 rendra ces deux références obsolète quand l’ISO 639-5 sera publiée gratuitement une fois son financement assuré)... verdy_p 25 novembre 2008 à 12:49 (UTC)
• tet : tétoum ou tétun
• tkl : tokelauien ou tokélaouén
• tl : tagalog ou tagal
• tn : tswana ou setchwana
• to : tongien ou tonga (des îles Tonga)
• tog : tonga ou kitonga
• tpi : tok pisin → tok pisine
• tsi : tsimshian → tsimchiane
• tt : tatare ou tatar
• tum : tumbuka ou tchitoumbouka
• tvl : tuvalu → touvalouén
• tw : twi → tchi
• tyv : touvain ou touvine
• ug : ou ouïgour
• ven, ve : venda : réduire au seul code ven ?
  • ( privilège aux codes de deux lettres : ven redirige sur ve ) Urhixidur 11 septembre 2008 à 02:53 (UTC)
• vot : vote ou votiak
• wen : sorabe ou wende
• wo : wolof ou ouolof
• wuu, wu : wu : réduire au seul code wuu ?
  • ( code wu inexistant, supprimé ) Urhixidur 11 septembre 2008 à 02:53 (UTC)
• yi : yiddish ou yidiche
• yo : yoruba → yorouba
• ypk : yupik → youpik
• za : zhuang ou tchouang

Urhixidur 29 août 2008 à 19:39 (UTC)

• ses : songhaï : le code est son, en fait (ses est une erreur de la part de ethnologue.com, semble-t-il)
  • réglé.

Urhixidur 30 août 2008 à 02:41 (UTC)

Concernant ces synonymes de noms de langues, je les ai ajoutés parmi les "autres noms=" des sous-modèles "/type" (qui mentionnent aussi les autres synonymes de la norme ISO 639 en français, et certains des noms ISO en anglais parfois rencontrés en français); en revanche je n'ai pas touché aux noms par défaut actuels. Toute permutation de ces noms reste à discuter (et nécessite de créer de nouvelles catégories et rediriger les anciennes), et il subsiste des liens rouges pour ces noms.

Les noms ISO restent mentionnés à titre de comparaison, sous leur graphie dans la version officielle de partie de la norme ISO 639 dont ils sont issus (même si les apostrophes et autres ponctuations ne sont 'pas converties, ou si ces noms de référence sont inverséz... verdy_p 25 novembre 2008 à 13:17 (UTC)

J'ajoute beaucoup de traductions françaises sur le Wiktionary Anglais et ils ont des modèles :

1. d'une part pour les tableaux avec {{trans-top|Reprise de la définition en question}} {{trans-mid}} {{trans-bottom}} qui créent des tableaux enroulables/déroulables.
2. d'autre part des modèles {{t+|code langue|traduction du mot|masculin ou féminin}} et {{t-|langue|traduction du mot}} qui créent des liens internes vers le mot traduit et externe vers le wiktionary de la langue.

Un bon exemple (parmi d'autres) sur en:scythe.

Je trouve ces modèles très bien faits et très pratiques, surtout pour les tableaux qui évitent d'avoir des pages visuellement surchargées pour rien. Donc je voulais savoir si on pouvait éventuellement importer ces modèles pour faire pareil.
AglarEdain 1 septembre 2008 à 13:33 (UTC)

1. Je ne suis pas très favorable aux boites déroulables.
2. Il existe ici {{trad}} et {{trad-}} qui ont un usage similaire (et qui sont liés par interwikis aux modèles sur en:).

--Szyx 1 septembre 2008 à 15:13 (UTC)

Pour le point 2, voir en:Wiktionary:Information desk#Request modification on protected templates. --Szyx 1 septembre 2008 à 15:42 (UTC)

Tu n'as pas compris Szyx: les modèles trad ou trad- ne gèrent pas le multicolonnage, mais des liens vers les autres Wiktionnaires. verdy_p 25 novembre 2008 à 13:25 (UTC)

Pour trans-top, -mid, -bottom, on peut envisager de modifier {{(}}, {{-}} et {{)}} pour obtenir le même effet, avec en prime une utilisation possible non seulement pour les traductions, mais aussi les -compos-, -drv-, etc. Urhixidur 3 septembre 2008 à 02:54 (UTC)

Méfiance quand même pour le code HTML des tableaux qui pourraient à terme devenir un unique <div> de style multicolonne automatique (dans ce cas {{-}} ne générerait plus rien, mais pourait être génant en laissant un saut de ligne parasite après lui qui interromprait la liste à puces) ; quand il sera enfin géré par IE, rendu conforme dans Gecko (Firefox) et corrigé dans WebKit (KDE, Safari, Google Chrome). verdy_p 25 novembre 2008 à 13:25 (UTC)

Ce modèle est encore peu utilisé, et me semble d’usage douteux. La forme pronominale d’un verbe est normalement listée à l’article consacré au verbe lui-même, ce qui fait que les articles pronominaux (par ex. se nourrir pour nourrir) resteront brefs. En fait, je crois qu’il serait préférable d’assimiler ces articles à des flexions (de l’infinitif, cette fois) : ainsi, au lieu de se nourrir, verbe pronominal, on aurait se nourrir, forme de verbe.

Le danger avec le maintien du modèle {{-verb-pr-}}, c’est que ça ouvre la porte à -verb-t- (verbe transitif), -verb-i- (intransitif), -verb-prnl- (pronominal), -verb-déf- (défectif), -verb-réfl- (réfléchi), etc.

Opinions ? Urhixidur 8 septembre 2008 à 17:34 (UTC)

Il y a des verbes qui ne sont QUE pronominaux (rares c'est vrai)... Les définir comme simples verbes est douteux au plan grammatical alors car l'article contient un pronom nécessaire dans son titre, et ce pronom n'est pas un verbe; le pronom doit se retrouver aussi dans la page annexe de conjugaison.

La situation actuelle me convient très bien, et permet aussi dans un article parlant du verbe simple d'avoir une autre section pour l'emploi pronominal, quand celui-ci acquière un sens et un usage particulier (p.ex. "se pouvoir") où le pronom n'est pas le simple objet direct du verbe simple (alors nécessairement transitif) c'est-à-dire quand il ne s’agit pas d'un verbe réfléchi (comme "se mouvoir", "se déplacer"). On peut noter quand même que certains synonymes de verbes réfléchis ne sont pas réfléchis (exemple : "déplacer" (qqch.) ou "se déplacer" peuvent tous deux être synonymes de "bouger" (qqch. ou soi-même), mais pas de "se bouger" qui, bien qu'apparamment réfléchi, est en fait pronominal et nécessiterait un article séparé, et ses propres synonymes comme ici "s’activer", un autre verbe pronominal et un faux verbe réfléchi).

Evidemment il est inutile d'avoir des catégories de verbes intransitifs (s'il y a deux emplois, transitif et intransitif) ce sera sur le même articles avec les sections "Verbe 1" {{-verb-|fr}} et "Verbe 2" {{-verb-|fr}}. On peut cependant regretter que les titres avec numéros ne soient pas assez clairs et préférer alors "Verbe transitif" {{-verb-|fr}} et "Verbe 2" {{-verb-|fr}}, et ces modèles se justifieraient sans que cela ajoute des catégories de verbes (puisqu'ils seraient dans le même article dont le titre est le même verbe simple à l'infinitif). En revanche pas question d'introduire les verbes défectifs dans des sections distinctes.

Les emplois pronominaux de verbes simples (non réfléchis avec un pronom réfléchi constituant le simple objet direct), n'ont pas besoin non plus de leurs articles concernant les flexions de verbes (au contraire éventuellement des flexions de verbes pronominaux non réfléchis comme les flexions de se bouger) verdy_p 25 novembre 2008 à 13:44 (UTC)

La suite dans Wiktionnaire:Pages proposées à la suppression/décembre 2011#Modèle:-verb-pr-. JackPotte ($♠) 21 janvier 2012 à 20:26 (UTC)

Que pensez-vous de ce modèle ? Je l’ai créé après que quelqu’un ait créé la page gsw-fr:Elsässisch en suivant le lien fourni par {{trad-}} à l’article alsacien. Si on n’a pas une meilleure idée (un paramètre nolink pour {{trad-}}, peut-être ?), je vais l’intégrer à l’Aide et l’utiliser pour les autres appels de {{gsw-fr}}, {{ht}}, {{tsolyáni}} et d’autres encore. Urhixidur 9 septembre 2008 à 13:57 (UTC)

Il faut absolument supprimer ce modèle tout de suite, puisque son but est juste de générer un lien normal, il ne sert qu'à donner du travail au serveur. Les modèles trad sont destinés aux cas où il y a un autre wiktionnaire. Et puis, il y a déjà un robot qui s'occupe des modèles trad, on n'a donc jamais à les utiliser à la main : quand on ajoute une traduction, il suffit de mettre un lien normal, et ce sera changé si besoin est, un jour ou l'autre. Lmaltier 11 septembre 2008 à 16:12 (UTC)

Non, le but n’est pas que de créer un lien normal (auquel cas il serait en effet inutile) : il crée aussi et surtout une catégorisation sous Traductions en.... Et en prime, si un wiktionnaire est créé dans une langue jusqu’ici orpheline, il suffit de changer les trad-- en trad ou trad- pour l’accommoder. Urhixidur 12 septembre 2008 à 11:23 (UTC)

Je rumine sur ces questions de charge des serveurs. Si trad-- ne fait que remplacer un trad- déjà en place, il n’y a ni gain, ni perte. Ajouter une catégorisation manuellement est pénible (à cause de la distance entre le bloc -trad- et le bas de la page) et sujet à erreurs. Ce qui pourrait être fait, cependant, serait d’ajouter un paramètre aux modèles {{en}}, {{ht}}, etc. Ce paramètre servirait à déclencher la catégorisation en question. Nous serions alors en mesure de laisser les traductions en liens ordinaires. L’avantage de cette approche est de soulager le serveur quelque peu dans les cas où il y a de nombreuses traductions —quasi-synonymes ou variantes de tournure, etc.— parce qu’on écrirait * {{xx|cat=oui}} : ], ], ] au lieu de * {{xx}} : {{trad--|xx|un}}, {{trad--|xx|deux}}, {{trad--|xx|trois}}. Le désavantage serait passager, puisqu’on aurait à retoucher chacun des modèles de code de langue ; une fois cela fait, il n’y aurait plus de « coût ». Commentaires ? Urhixidur 12 septembre 2008 à 12:57 (UTC)

J'avais parlé trop vite, alors... Mais je serais curieux de savoir s'il y a déjà des personnes qui ont utilisé ces catégories... Pour la dernière question, je ne suis pas sûr de bien comprendre, mais j'ai l'impression que ça ne change pas grand chose aux performances, et que ça complique peut-être les choses pour les contributeurs ? Si on gardait trad--, il suffirait d'adapter légèrement le robot existant. Lmaltier 12 septembre 2008 à 19:45 (UTC)

Une ligne comme :

* {{xx}} : {{trad--|xx|un}}, {{trad--|xx|deux}}, {{trad--|xx|trois}}

(ou avec trad- ou encore trad, ou un mélange, peu importe) se trouve à appeler les modèles trois fois, alors que :

* {{xx|cat=oui}} : ], ], ]

n’utilise que le modèle {{xx}} déjà appelé de toutes façons : on y gagne trois appels de modèles dans ce cas-ci, au moins un appel dans le cas le plus simple.

Si les divers modèles de codes de langue sont surtout appelés dans le cadre des blocs -trad-, alors il vaut peut-être mieux de faire la catégorisation automatiquement, et avoir un paramètre nocat pour les cas où on ne veut pas de catégorisation (comme dans la page listant les codes de langue, ou dans certains blocs -étym-). Comme ça, on aura moins de pages à modifier. Un bot pourrait probablement faire la transition automatiquement (le paramètre suggéré serait ajouté au modèle {{lang}}, et on n’aurait qu’à le passer dans chaque page de modèle de code de langue). Urhixidur 14 septembre 2008 à 01:57 (UTC)

Si je résume ta proposition (j'espère avoir compris) on aurait une section trad du type :

* {{en}} : {{trad|hello}}, {{trad|good afternoon}}, {{trad|good morning}}

* {{nl}} : {{trad-|goededag}}, {{trad|goedemorgen}}

Et il faudrait idéalement réserver les modèles de langues à 2 ou 3 lettres pour les traductions. Sauf à mettre « Vient du {{la|nocat=oui}} '']''. » dans les étymologies. Mieux vaudrait d'ailleurs à ce propos mettre « latin » ce qui chargera moins le serveur et sera plus simple à lire. Stéphane8888 discuter 14 septembre 2008 à 06:09 (UTC)

Pour ce qui est de réserver le modèle de langue aux traductions, 100 % d'accord, c'était l'idée de départ. Et on voit actuellement à cause des autres utilisations des choses du genre Du ancien français.... Je change régulièrement (à l'occasion). Lmaltier 14 septembre 2008 à 06:28 (UTC)

Euh...Si on réserve ces modèles ({{en}}, {{fr}}...) pour les lignes de traduction, alors là tu as raison. On aura donc à ajouter un paramètre nocat, pour des pages comme Wiktionnaire:Liste des langues, Wiktionnaire:Statistiques, les en-têtes des :Catégorie:<code de langue>, etc., ainsi que dans certains modèles clés comme {{-déf-}}, {{babels}} (pour Wiktionnaire:Babel/Modèles), {{Locuteur}}, etc.

Une entrée du genre * {{ht}} : {{trad--|kreyòl}} deviendrait alors simplement * {{ht}} : ]

Urhixidur 14 septembre 2008 à 13:53 (UTC)

D’accord aussi avec le fait de réserver les modèles ({{en}}, {{fr}}…) pour les lignes de traduction. Il y a du pain sur la planche mais simplifier la syntaxe et alléger les serveurs sont deux choses souhaitables. Ce changement (s’il est acté) nécessitera une communication (nouvelle syntaxe), un robot et une bonne coordination (suis dispo pour aider). Stéphane8888 discuter 15 septembre 2008 à 07:46 (UTC)

Voila j'avais demandé une modification de ce modèle à Dakdada, dans le soucis d'éviter des dommages Lmaltier nous a "conseillé" :-) d'aborder le sujet ici.Pour savoir de quoi il s'agit, ceux qui le souhaitent peuvent voir medan, ici et là, voila Serpicozaure(discuter) 25 septembre 2008 à 16:45 (UTC)

• En parcourant cette même page, je m'aperçois ( avec un certain embarras ) que j'avais déja posé la question et qu'Urhixidur avait apporté plusieurs réponses Serpicozaure(discuter) 25 septembre 2008 à 16:55 (UTC)

Si on veut changer quelque chose, je pense qu'il faut commencer par expliquer son objectif, ou bien le problème qu'on veut régler. Ensuite, on peut proposer des solutions (si on en a).

Pour ce cas précis, le but était-il de pouvoir trier dans les mots affichés après voir aussi pour aller voir ces pages de façon sélective en fonction de la langue qui nous intéresse ? Ce qui était proposé n'était pas possible, à mon avis, à moins d'autoriser plusieurs langues pour chaque paramètre, et qu'un robot se charge de les mettre à jour automatiquement. Mais ça complique beaucoup les choses. Une autre idée serait de mettre le bandeau au niveau de chaque langue, mais cela ferait perdre les liens entre mots de langue différente qui s'écrive avec les mêmes lettres et signifient souvent la même chose, ou bien sont de faux amis, et ce serait dommage. Lmaltier 25 septembre 2008 à 17:07 (UTC)

(après conflit de modification) : Je pense comme Lmaltier, que ce modèle sert à "rerouter" le lecteur vers d'autres pages d'articles lorsqu'il s'est trompé (majuscule/minuscule, mauvais accent) ou qu'il ne dispose pas des bonnes touches sur son clavier. Ce reroutage est indépendant de la langue... à moins de vouloir faire un lien vers la section française, un autre vers l'indonésien, etc. Ce qui est, à mon avis, inutile et encombrant. Je pense donc que cette modification du modèle voir n'est pas souhaitable. Stéphane8888 discuter 25 septembre 2008 à 18:44 (UTC)

Pour a part, je rejoins complètement le point de vue de Stephane8888. Pamputt 26 septembre 2008 à 14:15 (UTC)

en accord avec la discussion et le vote ayant eu lieu sur la wikidémie je m'apprête à modifier le {{droit}} dans ce sens ( voir {{géog}} ), j'ai passé en revue la liste des pages contenant le modèle, pour les pages ayant trait à des mots manifestement/visuellemenent étranger j'ai ajouté le code langue correspondant afin qu'elles soient correctement catégorisé, j'ai aussi ajouté le paramètre |nocat=oui pour quelques pages pour lesquelles, grâce à la liste je pouvait présumer que le modèle n'apparaissait pas dans la ligne de définition, toutefois je n'ai pas contrôlé chaque page individuellement, j'attends bien entendu vos réactions avant d'effectuer la modif sur le modèle, en attendant je vais effectuer le même contrôle pour les modèles {{just}} et {{juri}} merci Serpicozaure(discuter) 19 octobre 2008 à 16:56 (UTC)

L’article Aastais est classé en doublon après les z dans la Catégorie:français et ses autres catégories (Noms communs, Gentilés). Problème ? Urhixidur 22 novembre 2008 à 00:39 (UTC)

Un problème de cache ? Je ne vois pas pourquoi il y aurait une erreur sur celui-là et pas sur Aastaise. --Szyx 22 novembre 2008 à 18:24 (UTC)

Je tenterais bien un renommage provisoire et expérimental, eg en Aastais-test, pour voir si le problème suit. --Szyx 22 novembre 2008 à 22:00 (UTC)

Cela ne vient pas du modèle {{clé de tri}} (qui fonctionne parfaitement maintenant) : c'est un bogue dans la base de données qui a une entrée parasite dans son index des catégories (ou bien de MediaWiki lui-même qui rajoute une entrée en plus en parcourant la liste de tri à la fin de sa requête SQL), que même la suppression de la clé de catégorie de l'article (avant recréation) ne parvient pas du tout à supprimer. (j'ai testé, cela n'a eu aucun effet: l'article reste listé deux fois, une fois à sa bonne place, une fois après la fin!)

Cela concerne d'autres catégories aussi (j'en ai noté en parcourant certaines grace au lien "fin" que j'ai ajouté dans les boites de navigation, ce qui a révélé le problème qui existait peut-être depuis très longtemps).

Bogue à signaler sans doûte sur BugZilla, ou correction à faire dans la base SQL... verdy_p 24 novembre 2008 à 00:12 (UTC)

Note bien que l'article Aastais apparaît à la fin dans une section "anonyme" (aucun caractère visible dans le sous-titre de section), ce qui suggère qu'il apparait parce que la base de donnée (ou le code PHP qui effectue la requête) retournerait à la fin de la liste (dans les catégories très peuplées) une entrée vite parasite (ou dont la clé commence par une espace), qu'il vient afficher mais en réutilisant une variable interne contenant le nom de l'article à afficher... Cette entrée affichée est incohérente. Il n'y a AUCUNE clé dans l'article Aastais qui commence par une espace ou qui précise une clé vide, qui de toute façon devrait alors apparaître en début de liste et pas à la fin). verdy_p 24 novembre 2008 à 00:22 (UTC)

Le bogue 16565 a été ajouté à Bugzilla. Urhixidur 4 décembre 2008 à 17:24 (UTC)

Bugzilla indique qu'il n'y avait pas de doublon, mais un second article dont le nom contenait un caractère invisible (un byte-order-mark) au début. Ce caractère est invisible en HTML pourtant il est bien dans le nom. Ceci dit, BugZilla devrait considérer le bogue pour en déduire que MediaWiki devrait supprimer les caractères BOM rencontrés quand quelqu'un crée un article à partir d'un copier-coller ou d'une extraction d'un fichier texte (il semble que l'article a été créé par celui qui a importé Aastais depuis une source stockée dans un fichier texte Windows: le script d'import par Bot a lu le BOM présent dans ce fichier mais ne l'a pas supprimé.). Cet article en doublon est marqué à supprimer rapidement car mal nommé.

Attention à vos Bots d'importation qui lisent des fichiers texte Unicode contenant des données préalablement édités sous Windows (qui stocke un BOM au début): ce script de Bot devrait filtrer le BOM initial s'il est présent. verdy_p 13 décembre 2008 à 10:02 (UTC)

Le mobilien (?) n'est certes pas une langue très commune de nos jours , mais il serait improductif d'attendre d'en avoir besoin.

Jusqu'alors {{mod}} permettait d'afficher un joli lien vers un modèle. Verdy_p vient de le renommer en {{Mod}} (ce qui ne fait pas de mal), mais je crois qu'il faudrait prendre une décision pérenne le plus tôt possible. Les propositions 1 à 3 ci-dessous reprennent les résultats de nos discussions bipartites. NB : Quoi qu'on choisisse, {{mod}} deviendra le modèle de langue, et il faudra un bot pour remplacer tous ses usages passés par le nouveau nom. --Szyx 22 novembre 2008 à 22:35 (UTC)

Note: le renommage date du 7 novembre verdy_p 24 novembre 2008 à 07:27 (UTC)

Tu noteras qu’il y a déjà {{Mod}} (le nom actuellement redirigé) et {{M}} (comme sur Wikipédia)...

Ceci dit je n’ai rien contre, étant donné que l’utilisation actuelle de {{mod}} pose un conflit (mais aucune urgence, cela reste une langue rare). En attendant on peut toujours utiliser {{Mod}} (quitte à le renommer aussi et corriger alors la double redirection qui subsistera pour {{M}}). Comme je te le disais sur ma page de discussion, peu importe le synonyme choisi, on passera un Bot pour ôter les redirections de toute façon (y compris sur les pages de discussions où le modèle est principalement utilisé, mais aussi les pages d’aide des modèles), d’une façon assez simple (impossible à faire à la main, il y en a trop, mais l’expression régulière de recherche et le remplacement sont très simples à faire.) Tout ça pour dire que je n’ai aucune préférence entre les trois, du moment qu’on n’utilise plus {{mod}}. verdy_p 22 novembre 2008 à 22:51 (UTC)

Si tu lis ce qu'il y a écrit plus haut ici, tu constateras que j'ai repris l'essentiel de tes arguments. --Szyx 22 novembre 2008 à 22:55 (UTC)

Avantages : court ; comme sur Wikipédia.

1.  Contre Wikipédia ne différencie pas la casse du premier caractère, c'est une fausse ressemblance (la quasi-totalité de wikipédiens l'utilisent en minuscule). Nous, nous avons déjà {{m}} (masculin), inutile de rajouter à la confusion. --Szyx 22 novembre 2008 à 22:35 (UTC)

Avantages : proche du nom actuel.

1.  Contre Conserver deux modèles qui ne se différencient que par la casse de leur capitale est une source de confusion pour ceux qui ne dorment pas avec Wiktionnaire. --Szyx 22 novembre 2008 à 22:35 (UTC)

Avantages : se lit assez spontanément mod-L (modèle) ; 4 caractères évite tout conflit futur avec les codes ISO.

1.  Pour J'aurais préféré {{mdl}}, abréviation classique de modèle, mais je l'exclus car faisant 3 caractères. --Szyx 22 novembre 2008 à 22:35 (UTC)

   Précision : {{mdl}} est le code ISO 639-3 de la langue des signes maltaise ! Et on a déjà commencé à indexer les langues des signes (c'est vrai, via un autre projet wiki, sur lequel il y a des photos et vidéos). verdy_p 22 novembre 2008 à 22:57 (UTC)

   Attention, l'ISO 639-6 est en préparation (le volet -5 concerne les familles de langues), mais on ne l'utilise pas encore : elle comporte des codes à 4 lettres (peut-être aussi modl) pour une liste exhaustive des dialectes et variétés (orthographes, systèmes d'écritures). Cependant pour coder ces variétés (si on en a vraiment besoin ici), mieux vaut en cas de besoin rester sur un code ISO 639-1/2/3 à 2 ou 3 lettres pour la langue principale, suivi d'un tiret et d'un code à 2 lettres pour un pays, ou 3 lettres pour les autres variantes (garder 4 lettres pour le système d'écriture, 5 lettres ou plus pour les autres variétés). On ne peut pas non plus réserver tous les codes à 4 lettres, et ces codes de variétés ont intéret à rester associés à la langue mère. verdy_p 22 novembre 2008 à 23:08 (UTC)

2.  Pour ça me convient, c'est rapide à mémoriser (1 lettre de plus) et à saisir au clavier. Les propositions précédentes jouent sur la casse et sont donc tout aussi long à saisir. Stéphane8888 discuter 22 novembre 2008 à 23:25 (UTC)
3.  Pour À la réflexion, appuyer sur Shift pour taper le M est aussi long (voire plus) que taper une lettre de plus. verdy_p 23 novembre 2008 à 23:54 (UTC)
4.  Pour Urhixidur 24 novembre 2008 à 16:58 (UTC)
5.  Pour Parce que c'est mieux. - Dakdada (discuter) 25 novembre 2008 à 12:43 (UTC)

   Pas d'opposition pour que je valide le vote sur cette page, et renommer donc "Mod" en "modl" (en changeant les redirections existantes ou faut-il attendre encore une semaine de plus ?

   Je dis : Fonce ! Urhixidur 28 novembre 2008 à 15:49 (UTC)

   Je pense de même, mais je ne l'ai pas dit avant car j'ai l'impression d'être juge et partie. --Szyx 28 novembre 2008 à 20:52 (UTC)

On a d’autres modèles similaires dans nos abréviations d'indications terminologiques à trois lettres :

• {{fam}}{{familier}}, qui génère “(Familier)” devrait être le code langue ISO 639-3 de la langue fam (Ethnologue.com, ISO 639-3).
• il faudrait revoir la liste de ces abréviations ; certaines ne génèrent pas de conflit actuellement, mais peuvent éventuellement en générer plus tard, à l’occasion de la création de nouveaux codes (notamment pour des langues considérées actuellement comme individuelles, mais qui peuvent être soit fusionnées dans un nouveau code, les anciens codes étant retirés et reconsidérés alors comme des variétés dialectales, ou bien être divisés en plusieurs langues individuelles avec pour chacune un nouveau code, l’ancien code étant soit retiré ou reconsidéré comme une macrolangue).
• Concernant nos abréviations terminologiques et modèles à deux lettres, le risque est très faible qu’une abréviation (comme {{vx}}) entre en conflit avec un nouveau code ISO 639-1 (qui est maintenant stable depuis fort longtemps, de même que la partie 2 pour les codes alpha-3 bibliographiques et terminologiques dont beaucoup sont obsolètes ou ambigus, et ne devrait plus avoir de mise à jour), puisque toute la codification actuelle dans l’ISO 639 utilise des codes à 3 lettres dans l’ISO 639-3, et à 4 lettres dans les volets ultérieurs concernant la classification des langues en famille et la codification des dialectes par apposition d'un suffixe à 1 lettre après le code à 3 lettres pour la langue individuelle dont fait partie la variété dialectale, ou 5 lettres plus tard éventuellement.
• Dans le wiktionnaire il suffit de réserver les formes "xx-z" ou "xx-yyy-z" et "xxx-z" ou "xxx-yyy-z" pour ces codes dialectaux à 4 lettres, où "xx" ou "xxx" est un code langue ou code de famille/collection, et "yyy-z" est un sous-code pour la variété (dialectale ou orthographique) de la langue codée "xx" ou "yyy" (par exemple le souletin n’est pas un dialecte mais une variété orthographique ancienne de la même langue, le basque codé "eu" dans ISO 639-1 ou "baq" dans ISO 639-2 ou -3, le code du souletin proprement dit devrait apparaître dans un volet ultérieur de l'ISO 639, sous la forme "baq?" en tant que code de variété, où "?" serait une lettre apposée après le code ISO 639-3 "baq" du basque ; on utiliserait alors "eu-baq-?" ou directement "eu-?", puisque le sous-codet "baq" au début du codet de la variété n'apporterait pas de précision au codet "eu").
• Note: les codes réellement à 4 lettres sont pour la codification des systèmes écritures, comme "Latn" ou "Cyrl" (normalement avec une seule capitale dans la forme canonique du code), mais ces codes doivent normalement être apposés comme suffixes (séparé par un "-") après un code langue (selon la RFC 4646 bis). Cela signifie que les formes à 6 ou 7 lettres (2+4 "xx-yyyy" et 3+4 "xxx-yyyy") ne peuvent pas être utilisées pour coder les variétés dialectales, mais qu'on doit aussi les éviter, sauf si le suffixe à 4 lettres utilisé correspond à un code de système d'écriture.

verdy_p 24 novembre 2008 à 08:14 (UTC)

Une possibilité pour (familier) serait {{fam.}}, qui a l’avantage de suivre la forme de l’abréviation dictionnairique usuelle. Par contre, ce serait une dérogation aux formes auxquelles on est habitués pour les autres modèles du genre ({{vx}}, {{popu}}, etc.). Autrement, on pourrait faire {{famil}}. Urhixidur 4 décembre 2008 à 17:04 (UTC)

Il me semble que ce n'est pas la peine d'attendre plus longtemps : je vais rediriger tous les modèles vers {modl} (en renommant {Mod} vers {modl}). Je vais en profiter pour remplacer toutes les occurrences de {M|}, {Mod|} et {mod|} avec mon bot. - Dakdada (discuter) 2 décembre 2008 à 14:46 (UTC)

Le modèle {{Wikipédia}} dit : « Le modèle {{Wikipédia}} est une boîte flottante qui pointe vers une page de la Wikipédie (française par défaut). On le met généralement sous la rubrique {{=fr=}} (ou autre langue, selon le besoin). » J'ai rajouté : « Note : Cette façon de faire allonge l'affichage de la page, et il est parfois préférable, en particulier lorsqu'il n'y a qu'une section de langue en français, de placer ce modèle directement au dessus de {{=fr=}} de sorte qu'il utilise l'espace vide à droite du sommaire. »

L'idéal serait que cette boîte ne décale pas l'affichage, à l'image de certains modèle. Je vais chercher comment ça fonctionne dans un exemple comme {{fr-accord-mf}}. A suivre donc. Stéphane8888 discuter 23 novembre 2008 à 19:39 (UTC) --> En fait, le décalage ne se fait pas si on place le modèle {{Wikipédia}} dans la section {{-étym-}} (mais ce n'est pas sa place), ou sous le modèle {{-nom-}} (mais il y a déjà pas mal de bandeaux à cet endroit) On pourrait imaginer réduire en hauteur le bandeau affiché par {{Wikipédia}}, mais ça réduit sa visibilité. On pourrait aussi imaginer le placer dans le bandeau de section de langue. Stéphane8888 discuter 27 novembre 2008 à 13:15 (UTC)

Qu'est-ce qu'on fait s'il y a des articles pour la même graphie dans une autre langue, et disposant de leur lien de référence vers leur édition de Wikipédia? Il semblerait logique ce ce lien soit dans la section de langue, non ?

À priori on ne devrait pas rediriger les lecteurs vers des sites non francophones, à plus forte raison Wikipédia. Wikipédia est une encyclopédie, donc on renvoie vers un sujet, pas vers une graphie. - Dakdada (discuter) 24 novembre 2008 à 17:34 (UTC)

Tout à fait, mais les sujets abordés par les différentes sections (et donc les pages de Wikipédia) peuvent être différents. Le cas est encore très rare, mais ça va se développer. Je regarde cette histoire de "décalage". Stéphane8888 discuter 27 novembre 2008 à 10:52 (UTC)

Il m'arrive fréquemment de mettre un lien vers Wikipédia dans la langue du mot, voir par exemple bearnaisesås, je trouve qu ça permet d'appuyer et compléter la définition. J'ai tort ? --Szyx 4 décembre 2008 à 17:12 (UTC)

Non c'est très bien. Puisque c'est dans les liens externes et que la langue est précisée. Stéphane8888 discuter 13 janvier 2009 à 23:37 (UTC)

C'est vrai que certains sommaires peuvent être très longs car il y a beaucoup de langues dans la page.

Dommage qu'on n'ait pas le moyen de changer la forme de ce sommaire automatique et de l'abréger seulement au premier niveau (la liste des sections de langues), de façon aussi automatique (sans avoir à paramétrer un modèle pour faire un faux sommaire dans une page avec __NOTOC__ (ce qui est ingérable pour plsu d'un million d'articles).

Ce serait bien si on pouvait paramétrer le Wikitionnaire pour que par défaut, dans l'espace de noms principal, ce sommaire soit abrégé sous une autre forme (à moins qu'on y insère le mot-clé __TOC__ pour le faire apparaitre sous sa forme normale, ou __SIMPLETOC__ pour forcer la même forme abrégée dans les autres espaces de nom où ce ne serait pas la forme par défaut). Mais je ne sais pas si on doit le demander aux auteurs de MediaWiki, ou s'il faut qu'on le fasse nous même via un javascript qui change la forme du sommaire dans l'espace principal. verdy_p 24 novembre 2008 à 00:05 (UTC)

Ce moyen existe : il s'appelle css (même pas besoin de javascript). Je vais voir si je peux faire un gadget pour ça. Par contre pour en discuter il faudrait ouvrir une nouvelle section, ça me parait hors-sujet. - Dakdada (discuter) 24 novembre 2008 à 17:34 (UTC)

Par vraiment hors-sujet : le sommaire automatique manque de fonctionnalités pour sa numérotation (et il impose aussi des sous-titres distincts pour fonctionner et lier vers la bonne sous-section, ce qui nécessite souvent des redondances dans les titres de sous-sections), pas seulement sa présentation. De plus le CSS ne résoud pas tout pour la présentation.

Le CSS aussi ne saurait pas distinguer non plus les pages (ou espaces de noms) où un sommaire normal est nécessaire, alors que dans les articles de l'espace principal, il est souvent trop détaillé (car on génère trop de sous-sections pour les formes grammaticales, phonétiques, voir aussi, ... au détriment de la présentation des langues). Le CSS pour compacter en multicolonnes peut ne pas marcher non plus pour cause d'incompatibilité (et poser problème si on a placé des éléments flottants à côté. verdy_p 25 novembre 2008 à 14:41 (UTC)

Dans mon monobook.css je peux enlever du sommaire les numérotations (j'ai les ai laissées pour les langues), cacher les sections de niveau < 3, et ce spécifiquement pour les articles (espace de nom principal)... c'est pas suffisant  ? - Dakdada (discuter) 25 novembre 2008 à 14:54 (UTC)

Je viens de créer quelques pages pour les formes verbales à je postposé (« eussé, dussé, fussé, puissé, veuillé » et « aimè » pour l’ortho 1990). Voir aussi les références à {{note-je-postposé}}. Ma proposition est la suivante : devrait-on allonger {{fr-conj}} et compagnie afin de donner la conjugaison interrogative et/ou les autres formes postposées (car il n’y a pas que les interrogatives et interro-négatives) ? Urhixidur 24 novembre 2008 à 17:03 (UTC)

• J'y avais pensé, cependant j'ai laissé cette question en suspend le temps de régler d'autres problèmes plus urgents et complexes à régler dans les conjugaisons. Il n'est pas inintéressant de les noter aussi comme flexions de verbes. A-t-on d'autres cas que le seul imparfait du subjonctif à la première personne du singulier ? Je pense à « Puisse-t-il ne jamais refaire la même erreur ».

  Ici je pencherais pour ajouter dans l'annexe de conjugaison d'un verbe un autre temps "Imparfait postposé" dans la section "Subjonctif", et "Plus-que-parfait postposé" (sous l'imparfait et le plus-que-parfait actuels). Cela concernerait en fait beaucoup de verbes (sinon la majorité quand on considère les temps composés : "chanté-je" (défectif pour les autres personnes à l'imparfait postposé, sauf pour les auxiliaires et peut-être certains verbes exceptionnels), mais en revanche utilisé à toutes les personnes au plus-que-parfait postposé : "eussé-je chanté", "eusses-tu chanté", "eusse-t-il chanté", "eussions-nous chanté", "eussiez-vous chanté", "eussent-ils chanté"... Voir aussi "fassé-je que je ne subisse plus ce genre de choses". verdy_p 25 novembre 2008 à 14:04 (UTC)

• Il faudrait aussi noter que ces temps s'utilisent aussi à la place de l'indicatif présent ou passé composé pour les formes interrogatives et interronégatives), mais pas dans tous les cas (ex: "ai-je chanté ?" et non "eussé-je chanté ?" En revanche "chanté-je aujourd'hui ?") Ce qui revient à jouter aussi ces temps postposés dans l'indicatif (uniquement pour la première personne ?).

  Note: la forme postposée s'impose (plutôt que le subjonctif non postposé introduit par "que") quand le verbe est suivi d'un infinitif ("Puisse-t-il être pardonné.", "Puissé-je recevoir plus de compassion."), c'est-à-dire quand le verbe ainsi conjugué est employé comme semi-auxiliaire. À la troisième personne impersonnelle, le sujet disparait (forme non réellement postposée) quand le verbe (qui sui la même conjugaison que la forme postposée) est suivi d'un subjonctif présent ou passé ("Fasse que je sois pardonné.") verdy_p 25 novembre 2008 à 14:33 (UTC)

D'autre part, les participes présents et passés ne sont pas encore accordés au féminin, y compris dans les temps composés... Ne devrait-on pas corriger ce cas pour "elle" et "elles", quitte à casser un peu l'alignement des conjugaisons aux temps simples non composés (en insérant une ligne blanche entre le singulier et le pluriel) ? verdy_p 25 novembre 2008 à 13:50 (UTC)

Pour. --Szyx 25 novembre 2008 à 23:14 (UTC)

Note: les temps composés avec être s'accordent. Cependant ceux avec avoir n'accordent le participe passé que pour les verbes transitifs et seulment si l'objet est placé avant (ce qui ne peut pas être le cas dans les conjugaisons montrées). Et il y a des exceptions pour "faire" par exemple, quand il est employé comme semi-auxiliaire avant un infinitif) et d'autres introduites par la proposition de réforme orthographique de 1990.

Si on n'accorde pas les participes passés des verbes conjugués aux temps composés avec l'auxiliaire avoir, il faudrait tout de même montrer les accords des participes passés isolés en tête des tableaux annexes (si les verbes sont transitifs ou conjugués avec être).

Pour le participe présent, à moins qu'il soit employé comme adjectif, il ne s'accorde pas (cependant on devrait montrer l'orthographe pour l'emploi du participe présent employé comme adjectif, la seule exception étant pour les verbes impersonnels dont le participe présent reste invariable au masculin singulier, par exemple "pleuvant", "neigeant", etc.).

verdy_p 27 novembre 2008 à 10:50 (UTC)

Voir /Sections modifiables. --Szyx 11 décembre 2008 à 21:43 (UTC)