Discussion utilisateur:Verdy p/archive2

Archives :

• /archive1 (août 2007 – décembre 2008)
• /archive2 (décembre 2008 – avril 2009)
• /archive3 (mai – décembre 2009)
• /archive4 (2010 – 2012)
• /archive5 (janvier – mai 2013)

---

{{Bienvenue}}

Pourrais-tu remettre une taille de caractère normale dans le modèle Bienvenue ? Quand on met ce modèle, on veut qu'il soit lisible. Lmaltier 14 décembre 2008 à 22:33 (UTC)

Oui si tu veux, mais j'ai repris le style des autres boîtes de message... verdy_p 14 décembre 2008 à 22:47 (UTC)

Métadonnées

Est-ce qu’on pourrait voir ensemble pour faire un exemple de page en chinois qui utilise des métadonnées ? Je ne vois pas encore très bien comment tu peux gérer plusieurs romanisations différentes pour plusieurs sections de la page. Si tu veux, on peut essayer ensemble de trouver des solutions, sur 还 par exemple. Koxinga 15 décembre 2008 à 20:10 (UTC)

J’ai donné un exemple dans l’article cité (à voir pour la dénomination des variables : faut-il mettre "nom.langue" ou "langue.nom" ?). Mais ce serait bien que tu me trouves des pages avec des clefs radical/trait différentes pour le chinois simplifié et le chinois traditionnel, et plusieurs romanisations pinyin (mandarin, cantonais, wu) ou romaji (japonais) ou transcriptions en syllabaires kanas (japonais) ou en alphabet hangûl (coréen)...

Je dois dire que les décompositions en kangxi, je ne connais pas. En revanche, il serait bon de compléter les articles avec les transcriptions dans l’alphabet bopomofo (pour le mandarin et le cantonais).

Je peux aussi traiter le cas du coréen (qui devrait utiliser des clés en jamos non composables au lieu de l’orthographe usuelle en jamos composés en syllabes). verdy_p 15 décembre 2008 à 21:04 (UTC)

Justement, ta solution ne traite pas les différentes clés de tri. Il faudrait que parfois 还 soit classé sous huan2 (dans verbes en chinois par exemple), parfois sous hai2, parfois aux deux (enfin ça je sais qu’on ne peut pas dans une catégorie). Dis-moi si ça te paraît impossible, je ne t’embêterai plus avec ça.

Qu’est-ce qui empêche le modèle des verbes de sélectionner une clé de tri pour les verbes et une autre pour les autres usages ? Note: un même article ne peut être listé QU’UNE SEULE FOIS dans une même catégorie. Ce qui fait que si c’est hai2 ou huan2 pour un verbe écrit de la même façon en chinois, je ne vois pas comment tu pourras classer l’article aux deux endroits... Sauf à créer deux articles, un pour chaque prononciation. verdy_p 16 décembre 2008 à 01:24 (UTC)

Note : je ne connais pas le chinois dans le texte, je sais seulement comment cela fonctionne après avoir travaillé depuis des années sur Unicode et la base UniHan (que j’ai déjà mise en œuvre avec succès dans des applications professionnelles).

Si "hai2" ou "huan2" sont deux prononciations pour deux langues différentes du chinois, chacune avec éventuellement un sens différent alors que dans les deux cas c’est aussi un verbe, on peut les distinguer par code langue en utilisant un code plus précis que "zh" qui n’est seulement que le code de la macrolangue (mais référence par défaut et implicitement "cmn" pour le mandarin dans la norme BCP 47): "nan" pour le minnan, "yue" pour le cantonais, "wuu" pour le wu. Donc on peut parfaitement avoir une clé pour chacune de ces langues, même si la clé par défaut pour le chinois [zh] reste celle du mandarin [cmn]. Cette codification des langues pour le chinois est totalement conforme à la norme BCP 47 (et indirectement aux normes ISO 639 qu’elle référence).

Comment l’utiliser dans le Wiktionnaire ? On crée autant de sections de langue que nécessaire : =zh= reste pour le mandarin [cmn], et on crée une section =yue= pour le cantonais, une autre =wuu= pour le wu, etc. Et on utilise alors normalement les modèles pour les noms, verbes, etc. pour chacune de ces langues, chaque modèle recevant le code langue approprié et allant alors chercher la clé de tri pour chaque langue indiquée, et classant les termes dans des catégories distinctes pour chacune (la catégorie pour zh du mandarin sera donc séparée de celles pour le yue, le nan, le wu, etc. et chaque catégorie aura son propre tri) verdy_p 16 décembre 2008 à 01:31 (UTC)

Il n’y a pas d’exemple de caractère n’ayant pas été simplifié mais dont la décomposition en radical ait changé. En fait, chaque dictionnaire choisit ce qu’il veut comme clé et comme décomposition. Nous on reprend la version choisie par Unicode, très proche du dictionnaire Kangxi, sans variante selon les langues.

Ce que je voulais dire c’est qu’effectivement les dictionnaires font ce qu’ils veulent, mais chaque dictionnaire est fait pour une langue chinoise appropriée et dans une convention d’écriture simplifiée ou traditionnelle, en en privilégiant une au détriment de l’autre s’il choisit de mentionner les deux formes. verdy_p 16 décembre 2008 à 01:42 (UTC)

Pour le nombre de traits, il n’y a que quelques rares exemples (comme 残 (chinois) et 残 (japonais). C’est vraiment très rare et je ne sais pas si on doit le prendre en compte dans les métadonnées, même si ça mérite une note explicative. Si on génère des listes ou des catégories avec ces données, comment traiter ce genre de caractères ? Beaucoup de gens le verront dans la mauvaise catégorie quoi qu’on fasse.

Ce que je veux dire est qu’on peut effectivement créer des catégories en fonction des dictionnaires qui référencent et classent ces termes, à condition d’identifier ces dictionnaires selon un code langue éventuellement affiné : par exemple un dictionnaire pour le mandarin classé selon la romanisation pinyin utilisera le code langue standard "zh-Latn-pinyin" (on pourrait utiliser théoriquement "cmn-Latn-pinyin" mais BCP47 précise que "zh" est l’alias recommandé pour "cmn" et désigne le mandarin, même si le code "zh" est parfois utilisé aussi pour d’autres langues chinoises).

Les codes langues à utiliser doivent être utiles et discriminer en fonction des dictionnaires dont on souhaite reprendre la méthode de classification : à chaque méthode son code langue ; on peut en discuter justement pour savoir quels codes langues devraient être utilisés comme suffixe après "clé de tri." dans le nom de la variable. On peut discuter aussi des prononciations qui varient pour un même terme en fonction de son usage grammatical, si le cas se présente... (il faudrait alors utiliser un sous-code de variante pour les natures grammaticales, mais il ne sera pas nécessaire d’utiliser un autre code langue pour la section ni même dans le paramètre du modèle pour les verbes ou les noms). verdy_p 16 décembre 2008 à 01:42 (UTC)

Je ne sais pas ce que tu veux dire par décomposition en kangxi. Kangxi est un dictionnaire (et un empereur, mais on s’écarte du sujet ;o) )

Koxinga 15 décembre 2008 à 21:22 (UTC)

Je veux dire la décomposition en clé primaire et sous-clés secondaire et tertiaire dans la classification kangxi ("cangji" paraît-il en français dans le Wiktionnaire, mais j’ai toujours vu écrit "kangxi" ; je me demande d’où vient "cangji" si ce n’est par une francisation orthographique un peu trop poussée de la prononciation à la française par quelques contributeur voulant tout franciser, y compris des termes finalement très techniques propres au chinois; je m’en tiens à la romanisation pinyin, ou éventuellement Wade-Giles, mais de là à adopter une romanisation "à la française" non appuyée par une norme reconnue...). verdy_p 16 décembre 2008 à 01:24 (UTC)

Je réponds à tout ici, sinon on n’arrivera plus à se lire :

• C’est moi qui n’ai pas été clair. huan2 et hai2 sont tous les deux du mandarin. huan2 est un verbe, hai2 est un adverbe. Dans ce cas, il faut que le modèle verbe inclue un argument supplémentaire indiquant quelle clé utiliser ? Cela ne me paraît pas intuitif du tout.
• Je n’ai pas compris ton passage sur "zh". Tu as toi-même mis dans le modèle {{zh}} que c’était un code de macro-langue. C’est aussi la vision que j’en avais, zh étant pour l’ensemble des langues chinoises et cmn étant le mandarin en particulier.
• Je sais qu’il y a d’autres langues. On n’a pas encore à ma connaissance d’article dans lequel les sens sont différents suivant la langue chinoise considérée mais il y en a, bien sûr. Dans ce cas, il faudra faire une section par langue. La question est, comment faire pour les cas où les sens sont les mêmes, seule la prononciation change ?
  • Indiquer "chinois" avec le code zh et lister toutes les prononciations dans la section prononciation ?
  • Créer tout de même une section par langue, ce qui permet de classer plus proprement et d’extraire plus facilement ensuite toutes les données relatives à une langue ? Concrètement, cela veut surtout dire utiliser cmn partout pour l’instant.

C’est une vraie question que je me pose et à laquelle j’aimerais trouver une réponse avant de faire tourner mon bot. Pour l’instant on suit la première solution, mais je penche de plus en plus vers la deuxième, à l’image du Wiktionary anglais (en:春节). La possibilité d’avoir des clés de tri différentes par langue ajoute un argument pour cette deuxième solution.

• Pour la classification des caractères, tu parles de langues là où je te parle de dictionnaires. Pour l’instant, il n’y a pas de classification normalisée. Chaque éditeur de dictionnaire choisit son jeu de clés et à quelle clé il classe chaque caractère. La plupart de ces ensembles de clés sont des versions un peu simplifiées de celui du dictionnaire Kangxi, mais avec de subtiles différences, y compris entre deux dictionnaires de même langue et même jeu de caractère. Ici, nous n’avons pas besoin de gérer plusieurs tris par clé pour chaque caractère, puisqu’on s’est basé sur celui d’Unicode, prévu dès le début pour contenir des caractères simplifiés et traditionnels, des caractères spécifiques au japonais, etc. Le tri par clé n’est pas lié à la langue.
• Il y a toujours le problème de privilégier l’un à l’autre. Ici on privilégie les clés traditionnelles en considérant les simplifiées comme des variantes. Cependant, et c’est un ajout que j’ai fait récemment, il n’y a pas besoin de connaître la forme traditionnelle ou la forme complète pour se servir du tri par clés.
• Pour cangjie, tu confonds deux choses différentes. Cangjie est une méthode de saisie complètement différente de la classification par radicaux du dictionnaire Kangxi, et le nom est bien en pinyin.

Koxinga 16 décembre 2008 à 11:07 (UTC)

Merci pour la précision sur Cangjie, je ne connaissais pas du tout cette méthode de saisie, et j’ai assimilé à tort le nom de la méthode de saisie avec la méthode de classement et de recherche du dictionnaire Kangxi... verdy_p 16 décembre 2008 à 16:06 (UTC)

Métadonnées redux

Dans la doc du modèle {{clé de tri}}, section Clés de tri spécifiques à certaines langues, tu as mentionné la possibilité de créer des pages /:data et renvoyé à la doc de {{catégorie}} (c’est moi qui ai rajouté une mention au modèle {{métadonnées}}). Or, même si {{catégorie}} dispose d’une sous-page /:data (complètement vide, d’ailleurs), il n’a rien à voir avec l’usage attendu, servant simplement à créer un lien vers une page de catégorie. Pourrais-tu corriger la doc de {{clé de tri}} ? Mais surtout, pourrais-tu créer le modèle manquant ? Car {{métadonnées}} sert à créer /:data, mais on ne sait toujours pas comment écrire une page de catégorie exploitant ces métadonnées.

Je pose la question parce que je caresse le projet de créer des pages de catégories pour le tsolyáni qui utilisent la séquence de tri de ce dernier (p, b, m, f, v, w, t, d, n, th, dh, ch, j, y, k, g, kh, gh, q, ng, h, ’, ts, tl, s, sh, z, zh, ss, r, l, hl, i, a, o, u, ü, e, au, ai, oi). La première étape semble être d’écrire le sous-modèle correspondant clé de tri/tsolyáni, mais il me faudra ensuite savoir comment modifier les pages de catégories visées pour qu’elles exploitent ces clés de tri (et en plus il y a quelques (rarissimes) collisions des graphies tsolyánies avec d’autres langues, ce qui fait que /:data sera nécessaire dans quelques cas). Urhixidur 16 février 2009 à 16:20 (UTC)

Verdy p a renommé {{catégorie}} en {{sous-catégoriser par langue}} à 2008-12-07T19:22:26. Puis, il a créé un autre modèle sous le nom de {{catégorie}}. Ça t’a troublé.

Verdy p, pourquoi as-tu placé {{sous-catégoriser par langue}} dans {{-déf-/2}} ? Je crois que nous devons le placer dans {{=langue=}} et {{-déf-}}. Est-ce que c’est parce que les deux modèles sont protégés ? J’ai essayé des métadonnées pour 中国, mais cette page n’est pas bien triée dans Catégorie:Lexique en japonais de la géographie, parce que {{géog}} n’utilise pas {{sous-catégoriser par langue}}. Il me semble qu’il y a beaucoup de modèles à modifier. — TAKASUGI Shinji (d) 27 mai 2009 à 18:57 (UTC)

{{titre incorrect}}

À quoi peut bien servir Catégorie:Pages avec titre incorrect corrigé ? Ça n’a qu’un intérêt historique éphémère... Urhixidur 16 décembre 2008 à 14:22 (UTC)

Pas du tout ! Tu n'as pas lu la doc, il ne s'agit pas d'enterriner une faute d'orthographe, mais de corriger des caractères qui ne peuvent pas être saisis dans un titre d'article (de type "/" ou ":"). Tu n'as pas saisi l'utilité du modèle qui existe par ailleurs sur d'autres Wikis pour les mêmes raisons. C'est une contrainte technique, pas un signalement d'une erreur ! Cela n'a rien "d"'historique" ni "d'éphémère, c'est au contraire un signalement permanent.

Certes c'est un cas très rare, concernant les mots du dictionnaire qui utilisent très rarement ces caractères réservés mais il existe (moins que sur les autres Wikis qui l'utilisent aussi pour signaler les erreurs de capitalisation, mais ici on différencie les capitales de titre, absentes des titres d'articles, des véritables majuscules présentes dans le titre et distinguées des minuscules initiales). verdy_p 16 décembre 2008 à 15:59 (UTC)

Salut, je comprend le but du modèle mais :

• quelle est l'erreur dans l'article 퀘벡 주 (je ne vois pas de différence) ;

Il n'y en a pas sur cet article c'est juste un essai, il y en a ailleurs en revanche... verdy_p 16 décembre 2008 à 17:36 (UTC)

Note que l'affichage du coréen (ou d'une autre écriture non Latine peu souvent supportée par les navigateurs) avec le style par défaut du Monobook peut poser problème, et pouvoir utiliser le modèle d'écriture {{Hang}} pour indiquer la classe de style CSS "script-Hang" dans la ligne de titre peut être utile pour une visualisation correcte de celui-ci (avec des polices alors personnalisables pour chaque écriture). Dans ce cas il faudrait avoir ici le javascript déjà utilisé sur Wikipédia, pour remettre en forme le titre (si le javascript est présent, la bannière disparait automatiquement après que le titre a été substitué par le javascript). verdy_p 16 décembre 2008 à 17:41 (UTC)

• quel nom (d'article) utilisera-t-on alors pour « . », « M^me » etc. ?

Le nom d'article restera Mme, même si le titre correct devrait être M^me pour des raisons surtout cosmétiques ici. Note que si l'article comporte plusieurs langues, il ne faut pas l'employer dans ce cas pour des raisons cosmétiques, mais mettre la forme souhaitée seulement dans la ligne de forme.

En revanche pour "." il n'y a pas d'autre choix que de nommer l'article différemment, par exemple « Alias . » en utilisant un préfixe constant comme « Alias » avec une majuscule distinctive pour cet usage et une espace séparatrice (ce préfixe devrait être absent aussi de la clé de tri) . verdy_p 16 décembre 2008 à 17:36 (UTC)

N'oublie pas de prévenir les autres contributeurs de cette nouvelle possibilité à discuter, ce qui permettra de l'ajouter dans les conventions. - Dakdada (discuter) 16 décembre 2008 à 17:07 (UTC)

Il faut quand même faire quelques tests avant non ? Je ne l'ai pas déployé massivement.

J’ai commenté aussi la catégorie associée pour décrire l'usage souhaité et celui pour lequel il ne faut pas employer le modèle ; le même modèle existe sur Wikipédia (avec une présentation du bandeau un peu différente, j'ai repris la nouvelle présentation des ébauches d’étymologies). verdy_p 16 décembre 2008 à 17:36 (UTC)

Les tests peuvent être réalisés sur tes pages persos, c'est vivement recommandé. En attendant, merci de ne pas répandre ce modèle avant d'en avoir discuté avec d'autres personnes. Par exemple, dans le cas de Mme, Mme est aussi utilisé (c'est un usage répandu) sans qu'on doive pour autant le qualifier d'« incorrect ». En outre, le bandeau serait peut-être mieux placé dans la section de langue plutôt qu'en haut de l'article. - Dakdada (discuter) 17 décembre 2008 à 11:38 (UTC)

Il y en a déjà 3 avec lesquels j'en ai parlé, ce n'est pas du tout un essai, et je ne vois pas ce que cela ferait dans une page perso !

Je crois que tu n'as pas compris ce que je voulais dire : je parle de pages de test du genre Utilisateur:Verdy_p/test. Et quand je parle d'en parler, ce n'est pas isolément. La raison est toute simple : si chacun fait son truc dans son coin, on va se retrouver avec trois cents façons différentes de traiter la même chose. Par exemple, tu viens d'introduire l'« Alias » sans aucune discussion, alors qu'il pourrait y avoir de meilleures solutions. - Dakdada (discuter) 17 décembre 2008 à 13:14 (UTC)

Je ne viens pas de l'introduire, j'ai proposé une solution dès le début de la discussion ici (c'était déjà dans la catégorie, dans les discussions, même si j'ai complété la doc pour expliquer l'usage, mais on peut toujours en parler, car ce n'est pas encore étendu sur de nombreux articles). J'ai parfaitement compris ce que tu voulais dire par page de test, pas la peine d'expliquer ce que c'est : d'autant que l'utilisation est suivie dans une catégorie, et rend inutile les pages de tests à part, c'est doubler le travail pour rien : c'est très facile à retrouver et la catégorie est encore très peu peuplée. verdy_p 17 décembre 2008 à 13:19 (UTC)

J'ai discuté de deux cas différents de toute façon : celui d'une impossibilité technique et celui d'une graphie cosmétique recommandée (cas des exposants des lettres finales d'une abréviation) ; pour les graphies cosmétiques recommandées (car elles évitent des confusions et différencient bien les lettre initiales et finales) on pourrait avoir un autre modèle, mais j'ai aussi indiqué que si le terme avait des définitions dans plusieurs langues, le modèle ne devrait pas être utilisé, dnoc aucun problème à le laisser en haut de la page pour modifier le titre. L'usage du modèle est en vigueur depuis longtemps sur Wikipédia pour contrecarrer les difficultés techniques.

Tous les guides consultés indiquent que "Mme" est incorrect à cause de la confusion (et c'est aussi vrai pour "Mme."). C'est le même cas en fait que le problème des capitales accentuées ou des apostrophes : on a appliqué les règles hautement recommandées ici (y compris pour l'usage du point d'abréviation), je ne vois pas pourquoi on ne le ferait pas pour les abréviations avec lettres finales! Les articles mentionnent de toute façon aussi les graphies non recommandées quand elles existent. verdy_p 17 décembre 2008 à 11:47 (UTC)

Titre correct en gras

Pourrais-tu modifier ton modèle Modèle:titre incorrect pour que le titre correct apparaisse en gras pour la lisibilité ?
Ex : M^me dans Mme ou ./. dans . / .
-Béotien lambda 17 décembre 2008 à 11:05 (UTC)

Fait ! verdy_p 17 décembre 2008 à 11:06 (UTC)

Discussions

Je veux juste te tenir au courant que c'est parfois vraiment pénible de discuter avec toi. Pas sur le fond mais sur la forme. Tu édites tes commentaires beaucoup trop, y compris après qu'on y ait répondu. Si quelqu'un essaie de relire ça un jour, il n'arrivera jamais à comprendre. Regarde ici : [1].

Des problèmes de mise en forme du code, un peu délicats à régler car un peu lourd à écrire. verdy_p 17 décembre 2008 à 16:53 (UTC)

(et accessoirement tu as supprimé le paragraphe que je venais d'écrire ...)

Non je l'ai copié !~(conflit sur une édition, mais j'ai gardé ton paragraphe) verdy_p 17 décembre 2008 à 16:53 (UTC)

Koxinga 17 décembre 2008 à 16:46 (UTC)

il appert que

Pourrais-tu modifier le modèle Modèle:fr-verbe-flexion pour avoir la forme 3ème personne du singulier de l'indicatif présent il appert (uniquement le masculin) et non il/elle/on appert comme tu peux le voir sur appert ? -Béotien lambda 18 décembre 2008 à 12:45 (UTC)

Tu veux dire ajouter les paramètres pour le mode impersonnel je suppose ?

Je vais le faire, mais pour l'instant je corrige des défectivités partielles trouvées pour certaines personnes (verbes normalement employés uniquement au pluriel, notamment la plupart de ceux avec le préfixe entre- (accolé dans l'orthographe de 1990, ou joint au radical par un trait d’union ou une apostrophe), employés en plus sous forme réfléchie non transitive (où l'objet n'est pas l’agent, donc pas d'accord des participes non plus : « elles se sont entretué » : l’une tue l'autre mais pas elle-même, et non pas « elles se sont entretuées » ; en revanche, on doit accorder « elles se sont entresuicidées » car chacune se tue elle-même, « entre » signifiant ici « toutes ensembles dans une action concertée ».)

L'usage permet parfois l'accord transitif dans un sens très figuré mais d’un sens très inhabituel, la faute de grammaire consistant à accorder le verbe comme un verbe pronominal normal étant assez courante car malconnue pour ce type de verbe (pour savoir si l'accord du participe se fait, il faut connaître le sens du pronom réfléchi en fonction du verbe et déterminer quel est l'agent). Les sens très figurés étendant l'objet à l’agent sont très inhabituels (voire carrément un contresens ou contradictoire dans le sens habituel), raison suffisante pour griser ces formes. verdy_p 18 décembre 2008 à 13:03 (UTC)

Je vois que tu t'es débrouillé tout seul. J'ai juste ôté le premier appel superflu au modèle sans paramètre, le second avec ind.p.3s suffit... Mais effectivement il faudrait faire disparaître elle/on avec un paramètre "impers=oui" comme dans les tables de conjugaison).

Note : la gestion des verbes pronominaux en s’entre- est un peu plus compliquée que je le pensais au départ, je viens de régler partiellement le problème (la complexité vient du fait que certains sont en plus intransitifs, suivant la nature grammaticale du pronom réfléchi avant le verbe qui peut est direct ou indirect, et suivant le fait que, lorsqu'il est direct, celui ci a un sens singulier (agent différent de l'objet) ou pluriel !

À cela s'ajoute la gestion des deux orthographes rectifiée de 1990 et traditionnelle pour la soudure ou non du préfixe entre- !

J'espère que mes modifs sont lisibles dans la conjugaison de s’entre-détruire et s’entredétruire (transitifs) et s’entre-nuire et s’entrenuire mais il y a de même des tas de verbes à vérifier en entre- dans le premier groupe comme s’entre-tuer et s’entretuer, s’entre-déchirer et s’entredéchirer. Il va falloir reprendre au minimum la liste donnée dans l'annexe de l’orthographe rectifiée de 1990.

Il me reste à griser certains accords des participes passés seuls (à griser au masculin et féminin pluriel pour les verbes transitifs dont l'objet direct n’est pas l'agent, alors que le verbe ne s’emploie pourtant normalement qu’aux personnes du pluriel (avec un participe passé normalement au singulier) !!!

Pourtant, avec ces mêmes verbes, l'emploi du participe passé en tant qu’adjectif épithète s’accorde bien au pluriel !!! Voilà un cas complexe que je n'avais pas prévu (faut-il accorder entredétruit ou pas ? oui en tant qu'adjectif, non en tant que participe passé d’une conjugaison aux temps composés). Je suppose que dans des cas comme ça, il y a une tolérance, mais je voudrais bien l'avis d'un linguiste (on doit accorder selon le principe du COD placé avant le verbe, mais une autre règle relative aux verbes pronominaux dit le contraire concernant le pronom dont l’objet n'est pas l’agent ; de plus, dans le cas des adjectifs épithètes ils sont généralement placés après le nom avec lequel ils s'accordent (ce qui est ici finalement très flou et très trompeur car les verbes pronominaux se conjuguent avec l'auxiliaire être qui les fait ressembler à des adjectifs), et dans cet usage (épithète) la différence entre transitifs et intransitifs disparait (normalement les participes passés des intransitifs ne peuvent être employés comme épithètes, mais on trouve des tas d'exceptions, comme ici entrenui participe passé intrinsitif donc invariable de s’entrenuire qui ne devrait pas être utilisé comme épithète !). verdy_p 19 décembre 2008 à 06:06 (UTC)

Bon je crois avoir réglé les derniers problèmes. J’ai cherché des bogues pendant un moment avant de trouver, d’où plus de modifs que je l'aurait voulu dans le modèle {{fr-verbe-flexion}}, à la recherche d'un commentaire pas fermé, alors que c'était un problème d'accolade en surnombre, qui faisait aussi s'afficher incorrectement un masculin singulier pour le participe passé.

Le paramètre impers=oui est géré (regarde apert) ; il peut être utilisé aussi bien pour le singulier que le pluriel, qui sont à priori des flexions distinctes. On ne doit pourtant pas l'employer pour pleut et pleuvent qui s’emploient aussi de façon personnelle à la troisième personne (même si les premières et secondes personnes ne sont pas usitées).

Au passage le modèle détecte maintenant les autres formes du subjonctif, et nettoie la catégorie des flexions de verbe à vérifier pour le subjonctif présent (pour le cas du second groupe où elles étaient correctes), grace à la détection du passé simple (dont la présence commune avec l'indicatif présent est spécifique au second groupe mais ne demande pas la mention du subjonctif présent toujours différent) ; dans cette catégrorie, il ne resterait alors que as qui est correctement distingué (à l'indicatif présent, mais pas au subjonctif présent), et d'autres verbes irréguliers comme peux, et pour éviter ce signalement j'envisage d'ajouter le paramètre grp=3, ce qui permettra d'autres vérifications de cohérence sans déclencher cette "alarme automatique". verdy_p 21 décembre 2008 à 05:09 (UTC)

Merci pour ta réponse et ton intervention sur appert. -Béotien lambda 4 janvier 2009 à 06:46 (UTC)

s’entredéchirer

Le verbe s'entredéchirer est purement pronominal.

Je le sais ! Et c'est bien ce qu'indique la définition, et la classification grammaticale avec {{-verb-pr-}} et non {{-verb-}} ainsi que la ligne de forme en dessous, qui adopte les conventions communes à tous les verbes pronominaux. verdy_p 19 décembre 2008 à 08:35 (UTC)

1. Il n'est pas logique de faire une redirection de s'entredéchirer vers entredéchirer (c'est l'inverse qu'il faut faire)

   Non, car le pronom n'est pas partie du mot et est mutant, et non car le classement se fait sur la racine du verbe, jamais sur le pronom, et non car on ne le fait pas pour tous les verbes qui peuvent être pronominaux ou non. Et non enfin car on ne le fait pas non plus sur les flexions des mêmes verbes (notamment les participes). verdy_p 19 décembre 2008 à 08:33 (UTC)

   On n'est pas ici sur le petit Larousse du béotien lambda qui classe entredéchirer entre entrecuisse et entre-deux, sous la forme ENTRE-DÉCHIRER (S’). Avec l’informatique, on peut se permettre de faire une page correcte libellée "s’entredéchirer" et une redirection depuis entredéchirer qui n'a pas de sens avec une page qui lui est consacrée même si le contenu concerne s’entredéchirer. Pourquoi ne pas être rationnel sur ce projet qui ne nous dit pas de copier les dictionnaires existants mais d'être un outil efficace de diffusion de la connaissance ? -Béotien lambda 19 décembre 2008 à 10:10 (UTC)

   Qui n'a pas de sens ? C'est faux ! Il a bel et bien un sens dans une forme non pronominale (voir ci-dessous et référence donnée). Évidemment le sens le plus courant est sous une forme pronominale (plusieurs possibles, pas seulement avec s’). Mais le fait qu'on ne cite pour l'instant qu'une définition pronominale ne démontre pas que les autres formes sont impossibles (si on ne donne pas de définition c'est par manque de définition dans les mêmes références qui citent pourtant cet usage non pronominal mais sans le définir). verdy_p 19 décembre 2008 à 12:05 (UTC)

2. La conjugaison doit être dans s'entredéchirer et doit porter le nom Annexe:Conjugaison française:s’entredéchirer

   Même remarque, non. verdy_p 19 décembre 2008 à 08:33 (UTC)

   Même logique-Béotien lambda 19 décembre 2008 à 10:10 (UTC)

3. Dans la même logique, les flexions (entredéchireraient, par exemple) doivent faire référence au verbe s'entredéchirer et non entredéchirer qui ne veut rien dire.

   Même remarque, non. verdy_p 19 décembre 2008 à 08:33 (UTC)

   Même logique.-Béotien lambda 19 décembre 2008 à 10:10 (UTC)

Béotien lambda 19 décembre 2008 à 07:34 (UTC)

Cela veut dire quelquechose : le terme existe en temp que mot distinct, même si son usage est restreint au mode pronominal (mais là encore le pronom n'est pas nécessairement "s’", il varie, même pour l'infinitif). On classe dans le Wiktionnaire les mots, pas leurs emplois (qui en plus ici est variable), et dans le cas présent ce n'est pas non plus une locution (qui justifierait qu'on garde deux mots dans le titre). Le verbe est bien "entre-déchirer", le pronom est un complément d'objet (même s'il est nécessaire) et un mot distinct avec son propre sens et le pronom des verbes pronominaux ou réfléchi change de nature grammaticale (réfléchi, objet direct ou indirect, parfois même distinct du sujet) suivant les verbes. verdy_p 19 décembre 2008 à 08:33 (UTC)

Je voudrais ajouter que la notion de "purement pronominal" est dépendant d'une restriction d'usage (je ne veux pas préjuger que cette restriction soit observée strictement partout). Rien ne garantit que ce soit le cas dans tous les cas (même si l'usage actuel est certainement presque toujours pronominal). Pour tous les pronominaux on a choisi partout de ne garder que le verbe seul, quitte à mettre plusieurs sections pour les différents usages du mot (verbe simple ou verbe pronominal) dans la définition et plusieurs sections aussi dans l'annexe de conjugaison (sections qui peuvent réutiliser le même modèle de conjugaison en lui adjoignant un paramètre "réfl=oui" pour la partie pronominale. verdy_p 19 décembre 2008 à 08:51 (UTC)

Ce système est également celui le plus simple pour gérer les liens entre articles (y compris pour les flexions), ne serait-ce que pour le tri des entrées dans les catégories.

Ces redirections du mode pronominal vers le verbe simple ne produisent aucune ambiguïté, l'article (définition ou annexe de conjugaison) vers lequel pointe la redirection mentionnant bien l'usage correct le plus courant (peut-être le seul mais ce n'est pas si sûr : on a vu nombre de verbes réputés « purement » pronominaux utilisés aussi sous leur forme non pronominale, de même qu'on a vu des verbes théoriquement impersonnels utilisés de façon personnelle, par exemple pleuvoir qui peut aussi se conjuguer aux autres personnes dans certains usages). verdy_p 19 décembre 2008 à 08:59 (UTC)

Pour terminer, il faut ajouter que le verbe entredéchirer (ou entre-déchirer) a bel et bien un sens dans le mode non pronominal, en tant que verbe transitif, celui « d’entrouvrir (ou entr’ouvrir) en déchirant », ainsi que le sens figuré associé (pour parler des termes restrictifs d’un contrat ou d’un accord ou d’une convention, qu’on accepte de relâcher partiellement, et aussi dans le cadre légal et juridique ou législatif dans le langage parlementaire). Le préfixe entre- dans ce cas n’établit pas (comme dans le mode pronominal) de relation d’agent à objet parmi les objets du verbe induits par le pronom, mais celui de « partiellement » avec également la notion figurée relative au fait que l’on a glissé quelquechose dans un contenant entre ses plis qui le scèlent.

Raison de plus pour garder le mot seul dans l’article principal, comme on le fait pour les autres mots où on a mis dans le même article toutes les définitions dans toutes les langues, quelle que soit leur nature grammaticale (plusieurs sous-sections par nature grammaticale), et leur usage. Cela n'empêche pas de créer des redirections pour le verbe à l'infinitif avec le pronom se ou s’ (également s' pour faciliter la saisie) car c’est un usage très fréquent mais pas du tout obligatoire.

Mais on ne va pas non plus créer des redirections pour tous les pronoms qui peuvent remplacer celui-ci dans le cas des verbes pronominaux (qu'ils soient réfléchis, transitifs directs, transitifs indirects avec même parfois des sens différents suivant la préposition qui précède l'objet indirect ou qui se contracte avec lui, tels que "y", "en", "dont", "au", "aux", "d’", "duquel", "desquels", etc.) : dans tous ces cas là, on se retrouve à chercher le verbe simple (et on s’attend alors à voir l'usage pronominal mentionné au minimum dans une section très claire de l'article, mais pas nécessairement dans son titre où le pronom se ne correspond pas forcément au pronom effectivement utilisé). verdy_p 19 décembre 2008 à 10:10 (UTC)

Je ne suis pas d'accord avec ta conception. J'en ai constaté la limite dans de nombreuses pages. Voir Discussion Utilisateur:Béotien lambda#verbes pronominaux. Tu ne peux pas modifier le projet à ta façon comme ça te chante sans l'avis de la communauté. Je suis prêt à défendre mes arguments. Arrête de tout modifier et lançons une discussion avec vote.- Béotien lambda 19 décembre 2008 à 10:19 (UTC)

Je vois que tu me mènes à une discussion informelle sur ta page personnelle, cependant je n'ai pas "tout modifié" concernant les usages actuels, puisque c'est toi qui est intervenu pour modifier ce que j'avais écrit (selon ta propre convenance) et qui correspondait pourtant parfaitement à l'usage actuel le plus fréquent. J'ai des arguments nombreux (ci-dessus) pour ne pas mettre le pronom dans le nom de l'article.

Note que cette façon de faire ne produit AUCUN mélange dans les traductions (comme ce que suggère la discussion sur ta page perso). On a déjà pris la décision de scinder les listes de traductions par usage, pour ne pas les mélanger (et d'abandonner en même temps les numéros de référence qui sont illisibles).

On peut très bien mettre l'usage ponominal et l'usage non pronominal dans le même article, et il n'y a aucune confusion puisqu'on a {{-verb-}} et {{-verb-pr-}} pour faire la distinction (de même qu'on a aussi {{-nom-}} pour les verbes qui peuvent aussi être des noms comme déjeuner.

Franchement je ne vois aucune des « limites » dans les pages que tu voudrais indiquer ici (lesquelles ?).

Un mot est un mot (le même dans toutes les langues), il désigne sa forme orthographique(celle qu’on trouve dans les mots croisés par exemple), indépendamment de sa nature dans une langue donnée ou de son sens ou son usage. On met des articles principaux sur les formes orthographiques exactes de ces mots (donc des articles séparés pour les flexions), mais pas sur leurs usages puisque l’article est là justement pour permettre de les distinguer dans la même page (sauf pour les locutions mais ce n'est pas du tout le cas ici), et on distingue ensuite les langues, natures grammaticales et usages dans les articles : c'est encore plus vrai quand on voit que la notion de "verbe pronominal" est finalement très vague voire ambigüe en français, car il faut compléter par "réfléchi, transitif, transitif indirect" pour réellement définir la nature grammaticale et les règles d'accords du participe, et même parfois ce n'est pas encore suffisant ; la seule chose que ça indique c'est l'utilisation de l'auxiliaire être dans les conjugaisons, où de toute façon le se (ou s’) va devoir être muté en d’autres pronoms personnels. verdy_p 19 décembre 2008 à 10:35 (UTC)

À la limite je pourrais concevoir que l'article s'appelle entredéchirer (s’) comme le fait le TLFi/Atilf. [2]. Le CNRTL, à la recherche "entredéchirer" renvoie à "se entre-déchirer" [3] ce qui est choquant, non ? Mais leur page s'appelle ENTRE(-)DÉCHIRER (S’). À mon avis il faudrait que le titre dans notre page soit s’entredéchirer ou entredéchirer (s’) mais pas entredéchirer seul. -Béotien lambda 19 décembre 2008 à 11:14 (UTC)

Non, ça ne me choque pas du tout ce que fait l'ATILF ou le CNRTL (correction dans ce que tu dis : il indexe "entre(-)déchirer" pas "se entre(-)déchirer" comme le montre le lien sur le CNRTL : http://www.cnrtl.fr/definition/entredéchirer) est exactement ce qu'on fait aussi ici très majoritairement dans les articles : il classe aussi le mot seul, et mentionne dans une ligne de forme le pronom comme une précision supplémentaire pour distinguer les usages (regarde à "aimer" par exemple où il y a deux sections séparées pour aimer et aimer (s’). Je ne suis pas favorable aux parenthèses dans les titres d'articles ( l'ATILF ou le CNRTL ne le font pas non plus !) étant donné l'ambiguîté relative du terme "pronominal" qui ne se rapporte guère qu'à la présence d’un pronom (variable, raison pour laquelle il le cite uniquement entre parenthèses après le terme sur la ligne de forme) et l'indication de l'auxiliaire être pour les formes composées, mais ne précise pas la nature grammaticale du pronom.

Et je le répète, puisque tu ne l'as pas vu, il y a aussi un usage transitif direct non pronominal pour ce verbe (pas encore recensé par l'ATILF, mais trouvé dans le langage verbal courant et sans doûte dans des articles ou livres, il reste à les retrouver). C'est bien ce que dit la page du CNRTL en mentionnant les formes non pronominales entre parenthèses pour les usages peu fréquents, mais sans donner de définition).

Vouloir scinder les articles en deux articles distincts (sur une base aussi floue, notamment pour les verbes ayant un usage transitif direct comme ici) me choque davantage étant donné le caractère flou du mot pronominal (et aussi car l’étymologie, la prononciation, la conjugaison et très souvent une grande partie du sens sont communs), et le fait que cela ne permet pas de lever des ambiguïtés d'usage au sein du même article où figurent toutes les définitions et usages et toutes les natures grammaticales (pas seulement le verbe mais aussi le nom, un cas très fréquent tel que dans déjeuner). verdy_p 19 décembre 2008 à 11:25 (UTC)

Pour donner un exemple plus significatif et plus proche de notre problématique, il y a s’entrechoquer, le plus souvent pronominal mais qui admet aussi l’usage non pronominal entrechoquer. On est exactement dans le même cas sauf qu'on peut donner facilement une définition inconstestable et des références suffisantes d’usage dans des textes (livres, articles) pour entrechoquer en tant que verbe transitif non pronominal. Là encore, on a une grande partie du sens commun, de même qu'on a une étymologie commune, et une prononciation commune, ainsi qu’une conjugaison commune (à l'auxiliaire près uniquement pour les temps composés, mais avec les mêmes formes de participes passés qui peuvent s'accorder dans les deux cas). Un même article pour les deux usages (très proches) se justifie parfaitement, de même qu'une même feuille de conjugaison, où peuvent figurer à la fois la conjugaison pronominale la plus courante et la conjugaison non pronominale du verbe transitif. verdy_p 19 décembre 2008 à 12:21 (UTC)

Je ne semble (peut-être) pas le seul à penser ce que j'ai dit plus haut.

J'ai pris des verbes pronominaux avec des formes pronominales commençant par se.

Je constate que les articles de l'échantillon ont été créés par divers contributeurs dont certains sont bien connus, et que par ailleurs ces mêmes articles ou d'autres ont été modifiés par des Lmaltier, Pamputt, Urhixidur... sans qu'ils remettent en cause la dénomination se <---> qui ne les choquait apparemment pas.

16@r se barrer (11 mars 2008), se taper (29 avril 2008)

GnunuX se biler (24 mars 2007)

Lachaume se manquer (20 septembre 2007)

Serpicozaure se contenir (24 avril 2008), se grouper (25 avril 2008), se rassembler (25 avril 2008), se réunir (20 avril 2007)

Stephane8888 se bidonner (25 juillet 2006), se corser (7 mars 2007)

Il n'ont sans doute (comme moi) rien compris au problème ?

Ce serait très utile que tu complètes (ou modifies) Annexe:Conjugaison française:Verbe pronominal ou que tu fasses des propositions car ce serait bien de faire passer l'administratif avant le technique. Or tu travailles le technique (avec aisance et compétence) sans que les règles aient précédé et aient été acceptées. Il faut voter la loi avant de l'appliquer, non ? -Béotien lambda 19 décembre 2008 à 13:13 (UTC)

Justement j'ai appliqué les règles majoritairement en vigueur (la liste dans Catégorie:Verbes pronominaux en français est très longue où les verbes sont presque tous indexés avec un titre SANS le pronom (hormi une poignée, souvent injustifiée car le même verbe non pronominal est parfois aussi présent dans cette catégorie, à cause d'articles mal fusionnés ou simplement oubliés) !

Je n'ai donc rien changé du tout à ce qui se fait déjà depuis longtemps. La très grande majorité' des articles ne sépare pas les définitions pronominales des définitions non pronominales dans des articles séparés (et je trouve que c'est avec raison quand on voit comment ils se définissent, s’utilisent, se prononcent et se conjuguent, la délimitation des sens étant en fait assez floue et permettant de plus en plus souvent d’utiliser la quasi-totalité des pronominaux comme des verbes simples).

Je peux aussi te citer les mêmes auteurs qui y ont contribué très largement (et même bien plus souvent !).

Il est bien plus utile en fait dans les articles d’utiliser {{-verb-pr-}} pour faire un peu le tri dans les définitions (en abandonnant complètement {{pronl}} et {{prnl}} devenus inutiles sur les lignes de forme ou devant les définitions numérotées) mais de mentionner plutôt sur la ligne de forme si (dans les deux cas: verbe simple et verbe pronominal) ils sont transitifs ou non (car justement un verbe peu être transitif direct ou indirect sous sa forme simple, et intransitif lorsqu’il est réfléchi; on a aussi parfois aussi les deux formes transitives et intransitives dans chaque cas, ou bien aussi l’inverse), et dans le cas des pronominaux transitifs (en plus) s’ils sont réfléchis (le participe passé s'accorde toujours avec le sujet) ou réciproques (car cela change les règles d'accord pour savoir s’il faut ou non appliquer l'accord du pluriel au participe passé, les deux étant possibles pour le même verbe réciproque selon ce que désigne le pronom). verdy_p 19 décembre 2008 à 13:24 (UTC)

Je soutiens ce que dis Béotien lambda : il n'y a pas eu de règle établissant l'usage. Je te recommande donc de synthétiser tes arguments dans une discussion générale afin que l'on puisse mettre ces règles au point, plutôt que de continuer à faire ça dans ton coin. - Dakdada (discuter) 19 décembre 2008 à 13:38 (UTC)

Je n'ai pas fais ça "dans mon coin", les exemples sont nombreux et vous avez tous fait bien plus d'articles avec des articles uniques, en séparant seulement les usages, soit avec des définitions utilisant {{pronl}} obsolète, soit avec des lignes de forme supplémentaires avec {{prnl}} (pas clair car cela ne classe pas le verbe), soit avec le modèle {{-verb-pr-}} qui rend les deux autres modèles obsolètes. Le nombre d'articles concerné est très largement en ma faveur, et vous y avez tous contribué bien avant moi. Bref je ne vois pas du tout ce qu'on peut me reprocher ici, puisque vous dîtes vous-même qu'il n'y avait pas de règle clairement établie (et aussi une grande méconnaissance des règles d'accords des participes, plus complexes que ce que peuvent mentionner des annexes incomplètes). verdy_p 19 décembre 2008 à 13:49 (UTC)

Pour l'article porter par exemple, ne serait-il pas mieux qu'il y ait à part un article se porter pour plus de clarté. Tu vas d'ailleurs me dire à quels sens de porter ou se porter correspondent les traductions -Béotien lambda 19 décembre 2008 à 13:39 (UTC)

Note : le dictionnaire de l'Académie (importé) mélangeait les deux usages (pronominal et non pronominal), et il le fait toujours dans les éditions récentes ou l’édition en cours (car cela lui permet de rapprocher les sens communs aux deux usages).

Voir aussi aimer (le dico académique y classe aussi s’aimer, au milieu des autres définitions non pronominales, j'y ai remis un peu d'ordre, mais je n'ai pas scindé l'article pour autant, tellement les sens sont proches). verdy_p 19 décembre 2008 à 13:54 (UTC)

On peut voir que ceux qui ont tenté de séparer les entrées (ici dans le Wiktionnaire ou dans d’autres dictionnaires) se sont cassés le nez en créant des redondances de définitions, pas cohérentes entre les articles, où on trouve des exemples pronominaux pour des définitions de verbes simples, sans compter des tas d’impairs et d’oublis ! verdy_p 19 décembre 2008 à 13:24 (UTC)

Si maintenant vous voulez scinder les articles et les titrer avec le pronom, il faut le faire pour TOUS les verbes pronominaux et TOUTES les annexes de conjugaison. Il faut être logique !

Je vous souhaite bon courage car cela représente des milliers d'articles à scinder et des milliers d'annexes de conjugaison à créer ou scinder aussi (sans oublier de dupliquer les étymologies, les références, les pronociations, etc... entre les deux articles, sans oublier non plus de les lier l'un à l'autre). Je ne suis même pas sûr que cela sera plus clair quand il sera tentant de mélanger (sans s'en apercevoir) les deux usages, et quand on oubliera aussi de dupliquer des définitions de l'un dans l'autre pour les sens voisins.

Est-ce que ça vaut le coup ? Il me semble bien plus clair d'avoir tous les usages du même mot dans la même page, d'autant qu’ils doivent se classer au même endroit dans les catégories, selon le verbe lui-même et non pas selon le pronom (faute de quoi la catégorie des verbes pronominaux contiendra tout à la lettre 's', et le dictionnaire général du français aura un énorme pavé à la lettre 's'). verdy_p 19 décembre 2008 à 14:09 (UTC)

switch dans le Modèle trad

Est-ce que la suppression du switch est vraiment une bonne idée ? Je l'avais fait même s'il n'y avait pas d'urgence, pour pouvoir étendre plus facilement le modèle ensuite. Le chinois ne me semble pas être la seule langue à mériter un traitement à part, même si je connais moins les autres, je peux constater qu'on n'a pas à l'heure actuelle de solution satisfaisante pour le japonais par exemple.

Est-ce que cela ne risque pas de faire un modèle trop lourd si on ajoute les options pour toutes les langues dans un seul et même modèle ? Koxinga 22 décembre 2008 à 11:57 (UTC)

Justement c'est pour ça que je le généralise, car je compte ajouter d'autres paramètres pour les kanas du japonais (ou pour les autres alphabétisations non latines, telles que le bopomofo en chinois aussi).

Le switch ne se justifie pas du tout et complique la gestion des trois modèles trad, trad+ et trad- et ralentit le traitement (avec un appel de sous-modèle intermédiaire, qu'on ne peut pas "substituer" actuellement à cause du switch actuel).

Dans l'immédiat {{trad/zh}} ne sert plus à rien (il est redirigé), on peut utiliser {{trad/défaut}} directement sans aucun switch spécifique pour le chinois, car il gère toutes les options actuelles du chinois (et les futures pour le japonais, et aussi pour la prononciation éventuelle comme on peut en voir par exemple dans dictionnaire). Cela fait un niveau de moins à gérer spécifiquement dans les modèles. verdy_p 22 décembre 2008 à 12:02 (UTC)

Note : il n'y a pas que le chinois à avoir des graphies traditionnelles, le japonais, le coréen, le vietnamien en ont aussi (et en fait de nombreuses langues asiatiques et même européennes, pour lesquelles on n'a pas forcément à créer un article indépendant et une traduction séparée), en plus des autres translitérations ou alphabétisations (par exemple, en arabe ou cyrillique pour le turkmène ou l'azéri ou encore d'autres langues chinoises, ce qui fait qu'on devrait pouvoir gérer au moins 2 autres translitérations, à indiquer seulement si on n'envisage pas de créer des articles correspondant).

Pour le serbe, qui a une orthographe moderne latine spécifique et officielle, on ne parle pas de "romanisation" ni de translitération supplémentaire, ni d'orthographe traditionelle non plus, il devrait y avoir des traductions séparées pour {{sr-Latn}}. verdy_p 22 décembre 2008 à 12:08 (UTC)

Bot

Ça ne te dirais pas de demander d'avoir un compte de bot ? Là tu gênes pas mal la lecture des modifications récentes. Koxinga 22 décembre 2008 à 22:13 (UTC)

Je les ai vérifiées à la main avant de les lancer. Il faut un bot pour ça ? Ca fait peu de modifs en fait. verdy_p 22 décembre 2008 à 22:15 (UTC)

Surtout que c'est déjà terminé (pour les substitutions simples), le reste ce sera à la main. verdy_p 22 décembre 2008 à 22:16 (UTC)

Où faut-il s'adresser pour ça ici ? Je n'ai pas du tout l'intention d'utiliser un bot pour des modifs massives que je ne vérifierai pas une par une de toute façon. verdy_p 22 décembre 2008 à 22:18 (UTC)

C'est vrai que c'était court, donc pas de souci. Si un jour cela t'intéresse, il faut demander là-bas : Wiktionnaire:Bot/Statut. Koxinga 22 décembre 2008 à 22:46 (UTC)

Je précise que j'ai lancé mon bot pour faire ce travail-là. La prochaine fois évite de faire ça dans ton coin encore une fois (j'ai annoncé moi-même que je m'en occupais sur la Wikidémie) : merci de laisser les travaux de bots aux bots... - Dakdada (discuter) 22 décembre 2008 à 22:52 (UTC)

En outre, il y avait 4246 pages contenant ce modèle, ce qui explique l'usage d'un bot. - Dakdada (discuter) 22 décembre 2008 à 23:01 (UTC)

Je n'ai pas fait 4000 pages, loin de là ! verdy_p 22 décembre 2008 à 23:05 (UTC)

Non, c'est mon bot qui les a faites :P Dakdada (discuter) 22 décembre 2008 à 23:08 (UTC)

Je n'ai pas vu qu'il tournait, les compteurs étaient arrêtés sur le nombre de références. C'est en voyant ça que je me suis dit qu'il était possible de les faire, j'ai juste vérifié la liste et ça a été fait en deux minutes, hormi deux ou trois qui sont restés à faire à la main à cause de leur paramètre redondant. verdy_p 22 décembre 2008 à 23:11 (UTC)

caractère

Salut !

Est-ce que tu pourrais m'expliquer tes modifications du modèle {{caractère}} ? Il me pose un peu des problèmes car tu as écrit dans l'aide qu'il crée un titre de niveau trois, et tu as changé les == en <h3>. Il est utilisé partout en titre de niveau 2 ce qui énerve mon programme chargé de vérifier la cohérence de pages. (en plus, tu avais mal fermé ta balise <h3>).

Désolé pour cette fermeture incorrecte, mais le modèle est aussi utilisé dans des sections de langues, mais ça peut être fixé. Il y a plus de pages qui l'emploie actuellement au niveau 3, mais qui demanderaient une réorganisation (en chinois notamment) où on trouve de tout. MediaWiki a corrigé tout seul de toute façon ce cas là en fermant automatiquement la balise h3, et ignorant la seconde balise qui est vide après cette fermeture automatique. verdy_p 23 décembre 2008 à 12:53 (UTC)

Es-tu sûr qu'un caractère doive être dans une section de langue ? Moi je voyais plutôt un titre de niveau 2, au même titre que {{=conv=}}. Je ne vois pas du tout sous quelle langue mettre toutes les pages de caractères.

C'est vrai que tu as un peu tendance à modifier des choses importantes seul. Là je pense que cela méritait discussion, tu as quand même cassé la table des matières de milliers de pages avec ta modification. Koxinga 23 décembre 2008 à 12:26 (UTC)

C'est pas si évident que ça: est-ce que ça doit apparaître en table des matières alors qu'en tête de page, il apparaît préférablement à côté de cette table des matières, hors des langues ? Quand il est dans une section de langue, il est bien au niveau 3. Le nom du modèle (avec des signes moins et non égal) incite à faire ce placement au niveau 3 et non au niveau 2. verdy_p 23 décembre 2008 à 12:53 (UTC)

Note aussi que le caractère seul ne décrit pas une convention internationale (symboles, unités de mesures, etc.) C'set une description indépendante de toute langue ou signification (codification Unicode, propriétés etc.) et la notation d’alphabet n'y a pas sa place, mais seulement celle d’écriture unifiée (selon la normalisation Unicode), indépendant de la forme graphique réelle (simplifiée, traditionelle). Aussi je pense que même la représentation graphique devrait être évitée dans la tête de page qui apparaît avant les langues ou même avant les conventions internationales, car elle dépend justement de la convention ou langue utilisée.

Note : ma modif consistait surtout à déplacer la documentation et la catégorisation dans une sous-page. verdy_p 23 décembre 2008 à 12:55 (UTC)

Non, tu as changé le niveau d'un titre, et donc la hiérarchie de toutes les pages l'utilisant. Ce n'est pas grave, c'est bien que des gens changent des choses.

Est-ce que tu peux me donner un exemple de page l'utilisant en titre de niveau 3 ?

Ce qu'il nous faut, c'est un nouveau modèle de titre de niveau 2 non ? (Je viens de voir que {{=car=}} était pris, d'où l'edit) Koxinga 23 décembre 2008 à 14:41 (UTC)

Au moment où je l'avais fait il y en avait plein, mais il semble que la plupart des pages (la pluaprt pour des idéogrammes) ont été corrigées depuis). Je n'ai donc pas modifié la doc, j'ai remis le titre en niveau 2 en regardant comment il était utilisé maintenant.

La présentation des pages de sinogrammes demanderait toutefois à être encore améliorée, parce qu'elle est assez lourde et pas encore bien structurée, justement dans la section "Caractère" (de niveau 2 rétabli), les modèles faisant à peu près tout ce qu'ils veulent et de façon pas homogène. Mais effectivement s'il est de niveau 2, ce serait mieux qu'il soit renommé =carac= (plus logique pour la vérification de structure des pages), et pas =car= (c'est un code langue). Il n'y a pas urgence ici si on garde pendant un temps caractère. verdy_p 23 décembre 2008 à 14:48 (UTC)

ok, je n'en ai pas trouvé dans le dernier dump, je pensais que c'était des ajouts récents que des gens avaient fait. Je pense donc qu'on peut le laisser en niveau deux, et créer {{}}, même si le renommage n'est pas une urgence, cela sera plus facile à comprendre et à parser ensuite.

Je suis bien d'accord que toutes les pages de sinogrammes devraient être reprises. j'ai d'autres trucs en ce moment mais si tu me fais une liste des choses qui ne vont pas selon toi, je suis intéressé. Koxinga 23 décembre 2008 à 14:59 (UTC)

Ah si, il y a par exemple … que tu as édité il y a peu. Koxinga 23 décembre 2008 à 15:14 (UTC)

(...) Lequel ? J'ai sans doûte recherché dans cette page (je ne sais plus laquelle) comment organiser un contenu fouilli. Si je me souviens bien, il y a des données relatives aux dictinnaires propres au chinois qui sont dans la section chinoise, et pas dans la section caractère générale en tête.

Pour moi la section caractère en tête doit être indépendante de la langue (chinois, coréen, japonais), et doit adopter la présentation adaptée du caractère dans cette langue (car elle varie d'une langue à l'autre entre le chinois (mandarin) à écriture Hanzi simplifiée, le chinois (probablement uniquement le chinois classique ou médiaval, le cantonais, le taïwanais, et le wu qui ont leur propre codes) à écriture Hanzi traditionnelle, le japonais Kanji, le coréen Hanja et le vietnamien Chunhom). Il ne m'apparait pas logique de mentionner tout ça dans la section caractère.

D'autre part la présentation des tableaux étymologiques des sinogrammes, et le centrage des tracés ou animations pose des tas de problème de mise en page.

Et j'aimerais bien pouvoir qualifier la langue d'un texte directement avec {{zh|texte}} au lieu (actuellement) de {{lang/span|zh|texte}} ou chinois pour demander une transcription chinoise simplifiée dans la section chinoise (mandarine) simplifiée (malheureusement le modèle de base {{lang/}} est bloqué et ne permet pas de mettre un test pour savoir si le paramètre 1 est renseigné dans {{zh}} par exemple, et indique alors le texte dans cette langue et non le nom de la langue en français qui s'affiche par défaut et ignore tous paramètres.

Pour en comprendre l'utilité regarde les deux premiers articles de sinogrammes liés à {{caractère}} : la présentation du sinogramme est différente en japonais ou coréen hanja de celle exposée dans la section caractère (pour le chinois simplifié ou pour les représentations historiques du chinois médiéval, que le caractère codé ne représente pas directement selon Unicode, qui n'a pas unifié ces formes historiques car elles ont souvent donné naissance à des sinogrammes modernes distincts, et ces formes historiques ont parfois leur propre codification). verdy_p 23 décembre 2008 à 15:30 (UTC)

J'ai trouvé deux pages qui avaient été affectées par le passage de {{caractère}} au niveau 2 : , et Alias .. Comme tu es l'auteur principal, je te laisse t'en occuper si tu veux. Sinon je réorganiserai moi-même. Koxinga 28 décembre 2008 à 23:39 (UTC)

page principale

Je suis aussi pour un mouvement plus rapide pour la nouvelle page d'accueil. Il y avait plusieurs contributeurs qui pensaient que le texte d'accueil était trop long et, bien que bien écrit, pas très convivial. Est-ce que tu y tiens beaucoup ou est-ce que c'est envisageable de le mettre dans une sous-page avec un lien bien visible ? Comme ça les gens intrigués par le concept puissent en lire plus mais que les gens qui veulent juste chercher un mot ne soit pas repoussés.

En plus, mais là c'est personnel, dans l'espace libéré je mettrais bien les liens parcourir, afin d'avoir la boite de recherche sur toute la largeur, plus comme un moteur de recherche, pour qu'elle ressorte encore plus que dans ta proposition actuelle. Le succès de Google s'est fait en partie sur l'interface épurée que l'on voyait sur leur page principale.

D'ailleurs, j'aurais bien fait une proposition plus radicale, par exemple en enlevant l'index général, qui était sympa au tout début, mais qui ne sert à rien maintenant.

Pour une modification aussi visible que celle-là, peut-être que tu es obligé de passer par un vote un peu formalisé quand même, pour qu'un administrateur n'hésite pas à modifier la page.

Ce n'est donc pas assez épuré à mon goût, mais sans conteste un pas dans la bonne direction, n'hésite pas à insister un peu pour le faire accepter.

Koxinga 31 décembre 2008 à 00:41 (UTC)

Je ferai ça en rentrant chez moi (il ne s'agit pas seulement de déplacer un cadre mais réagencer le tout), je suis en famille pour encore quelques jours, et pas trop le temps de faire ça maintenant. (j'attends des invités pour l'instant). Je pensais que le texte avait sa place sur l'accueil car il est directement lié à la présentation du site lui-même et guide déjà les premiers visiteurs. D'ailleurs on retrouve ce texte aussi sur la page anglaise (dont cette version est principalement issue).

L'index est déjà en bas, que veux-tu faire de plus ?

La boîte de recherche en pleine largeur ? Peut-être, mais je pensais ne pas perdre de place, la largeur étant suffisante pour rechercher un mot ou deux. Il faut que je regardes différentes solutions, mais je ne tiens pas trop à tout décaler vers le bas, en concentrant tout en haut sous forme assez compacte tous les principaux liens de navigation sans que cela gène la présentation du site ni les autres cadres importants.

Bon réveillon, et bonne année. verdy_p 31 décembre 2008 à 17:24 (UTC)

Organisation des pages de sinogrammes

Salut ! (décidément, je suis le seul à venir te parler ;o) )

J'ai vu que tu avais réorganisé certaines pages de sinogrammes. C'est bien de se lancer mais cela mérite discussion parce que tu as quelques problèmes avec ton organisation. Par exemple :

Dae Jaweon est un dictionnaire coréen non ? Pourquoi l'avoir mis dans la section chinois ?

Parce que je n'ai pas encore tout trié... Les dictionnaires devraient effectivement être éclatés par langue, contrairement à ce qui concerne la codification du caractère lui-même (Unicode, HKCS, Big5, GB2312/18030) qui est multilingue. Comme actuellement on mélange tout, et qu'on ne donne même pas un lien donnant une définition de la teminologie utilisée pous cette classification ou ces dictionnaires, on se retrouve déjà (même avant mon début de changement) avec un sac de noeuds avec des données sans aucun rapport les unes avec les autres.

Tu es sûr de vouloir séparer le cantonais, même quand le sens n'est pas différent ? Dans ce cas tu devrais recopier la définition.

Le problème c'est qu'on mélange tout dans la section caractères, alors que bien des parties ne concernent que le chinois (et encore, seulement le mandarin, pas toutes les langues chinoises en le plus souvent pas le cantonais)). Les classements de dictionnaires sont aussi spécifiques par langue (ce que les modèles actuels n'indiquent pas du tout. De plus la cantonais n'ai rien à voir en ce qui concerne la présentation graphique du sinogramme, et même souvent son étymologie, ainsi que sa prononciation, ses romanisations, ses méthodes de saisie, etc... C'est une langue bien à part même si on l'appelle souvent abusivement "chinois" (juste parce que c'est dans le même pays au sens politique).

Rappel : le chinois est considéré comme une macrolangue, pas une langue individuelle. Bien qu'on le code "zh" pour signifier "le" chinois, c'est en fait pratiquement toujours le mandarin et pas toutes les langues chinoises, même s'il apparait qu'il y a des ressemblances superficielles dans l'écriture, et un degré très limité d'intercompréhension et uniquement dans la forme écrite de ces langues (mais finalement beaucoup moins qu'entre le français et l'italien par exemple...). La grammaire est même très différente.

Il faut briser ce mythe "du" chinois qui n'a jamais été une langue unique (et finalement ne le sera jamais, on n'est plus au temps de la "révolution culturelle" en Chine, les tentatives d'unification ont échoué et sont même largement abandonnées au profit d'une repurification des langues individuelles concernées. C'est d'autant plus vrai que maintenant les langues chinoises sont bien séparées dans l'ISO 639 (alors que pendant longtemps on les codait toutes avec le code "zh" unique pour uniquement désigner leur forme écrite dans une forme finalement adaptée uniquement au mandarin et très grossière ou incorrecte pour les autres langues chinoises). La notion même de "macrolangue" pour le chinois est même très abusive et grossière. Pour moi ce n'est qu'une sous-famille de langues sinotibétaines, et le code "zh" devrait avori une étendue de type "C" (code collectif)

Mais pour respecter la compatibilité ascendante, il est établi désormais que "zh" est utilisé pour désigner le mandarin, en tant qu'alias synonyme de "cmn", toutes les autres langues devant utiliser soit leur nouveau code langue ISO 639-3 respectif (à trois lettres), soit un code historique (de compatibilité uniquement et désormais plus extensible du tout) formé à partir de "zh" suivi d'un tiret et d'une ou plusieurs extensions : c'est le cas pour le minnan ("zh-min-nan" obsolète devient "nan" hautement recommandé), le cantonnais ("zh-yue" obsolète devient "yue"), le wu ("zh-wuu" devient "wuu" recommandé), etc... Il ne reste alors plus que "zh" pour désigner la mandarin uniquement (y compris sous la forme "zh-Hans", rendu obsolète car "le suffixe "Hans" est déclaré supprimable, ou "zh-Hant" rendu aussi obsolète au profix de codes spécifiques pour le taiwanais. Les codes d'écritures "Hans" et "Hant" restent utiles mais uniquement pour établir la forme graphique adaptée à chaque langue individuelle quand celle-ci n'est pas la forme supprimable. Cela simplifie énormément la situation tout en maintenant la compatibilité ascendante (les anciens codes deviennent des aliases). Je n'ai pas encore vu la moindre utilité du code [cmn] alloué spécifiquement pour le mandarin dans l'ISO 639-3 (alors que BCP47 établit que "zh" reste la forme recommandée pour le mandarin qui est la langue très largement majoritaire parmi les langues chinoises

Est-ce que tu te souviens que c'est toujours à moi que tu parles ? C'est la troisième fois que tu m'expliques que le chinois n'est pas une langue unique, et je le savais déjà avant la première fois. S'il te plait, souviens-toi de nos discussions d'une fois sur l'autre, tu gagneras beaucoup de temps.

Ceci dit, je suis d'accord pour séparer les entrées par langue.

Koxinga 3 janvier 2009 à 23:19 (UTC)

Tu veux vraiment utiliser des modèles {{lang/span}} directement dans la page ?

Non ce n'est pas idéal mais malheureusement on a protégé le modlèle {{lang/}} qui simplifierait la syntaxe grandement: je voulais utiliser par exemple {{zh|texte en mandarin avec sinogrammes simplifiés}} et non {{lang/span|zh|texte en mandarin avec sinogrammes simplifiés}}.

Le but est d'annoter la langue réellement utilisée pour afficher le rendu correct propre à chaque tuple (langue,écriture,orthographe) et indexer correctement le contenu. Le mélange actuel ne me plait pas du tout, et est en fin de compte illisible, sans permettre de définir une utilisation réelle, ni même un affichage correct sur n'importe lequel des navigateurs actuels (ou robots de moteurs de recherche de type Google) qui sont totalement incapables de faire la différence dans tout ça !

J'espère que ce ne sont que des tests et que tu ne vas pas tout reformater comme cela (et si c'est des tests, c'est peut-être mieux sur une page perso). Koxinga 3 janvier 2009 à 21:13 (UTC)

Je ne fais que quelques essais sur une ou deux pages à titre de tests effectivement, pour juger du rendu final, je comptais bien en discuter (j'(en ai déjà parlé sommairement un peu avant Noël. Je ne fais pas les tests partout, j'ai pris la première page listée dans les catégories testées, et les sinogrammes les plus simples en tête de série, mais sans casser toute la structure des articles. Mais il me faut des exemples concrets et suffisamment complets (c'est pour ça que j'ai choisi des sinogrammes de base utilisés dans la majorité des langues à écriture sinographique pour tenter de définir une structure claire, mais rendant compte des véritables différences d'utilisation.

J'avais déjà signalé ces problèmes avant Noël, mais entre temps je n'étais plus là et suis rentré seulement aujourd'hui, avec encore peu de temps pour reprendre tout ça.

J'aimerais bien qu'on clarifie et finalise cette structure pour clairement séparer et classer : cantonais [yue], chinois médiéval [ozh], vietnamien médiéval (chu-nho), chinois classique [zh-Hant], vietnamien classique (chu-nom), mandarin moderne [zh], coréen classique (hanja), coréen moderne, japonais nihôn classique, ... Les modèles d'étymologie graphique doivent aussi être reclassés sous une forme plus logique qui ne mélange pas tout (de la même façon qu'on ne mélange pas non plus le français avec toutes les langues romanes ou même le latin ou l'ancien grec dans les étymologies de langues romanes...). Et redonner du sens sans se contenter de tout mettre au même endroit simplement en reprennant des données de sources diverses mélangéés au sein d'un même modèle qui veut tout afficher plus ou moins bien.

C'est ce mélange actuel des sources et données qui n'a aucun sens et ne permet pas de donner une définition précise et de lever les nombreuses ambiguïtés. Ce n'est pas seulement une question de présentation, mais bien un problème de structure des articles, avec des modèles à mieux réfléchir et reconcevoir. Ces quelques pages d'essais ne cassent pas trop ce qui est fait actuellement, mais sont un début de reclassement. Il serait bien de commencer par là sur ces quelques articles de test assez fournis pour ensuite savoir comment restructurer le reste (au passage il faut aussi revoir les noms des modèles de forme utilisés dans les langues à sinogrammes: rien ne fonctionne selon la structure adoptée pour les autres langues, et les noms de modèles utilisés sont très ambigus, ou carrément inhomogènes et incohérents entre eux). verdy_p 3 janvier 2009 à 22:42 (UTC)

Je suis bien d'accord qu'il faut revoir la structure. Le problème c'est que tu fais des essais dans l'espace principal, celui que les visiteurs viennent voir, et justement avec les caractères les plus courants.

Ce ne sont pas réellement des essais, mais des modifs mineures sur quelques pages, trop isolées pour que cela constitue une norme susceptible de géner les autres contributeurs. Je n'ai rien fait qui rende ces pages illisibles ou inexploitables, il faut réellement aller chercher dans le détail du code et analyser longuement la page convcernée par rapport aux autres pour s'apercevoir que la structure est modifiée. Sur de telles pages isolées, cela ne peut pas constituer une "norme" indiquant aux autres ce qu'ils "doivent" faire, ou ce qu'il "faut" faire. verdy_p 4 janvier 2009 à 08:46 (UTC)

Il faut copier la source de 人, par exemple dans Utilisateur:Verdy p/人 et tout faire là dedans.

Méfies toi du terme "Il faut". D'abord il n'existe pas de telles règles, ensuite cela contrevient aux principes mêmes du wiki qui dit qu'on doit pouvoir modifier toute page. S'il faut une autorisation pour modifier UNE page à certains endroits, que faudra-t-il faire ensuite pour ceux qui veulent ensuite modifier plein de pages ? Réellement, on modifie à quelques endroits, sans rien de mander à personne, si cela ne plait pas, d'autres peuvent modifier à nouveau ou en discuter. On discute en général les modifs à faire sur un grand nombre de page ou qui font l'objet d'une nouvelle "recommandation" (pas une obligation) pour la meilleure pratique actuellement retenue (mais qui peut encore être modifiée ou améliorée plus tard). verdy_p 4 janvier 2009 à 08:46 (UTC)

C'est ce que je fais (tu peux voir par exemple Utilisateur:Koxinga/sinogrammes/面) et cela garde une distinction claire entre contenu du dictionnaire et essais personnels, pour pas qu'un contributeur tombe dessus et pense que c'est comme cela qu'il faut faire.

En gros on est d'accord sur tout, il faut réorganiser toutes ces données, c'est juste ta méthode que je trouve criticable.

C'est la méthode du wiki, pas besoin de discuter quelques modifs isolées dans quelques pages. Sinon on n'en finira pas. Je ne vois pas non plus l'intérêt de dupliquer les pages (sinon celui de doubler le travail), sauf dans le cadre justement d'une discussion ou plusieurs solutions sont envisagées et proposées avec des éléments de comparaison. Note bien je contais en discuter (et j'avais déjà commencé à le faire avant Noël). verdy_p 4 janvier 2009 à 08:46 (UTC)

Bon, on ne va pas se quereller pour ça. Je retire "il faut", j'aurais dû dire, "je pense que tu devrais". On est d'accord que la version actuelle de 人 n'est qu'une version de travail et j'aurais préféré qu'elle ne soit pas sur l'espace principal, mais tu fais bien comme tu veux.

Koxinga 4 janvier 2009 à 11:02 (UTC)

De toute façon, mon plus gros problème n'est pas là. Il faut trouver un moyen de lier les définitions des caractères simplifiés et traditionnels (en gros cela ne concerne que le mandarin, les autres langues s'écrivant dans l'un ou l'autre des deux jeux). C'est ce que j'essaye de faire dans Utilisateur:Koxinga/sinogrammes/面 et Utilisateur:Koxinga/sinogrammes/麵 mais je ne sais pas si les autres contributeurs vont trouver cela acceptable de créer des pages telles que Utilisateur:Koxinga/sinogrammes/zh-déf-麵面, surtout que la saisie n'est pas ultra-intuitive. Koxinga 3 janvier 2009 à 23:19 (UTC)

Les définitions pour le coréen, le japonais ou le vietnamien, ou même pour le cantonais ou le wu sont souvent différentes de celles du mandarin. La distinction "simplifié" ou "traditionnel" actuellement faite n'est valide que pour la mandarin puisque cette distinction se fait de façon différente pour les autres langues (y compris pour les langues chinoises autres que le mandarin). Effectivement cette saisie n'est pas du tout intuitive, mais si on sépare correctement les langues cela devient nettement plus simple. C'est la volonté de "lier les définitions" qui en fait complique tout et introduit des conflits et contradictions. Même si c'est au prix d'une "copie" de certaines définitions, cela correspond à des usages différents d'une étymologie commune (c'est exactement similaire au cas des mots "identiques" en français et anglais qui ont la même étymologie mais acquis depuis certains usages distincts dans chaque langue.) Il n'y a pas réellement copie (la copie ne concerne qu'une toute petite partie de la définition, mais pas les usages, exemples ou citations) et en fait on évite de mélanger des définitions, prononciations, synonymes, homonymes, paronymes, romanisations et transcriptions pour des usages concernant d'autres langues que la langue définie.

Si tu regardes bien mon exemple, tu vois que le problème que j'essaie de résoudre n'a rien à voir avec la séparation des langues. Je parle de duplications des définitions entre simplifié et traditionnel pour le mandarin. J'ai modifié le titre de la section pour rendre cela plus clair mais même avant elle ne donnait des informations que sur le mandarin (sous le titre zh, comme ce que tu m'as expliqué ).

Pour essayer de résoudre ce problème, j'ai commencé par regarder ailleurs ce qui se faisait :

* Le wiktionary maintient deux versions totalement séparées des pages. Cela fonctionne parce que seul en:User:A-Cai contribue et qu'il pense à faire soigneusement les deux versions à chaque modification (sûrement aidé de programmes). Je ne pense pas que cela soit viable sur le long terme.

* Le wiktionary chinois a testé différentes possibilités mais n'est pas assez développé pour pouvoir en tirer des conclusions. Il propose :

** Un simple redirect du simplifié vers le traditionnel : zh:中华民国 redirige vers zh:中華民國

** Un modèle commun aux deux pages : zh:中国人 et zh:中國人 incluent tous les deux le modèle Template:中国人. C'est en gros ce que je veux faire, sauf que je veux aussi avec un argument indiquant le type de la page où il est inclu, à passer aux différents modèles concernés dans la page.

** Une inclusion d'une partie de la page en caractère traditionnel dans la page en caractère simplifié.

* On pourrait aussi envisager des "soft redirect", mais cela crée une asymétrie que je ne suis pas sûr de vouloir commencer, c'est un sujet plus sensible que les réformes orthographiques de 1990 .

Le mélange des langues est un problème complètement orthogonal à ce problème de duplication d'entrées et séparer les langues ne va pas simplifier la saisie de définitions en mandarin. Koxinga 4 janvier 2009 à 11:02 (UTC)

D'ailleurs j'envisage même de demander plus tard la suppression (ou la réorganisation) des sections de langue "Coréen hanjas" sous leur forme actuelle : c'est du coréen, mais la distinction fondée sur l'écriture n'est pas pertinente. Ce qui compte c'est la distinction historique de langue. Si ces caractères hanjas sont encore employés dans la langue actuelle (en Corée du Sud seulement car en Corée du Nord ils sont complètement bannis), ils ne constituent pas à eux seuls une langue écrite (sauf dans une forme très ancienne); au mieux on peut seulement les considérer comme un sous-ensemble de caractères/mots utilisés en coréen (à sous-catégoriser dans la langue coréenne, et pour lequel devrait toujours indiquer une transcription hangûle (d'usage obligatoire en Corée du Nord, et présente dans les dictionnaires hanjas en Corée du Sud).

Je suis d'accord, cela m'a surpris de le voir dans la liste des langues. Koxinga 4 janvier 2009 à 11:02 (UTC)

Mais ne nous précipitons pas. Avant de proposer un changement, on doit bien le mettre au point sur des exemples concrets et montrer en quoi cela améliore la lisibilité de l'article et sa compréhension. Pour moi cela veut-dire que si plusieurs solutions sont proposées (pour des modifications en masse de nombreuses pages) on peut effectivement avoir des pages de tests ; mais c'est inutile tant qu'on n'a rien d'autre à proposer pour le moment sur quelques pages prises comme exemples. Il sera toujours temps de proposer ces changements et d'en discuter une fois l'expérimentation effectuée, si ces changements doivent être effectués à plus grande échelle et proposés comme une nouvelle recommandation (tant que l'expérimentation limitée ne casse pas les pages au point de les rendre inexploitables pour les autres, il n'y a pas besoin de le faire dans des pages personnelles à mon avis, car cela pollue plus le Wiktionnaire et ses catégories). Actuellement, je ne recommande rien du tout et ne demande pas aux autres de faire comme je le fais ; ce que je fais n'est pas différent de modifs individuelles comparables à des corrections locales, et non destructrices ; bien sûr cela complique localement le code, mais je cherche bien à obtenir à terme une structure plus simple (et plus comparable à ce qu'on fait pour les autres langues à écriture latine) Cela passe nécessairement par des étapes intermédiaires où les modifs sont progressives et peuvent introduire une complexification, mais c'est exactement ce qui se passe toujours en cas de changemetn de façon de faire et cette complexification n'est réellement génante que lors de la phase transitoire de déploiement massif, car on doit encore maintenir une compatibilité avec le reste, avant de pouvoir simplifier le code. verdy_p 4 janvier 2009 à 08:46 (UTC)

Modèle:grc

Bonjour, pourrais-tu voir ce que tu peux faire pour ça ? -Béotien lambda 4 janvier 2009 à 06:43 (UTC)

Réglé. La valeur par défaut de l'écriture (Latn) était encore utilisée car ça n'avait pas encore été paramétré pour cette langue (j'avais paramétré {{el}} et j'ai oublié le grec ancien car il n'était pas dans ma liste d'exemples...)

J'ai introduit le paramètre "écriture=" récemment (ce paramètre est déjà documenté aussi dans {{lang/Aide}} visible dans tous les modèles de code langue existants) en ne le modifiant que pour un certain nombre de langues que j'ai pu détecter rapidement à partir des langues des principaux Wiktionnaires, mais il y en a certainement d'autres. Les modèles pour les écritures sont encore récents (et pas encore tous paramétrés).

Il en manque encore, c'est très simple de l'indiquer : ajouter le paramètre "écriture=Code ISO 15924" dans le modèle lang/type de paramétrage d'une langue (mais avant de le faire, il faut vérifier que le modèle d'écriture est paramétré, hors ils ne le sont pas encore tous, ce que je vais terminer car ils sont assez peu nombreux). Voir la page Wiktionnaire:ISO 15924 où ils sont tous listés (les modèles de base existent tous, mais pas tous les modèles de paramétrage, ce que je vais achever rapidement.)

Notes :

• les modèles basés sur "{{écriture}}" sont similaires à ceux pour les langues. Ils centralisent des informations destinées à labelliser le texte et lui permettre un affichage correct, indépendamment des langues utilisées mais les langues ont aussi une écriture par défaut et parfois des écritures alternatives, y compris les romanisations en écriture latine (certaines étant normalisées pour certaines langues comme le pinyin qui est la romanisation par défaut du mandarin, ou Hepburn pour le romaji japonais, ou l'orthographe officielle du vietnamien moderne ou du serbe latin), ou transcriptions vers d'autres alphabets (comme l'hangûl pour la transcription phonétique des hanjas coréens), ou syllabaires (le bopomofo pour la lecture des sinogrammes de certaines langues de la Chine et le mandarin, les kanas pour le japonais).
• les exemples montrent des caractères significatifs dans l'écriture correspondante. Ils permettent de tester la compatibilité du navigateur. Ils référencent aussi une liste optionnelle de polices de caractères pour supporter cette écriture. Comme ces listes sont encore à l’état d’ébauche (pour l'instant on y trovue surtout des polices Windows de bonne qualité, mais il devrait être possible d'ajouter des polices libres si elles sont suffisantes, mais en dehors des polices latines, bien peu sont libres et de bonne qualité, sauf celles conçues et diffusées par les organismes linguistiques nationaux comme ceux du Cambodge pour l’écriture khmère, du Maroc pour l’écriture tifinaghe...).
• A terme, ces listes optionnelles de polices présentes dans les modèles Code-écriture/type devraient ensuite être paramétrées dans la feuille de style CSS générale du site (via les classes comme ".script-Latn", ".script-Grek", ".script-Cyrl", ".script-Hant", ".script-Hans", ".script-Jpan", ".script-Kore", etc. qui sont nommées d’après le code ISO 15924), de même que l'ajustement de taille (nécessaire pour afficher le khmer de façon lisible dans toutes les polices khmères que j'ai pu voir). Initialement on avait des classes de styles basées sur les codes langue, mais c'est assez malaisé de les paramétrer de façon exhautive, alors qu'il est nettement plus simple de paramétrer les polices par écriture (et donc associer chaque code langue à son code d'écriture).
• Mon intention est de pouvoir écrire directement {{ja|mots en japonais}} de façon assez intuitive dans les articles (mais il faudrait qu'on me permette de modifier le modèle {{lang/}} que j'avais créé mais qui a été protégé récemment avant que je puisse prendre en charge un paramètre optionnel, autre que le seul paramètre "type=". Sinon il faudrait aussi passer ce paramètre optionnel contenant le texte dans les modèles de base de codes langue (je peux faire cette modif automatiquement, ces modèles étant tous uniformes).
• C'est déjà fait depuis mi-décembre pour labelliser et afficher correctement les traductions dans {{trad/défaut}}, ainsi que pour {{trad/zh}} (qui n'a plus lieu d'être et unifié dans {{trad/défaut}} vers lequel il est redirigé : cela devrait conduire à la suppression des switch encore présents dans {{trad}},{{trad+}} et {{trad-}} mais désormais inutiles et même indésirables). verdy_p 4 janvier 2009 à 11:39 (UTC)

{{étymologie-chinoise-SVG}}

Je ne comprend pas vraiment tes modifications sur ce modèle. GiuseppeMassimo m'a fait remarquer que le modèle donnait un mauvais résultat pour le caractère simplifié dans 馬.

• J'ai revérifié ce caractère et le résultat est correct justement ! Ce n'est pas très flagrant dans la version agrandie du caractère, mais sans sa forme réduite c'est évident ! La forme dite "simplifiée" est en fait légèrement plus complexe (des traits de la partie supérieure du caractère s'allongent dans la partie basse) que la forme traditionnelle (où les deux parties sont bien séparées), et c'est tout à fait normal ! Méfiance avec le terme "simplifié" qu'on devrait lire plutôt comme "révisé" ou "réformé". Individuellement les caractères peuvent être plus complexes, même si globalement les caractères réformés sont généralement (mais pas toujours...) simplifiés. verdy_p 8 janvier 2009 à 21:07 (UTC)

mais pas du tout ! La version simplifiée de 馬 est 马 (je met les liens vers les glyphes Unicode pour qu'il n'y ait pas de malentendu lié aux polices différentes) . Les deux ont des codes séparés pour des raisons de compatibilité que l'on peut regretter mais qui existent. Moi je vois 馬 dans la partie Forme actuelle (simplifiée), ce qui est faux. Koxinga 8 janvier 2009 à 21:20 (UTC)

J'ai donc regardé le code du modèle et tu ne fais que changer l'argument de lang/span entre traditionnel et simplifié.

C'est exactement ce que l'étymologie indique (à ceci près que "simplifié" devrait se comprendre comme "réformé" : c'est bien une évolution plus tardive du caractère traditionnel. verdy_p 8 janvier 2009 à 21:13 (UTC)

Cela ne peut pas marcher !

Si, si, ça marche de la façon attendue (à condition d'avoir toutefois des polices simplifiées et traditionelles installées correctement pour voir les distinctions, sinon si on n'a qu'une seule on ne verra qu'une seule version, ou deux versions traditionnelles ou deux versions simplifiées. Je te conseilles de regarder des des polices de bonne qualité ("Microsoft YaHei" est une excellente police pour le style traditionnel, sinon on a "MingLiU"/"PMigLiU" qui n'a pas d'instruction de Hinting et est donc difficile à lire à l'écran ; "Microsoft JengHei" est une excellente police avec Hinting pour le style simplifié/réformé, sinon on a "MS Gothic" sans Hinting). verdy_p 8 janvier 2009 à 21:13 (UTC)

Note: les polices sinographiques de Windows Vista avec le font-hinting "ClearType" sont installables sous Windows XP via le site de Microsoft (il faut juste passer le test de licence "Genuine Windows") :

• http://www.microsoft.com/downloads/details.aspx?FamilyID=87e726a9-5c79-4a73-9347-78a557314d0b&DisplayLang=en ("Microsoft JengHei" pour les sinogrammes chinois traditionnels)
• http://www.microsoft.com/downloads/details.aspx?FamilyID=b15774c0-5b42-48b4-8ba8-9293fdc72099&displaylang=en ("Microsoft YaHei" pour les sinogrammes chinois simplifiés)
• http://www.microsoft.com/downloads/details.aspx?familyid=F7D758D2-46FF-4C55-92F2-69AE834AC928&displaylang=en ("Meiryo" pour les Kanjis et syllabaires kanas japonais)
• http://www.microsoft.com/downloads/details.aspx?familyid=C55A8C2B-B451-4D1F-87F3-690F78342AE8&displaylang=en ("Malgun Gothic" pour les Hanjas et jamos hangûls coréens)

Puisque pour l'immense majorité des caractères, il y a des codes différents pour simplifié et traditionnel, un changement de police ne peut pas suffire à donner le bon résultat.

Ce n'est pas vrai du tout. L'apparence change pour le même caractère unifié dans Unicode. Le changement de police n'est pas destiné à remplacer un code par un autre mais bien afficher la forme adaptée au style demandé par un tuple (langue, écriture), mais pas pour prendre en compte ce qui est un changement d'orthographe (car alors on a des articles distincts pour des caractères distincts). verdy_p 8 janvier 2009 à 21:15 (UTC)

C'est une erreur non ?

Non ! Ce n'est pas une erreur. Les sinogrammes n'ont pas le même tracé suivant la langue et le style propre à la langue. Les cas où il existe des codes différents correspondent à des codes de compatibilité qui n'ont pas été unifié en raison d'anciennes normes de codage avant Unicode et l'unification UniHan. L'immense majorité des codes est unifiée (et tous les sinogrammes ajotués maintenant devraient être unifiés même si leur graphie diffère suivant les langues ou dans leur codage non Unicode comme GB2312/18030, HKCS, Big5, SJIS, etc...) verdy_p 8 janvier 2009 à 20:25 (UTC)

Tu ne comptais pas réellement faire une table de conversion de caractères dans {{lang/span}} ? Il faut ajouter un paramètre donnant le caractère simplifié correspondant, si tu tiens vraiment à ajouter cette information. Koxinga 8 janvier 2009 à 19:34 (UTC)

Non je ne comptais certainement pas faire cette conversion. Je ne vois pas pourquoi tu penses que je voulais le faire, rien n'indique que c'était mon intention. Il semble seulement que tu ne voies pas encore l'intérêt de cette transformation alors que les pages où j'ai fait ça sont de bonnes démonstration de cet intérêt. Donc NON je ne rajouterai PAS non plus l'orthographe alternative ici. Il s'agit bien du même caractère unifié codé de la même façon mais avec des présentations distinctes, et il s'agit même du caractère recommandé (les autres n'étant nécessaires que pour la compatibilité en l'absence de spécification précise de l'identification de la langue sur les pages !

Note : mon intention réelle était de faire {{zh|mot en mandarin simplifié}} et non {{lang/span|zh|mot en chinois mandarin}} mais je n'ai pas pu le faire à cause du blocage actuel du modèle. Avant de demander le déblocage pour corriger et alléger la syntaxe, l'utiliastion de lang/span permet d'obtenir le même rendu. Tu noteras que dans les articles où j'ai fait cette utilisation, la présentation des sinogrammes est bel et bien distincte pour chaque langue (même si certaines d'entre elles ont des présentations identiques, cela ne correspond pas à la simple distinction entre sinogrammes traditionnels et simplifiés, une distinction qui n'a de sens réel que pour le mandarin codé "zh" puisque "cmn" en est un simple alias dans la norme actuelle BCP 47 utilisée sur le web). Mais avant que je demandes un déblocage du modèle {{lang/}} qui a été bloqué trop vite alors que je l'avais moi-même créé quelques semaines plus tôt et qu'il se généralise, il faut bien savoir ce que cela va engendrer. Le remplacement de {{lang/span|code langue|texte}} par {{code langue|texte}} est facile à faire automatiquement et fonctionnera quand je pourrais ajouter le paramètre 2 qui manque encore dans {{lang/}} mais qui je ne peux pas faire.

L'idée n'est pas spécifique aux sinogrammes: la même annotation de la langue utilisée devrait en fait être utilisée partout où l'article ne contient pas un mot français (donc aussi pour l'anglais par exemple). C'est peut-être lourd mais cela indexe corectement le contenu et à terme on y viendra aussi pour toutes les autres langues. L'idée n'étant pas d'identifier une écriture, mais bien un tuple (langue, écriture) à partir du moment où cela définit une orthographe pour chaque langue concernées (et pas seulement les langues sinographiques). Ce que je cherche ici n'est donc pas non plus de différencier les codages ni d'appliquer une distinction simplifié/traditionnel sur d'autres langues que le mandarin : le japonais a ses propres conventions orthographiques, de même que le coréen ou le vietnamien ou encore les autres langues chinoises (cantonais, wu, et yi notamment), et pour chacune il y a une étymologie propre qui n'est pas équivalente à celle du mandarin même si le chinois médiéval se retrouve souvent à des époques distinctes mais avec des évolutions distinctes et séparées dans le temps dans chaque langue ou région, ainsi que des significations, usages, phonétiques et translitérations distincts. Si on veut clarifier les choses il n'y a pas d'autre choix que de bien discriminer les langues et pas la codification des mots orthographiés (la désunification de certains caractères est en fait bien une minorité dans les sinogrammes). Ce n'est pas pour rien qu'il y a des polices distinctes développées pour chaque langue (si tu regardes les polices sinographiques de Windows les différences de traits sont fort nombreuses dans les caractères unifiés, même si certaines variantes dans une police donnée pour une langue dispose parfois d'un code de compatibilité qui sera affiché de la même façon dans toutes les langues, ce n'est pas le caractère recommandé, seulement un caractère usuel issu des anciennes normes avant Unicode et UniHan, et cela concerne une dizaine de milliers de sinogrammes, soit beaucoup moins que les sinogrammes unifiés, même si ce sont encore les plus courants et les plus utilisés dans les langues concernées qui peuvent encore utiliser ces caractères de compatibilité).

Note bien qu'avec l'unification et les transformations de normalisation NFC/NFD ou NFKC/NFKD, bon nombre de ces caractères de compatibilité disparaissent des textes codés, ce qui modifie leur orthographe spécifique dans l'orthographe unifiée dasn de plus en plus nombreux textes, ce qui nécessite alors des polices spécifiques pour chaque langue si on veut garder leur présentation (cela est semblable aussi dans l'unification des caractères latins qui ont aussi certaines formes spécifiques et préférables pour certaines langues, ce qui justifie que les polices contiennent alors des sections dépendant de la langue pour afficher des présentations distinctes propres à ces langues, qu'il nous faut alors annoter dans le texte des articles : ce cas est flagrant pour les langues turques à alphabet latin altaïque, mais aussi pour certaines langues à écriture arabe ou cyrillique, ou pour le yiddish et le samaritain en écriture hébreu, ou encore dans l'alphabet latin pour le moyen allemand avec le cas du umlaut transcrit comme un e suscrit, le vieil anglais, le vieil irlandais, les langues celtiques qui utilisent des variantes de l'alphabet latin unifiées en Unicode seulement mais pas dans leur usage normal, ou encore des orthographes latines médiévales, y compris pour le vieux français). Seule l'annotation de la langue précise permet de traiter proprement les différents cas et afficher la forme préférable pour respecter les orthographes. On ne doit pas se laisser abuser par l'orthographe moderne qui unifie souvent trop de choses différentes dans la même codification (et c'est encore plus vrai pour les sinogrammes).

D'ailleurs s'il fallait bannir quelque chose c'est la terminologie "traditionnelle/simplifiée" pour le mandarin, qui ne résulte pas nécessairement d'une simplification mais bien d'une réforme orthographique qui dans certains cas a complexifié certains traits sans les simplifier, par analogie avec d'autres caractères, ou par rapprochement phonétique ou modification d'usage. Regarde les polices sinographiques japonaises ou coréennes, tu verras combien ces distinctions orthographiques sont importantes et n'ont rien à voir non plus avec les distinctions propres au mandarin (c'est d'ailleurs pour ça que l'unification des sinogrammes dans Unicode/UniHan fait des débats très houleux en Asie orientale, certains voulant l'abolir complètement et développant leur propre codification pour maintenir des distinctions pertinentes, voire même abandonner Unicode! La façon d'éviter la cassure avec Unicode est de montrer que ces distinctions sont préservées à condition d'identifier la langue précisément afin de pouvoir utiliser les polices appropriées puisqu'il n'est techniquement pas encore possible de faire une police sinographique universelle supportant chaque langue correctement). verdy_p 8 janvier 2009 à 20:25 (UTC)

J'ai supprimé la distinction problématique. Dire que 馬 est la version simplifiée de 馬 ne sert à rien et induit tout le monde en erreur. La version simplifiée de 馬 est 马. 马 est une adaptation de l'écriture cursive de 馬, ce n'était pas du tout un caractère à part entière avant la simplification décidée par la RPC (il n'existe pas dans le Kangxi et n'est dans http://dict.variants.moe.edu.tw , qui recense 100 000 variantes, que comme la version simplifiée de 馬). Si Unicode avait été créé directement, on aurait pu leur attribuer le même code et gérer le passage de l'un à l'autre par des balises de langue. Malheureusement ce n'est pas le cas.

Les différence entre 馬 et 馬 que tu cites ne sont pas forcément essentielles. Les polices influent tout de même l'apparence des caractères. Sur mon ordinateur, les deux apparaissent complètement identiques alors que des différences plus significatives, telles que 骨 et 骨, ont été représentées. Koxinga 8 janvier 2009 à 22:30 (UTC)

C'est vrai, mais dans le cadre d'une étymologie "graphique" on parle bien dans ce modèle de leur apparence graphique (où les choix de polices propres à chaque style d'écriture sont pertinents). Dans la mesure où le modèle affichait déjà le caractère, il s'agissait de le montrer dans les deux styles principaux pour le "chinois" (d'après le nom du modèle) en laissant de côté nécessairement les styles des kanjis japonais, des hanjas coréens, des chunhos du sino-vietnamien médiéval ou des chunoms du vietnamien classique. Elles sont essentielles dans le cadre de cette étymologie graphique qui justement compare ces modifications d'apparence. Il y a bien sûr entre les différents styles sinographiques modernes de fortes similitudes pour ces caractères unifiés, mais ce n'est plus vraiment le cas dans le cadre de l'orthographe simplifiée.

Dès qu'on entre dans l'usage, la prononciation, ou le sens, ou quand des clés ou traits disparaissent ou sont fusionnés, on parle de définition (où la signification de chaque trait disparait au profit de la signification du caractère dans son ensemble et de sa pronociation moderne en madarin), et c'est propre à chaque langue : les variantes sont alors orthographiques, les codes changent, et on a des caractères distincts avec leur propre sens, leur propre usage (et éventuellement, mais sans garantie, une étymologie commune d'une variante à l'autre, ce qui n'est PAS démontré par les tables de transposition entre le mandarin traditionnel et le mandarin dit "simplifié" et qu'on devrait appeler mandarin "réformé", même s'il s'agit toujours de la même langue parlée qu'on transpose ainsi mais plus vraiment de la même langue écrite).

Je veux bien qu'on ajoute un second paramètre pour donner le caractère simplifié/réformé s'il est différent du caractère traditionnel décrit dans l'étymologie, mais seulement si c'est pertinent "étymologiquement". Sinon les synonymes sont faits pour ça et on parle d'un autre caractère distinct dont la ressemblance s'éloigne beaucoup trop de l'original ou peut adopter des conventions héritées d'autres caractères historiques "similaires" (par leur sens ou leur prononciation ou usage). verdy_p 8 janvier 2009 à 22:58 (UTC)

Je pense vraiment que tu as une vision fausse des caractères simplifiées et traditionnels. On ne parle pas de synonymes, quelle que soit la différence entre les caractères. Ce sont deux façons différentes d'écrire la même chose, deux étapes successives dans la représentation du même caractère "abstrait". Je ne vois pas pourquoi tu parles de différences d'usage et de sens ! :Par exemple, on peut passer de traditionnel à simplifié de manière complètement automatique avec de tables de correspondance (l'inverse est plus complexe avec les histoires de simplification de plusieurs caractères traditionnels en le même simplifié). Il n'y a qu'une exception d'un caractère traditionnel ayant deux caractères simplifiés une fois que l'on s'est rendu compte que le premier pouvait créer des ambiguïtés.

La relation simplifié/traditionnel est beaucoup plus forte que celle de synonyme, et le caractère traditionnel est quasiment toujours pertinent pour expliquer la forme du caractère simplifié. Le caractère simplifié est arrivé bien après, donc ne peut expliquer la forme du traditionnel, mais peut servir à montrer le « futur » de ce caractère, au moins en République Populaire de Chine.

Bon, je ne serai pas là pendant quelques jours, ne t'étonnes pas si je ne répond pas. Cette discussion est très intéressante et j'aimerais qu'on trouve un terrain d'accord. Avoir les idées claires là-dessus ne servira pas que pour l'étymologie, mais aussi pour mes idées d'avoir une définition commune, etc.

Koxinga 9 janvier 2009 à 06:32 (UTC)

Modèle:cs-décl-adj

c'est vraiment tres tres bien ce que tu as fait. merci et bravo ! --Diligent 13 janvier 2009 à 13:17 (UTC)

Pas de quoi. On me l'avait demandé vers début décembre si je me rappelle bien, je l'ai fait... verdy_p 13 janvier 2009 à 18:01 (UTC)

Voir discussion sur ma page d'archive : Discussion Utilisateur:Verdy_p/archive1#Modèle:cs-tab-cas.

Note: il y a des paramètres optionnels (non mentionnés dans les pages d'aide des sous-modèles) pour gérer les exceptions: ce sont les mêmes que pour le cas général, donc il est facile de rajouter des sous-modèles pour les déclaisons dures des adjectifs en -ský, -cký, et -hý.

Mais il me faudrait des exemples pour les généraliser car je ne suis pas expert en tchèque et mes recherches sur Internet ne donnent pas assez d'information. Si tu as des explications à donner sur la façon de modifier la déclinaison dure afin de généraliser certaines de ces déclinaisons au lieu de les traiter comme des exceptions, je suis preneur je peux ajouter les modèles supplémentaires. verdy_p 13 janvier 2009 à 18:13 (UTC)

Je reprends ci-dessous des réponses que tu as postée tardivement dans l'archive ci-dessus: verdy_p 13 janvier 2009 à 21:11 (UTC)

Oui. le nominatif et vocatif pluriel masculin animé devrait etre božští dans {{cs-décl-adj-dur|božsk}} mais technologičtí dans {{cs-décl-adj-dur|technologick}} donc il faut deux sous modèles en -ský et en -cký. Diligent

encore un petit détail. pour {{cs-décl-adj-dur|blah}}, ça ne marche pas non plus :-( le nominatif/vocatif masculin animé pluriel est blazí. donc il faut un sous-modéle pour les adjectifs durs en -hý (tester sur drahý, blahý)

Á part ça un grand bravo ! Diligent

De tête, il en faudra un aussi pour les adjectifs en -ký (autre que -ský et cký) avec un masculin pluriel en -cí (tester sur úzký, široký)

un pour les adjectifs en -rý => -ří pour le masculin pluriel. (tester sur mokrý)

…les délices de la langue tchèque ;-)

Je ne sais pas comment tester les adjectifs durs en -ský, -cký, -ký, -hý, -rý que tu mentionnes. Toutes mes sources que j'ai pu trouver ne citent que les 4 paradigmes pour les adjectifs (mou, dur, et les deux formes des possessifs en -in et -ův), mais ne donnent aucun détail sur les exceptions que tu donnes (si elles sont communes et pas seulement des exceptions à indiquer simplement en ajoutant les paramètres optionnels directement dans l'article pour le modèle du paradigme dur) ?

Il serait donc intéressant que tu crées les articles sur ces adjectifs de base (božský comme paradigme pour -ský ; technologický pour -cký, drahý ou blahý pour -hý ; úzký ou široký pour -ký ; mokrý pour -rý) avec la conjugaison dure actuelle (basée sur le radical privé seulement du suffixe -ý, et que tu m'indiques comment créer des modèle dérivé pour leur déclinaison : c'est-à-dire ce qui doit changer et que je dois mettre dans les 5 nouveaux modèles tchèques de déclinaison d'adjectifs à ajouter (qui seront à priori nommés : {{cs-décl-adj-dur-ský}}, {{cs-décl-adj-dur-cký}}, {{cs-décl-adj-dur-ký}}, {{cs-décl-adj-dur-hý}}, {{cs-décl-adj-dur-rý}}).

En revanche les mêmes sources indiquent sur le comparatif (et son pendant, le superlatif avec le préfixe additionel nej-) est irrégulier et devrait être mentionné dans les articles car il n'y a pas de règles évidentes. Cela suggère un autre modèle pour les donner : faut-il d'autres articles séparés pour les comparatifs et superlatifs dérivés des adjectifs (comme on en a pour les rares comparatifs dérivés en français, ou pour les plus courants comparatifs en anglais) et dans ce cas se contenter de lier les deux formes à l'adjectif de base (au nominatif masculin animé singulier) ? Ou doit-on aussi donner les comparatifs et superlatifs correspondants pour les autres articles créés pour les flexions ?

Le comparatif se construit sur la base du masculin pluriel (d'où l'importance d'avoir les bons modèles) avec ablation du í et ajout :

{{cs-décl-adj-dur}} nový / noví => novější

{{cs-décl-adj-dur-cký}} technologický / technologičtí => technologičtější

{{cs-décl-adj-dur-ský}} mužský / mužští => mužštější

{{cs-décl-adj-mou}} intimní / intimní => intimnější (exceptions : les adjectifs en -cí qui sont en fait un participe présent adjectivé et à ma connaissance n'ont pas de comparatif superlatif)

OK, mais est-ce que les tableaux que j'ai créés pour -ský, -cký, -ký, -hý, -rý sont corrects maintenant avec tes exemples ? (Consulte la liste des pages liées aux modèles pour avoir les adjectifs que j'ai dérivés.)

Il y a quelques exceptions (dobrý, dlouhý, špatný, suchý, etc.)

Peut-on toutefois indiquer cela avec un paramètre (note: je ne compte pas donner les finales pour tous les superlatifs et comparitifs, juste mentionner les liens vers ces mots dérivés, qui alors peuvent utiliser la déclinaison. De plus il ne faut pas dériver un superlatif d'un superlatif, ni un comparatif d'un comparatif, mais donner l'adjectif normal correspondant: le tableau de déclinaison ne doit pas les générer dans ces deux cas, mais seulement mentionner les 2 autres formes non accordées).

Je me demande aussi comment faire avec les autres possessifs (dérivés des pronoms personnels par exemple)... Si tu as des sources utiles, je suis preneur. verdy_p 20 janvier 2009 à 09:39 (UTC)

le superlatif se fait toujours en ajoutant nej- devant le comparatif.

Ça je le savais (je l'ai même mentionné ci-dessus), mais est-ce général ? Y a-t-il aussi des exceptions ? verdy_p 20 janvier 2009 à 09:39 (UTC)

Ça serait intéressant de demander à un bot de faire le travail (automatique pour les -cký et -ský qui ne connaissent pas d'exception) --Diligent 20 janvier 2009 à 09:27 (UTC)

en -chý

cher Verdy, je peux te passer commande d'un nouveau modèle ? Il nous manque en -chý pareil que pour -hý sauf que le masculin pluriel animé fait -ší après mouillage de la consonne. suchý en a besoin... --Diligent 1 février 2009 à 06:55 (UTC)

Tu peux vérifier suchý et hluchý ? Est-ce que cela correspond à ta demande ? Voir Modèle:cs-décl-adj-dur-chý.

Super ! Merci !

en -shý

Note : est-ce que cela s'applique aussi aux rares adjectifs en -shý ? Si oui vérifie le Modèle:cs-décl-adj-dur-shý (qui ne donne pas d'exemple directement mais mais des points d'interrogation sur la racine) et indique s'il y a lieu de l'ajouter (faut-il qu'ils "mouillent" le masculin animé pluriel en -ší au lieu de garder la déclinaison régulière -shí ?)

Je te demande ça car on a aussi des variantes similaires entre elles pour -cký et -ský, et j'ai trouvé des adjectifs tchèques en -shý... L'essai de déclinaison anticipe une généralisation de cette exception verdy_p 2 février 2009 à 07:37 (UTC)

hmmm... je ne sais pas. en fait ch est une lettre (équivalent au Ach! allemand) un h dur en somme. et en tant que tel se comporte differemment. Le sh est deux lettres et devrait se décliner selon -hý avec un s devant - je n'ai pas d'exemple en tete sur lequel tester le modele... --Diligent 3 février 2009 à 17:19 (UTC)

pour une conjonction : jenž

bonjour, j'ai utilisé le modèle pour la déclinaison de la conjonction jenž. Cela me pose deux problèmes : le vocatif ne devrait pas apparaitre et (problème mineur qui se réglera par un redirect quand les pages seront créées) l'accusatif masculin singulier et le génitif pluriel comportent deux formes complémentaires. que me conseillerais-tu avec ta connaissance des modèles ? --Diligent 15 février 2009 à 08:20 (UTC)

Participe présent

Bonsoir.

La plupart (totalité ?) de ceux que j'ai vu ici donner un avis sur le sujet sont d'accord pour dire que le participe présent ne s'accorde pas. Personnellement, je me considère comme ignare sur la question, mais j'ai lu ce que je dit Grevisse, et il ne dit rien d'autre.

Grevisse cite d'ailleurs une petite collection de verbes pour lesquels l'adjectif dérivé est différent du participe présent. Assez imparable, je pense.

Je souhaiterais modifier {{fr-conj}} en conséquence (ce qui ne veut pas obligatoirement dire supprimer, mais au moins reformuler).

Mais, pour être franc, je n'ai aucune envie de me fâcher avec toi pour un sujet si futile. Alors j'aimerais (je veux dire : il serait sympa) que tu me donnes ton feeling, afin que je pusse avoir moi-même une position sur cette question. En attendant, je ne ferai rien, bien sûr.

Amitiés. --Szyx 13 janvier 2009 à 19:32 (UTC)

Admettons que ces accords concernent les participes présents utilisés comme adjectifs : quand c'est le cas, l'adjectif masculin singulier est bien identique au participe présent (dans la quasi-totalité des cas). Ceci dit, j'attends encore de voir pourquoi on ne peut pas mentionner ces adjectifs alors que c'est le cas général, même s'il peut exister des exceptions pour certains adjectifs formés moins régulièrement.

Il y a bien un usage adjectival très courant et indubitable des participes présents (dans le français actuel), de la même façon que pour les participes passés (qui s'accordent eux aussi sauf pour les verbes intransitifs), même si le Grévisse s'appuie encore sur des emplois plus restrictifs et normatifs de la langue française (il semble qu'il s'agisse plus d'une forme de style considérée comme "impropre", mais dont l'usage s'est pourtant largement étendu en français sous l'influence des gérondifs anglais qui peuvent tous s'employer aussi comme adjectifs sans que cela cause le moindre problème de compréhension ; le Grévisse recommanderait alors plutôt l'emploi d'une proposition relative plutôt que l'usage adjectival et accordé du participe présent).

Doit-on accepter de ne garder que la forme de style "officielle" du Grévisse et bannir les usages modernes devenus courants ? Cela semble être opposé au fait qu'on accepte dans le Wiktionnaire de nombreux néologismes et nouveaux emplois, même s'ils semblent "impropres" pour les puristes attachés aux propositions relatives, alors que finalement le participe présent est beaucoup moins lourd qu'une proposition relative et clarifie le discours. Si le critère de style est retenu, il faudra trancher dans le vif dans le Wiktionnaire car on a accepté bien pire ! C'est bien mal servir la langue française que de ne pas montrer les usages courants (qui ne sont plus considérés comme fautifs et que tout le monde comprend !) Ce qui était l'exception pour certains verbes est devenu aujourd'hui une règle quasi-générale même si ça ne plait pas aux puristes. Ces adjectifs accordés se trouvent de de nombreuses publications de nombreux auteurs, y compris les plus illustres ou les meilleurs défenseurs de la langue française (Pierre Perret ne s'en est pas privé par exemple dans ses chansons, ni même des Académiciens dans leurs livres !)

Pour moi le style doit s'adapter au discours : il y a des cas où une proposition relative n'alourdit pas trop la phrase, et dans ce cas elle est recommandée même si on ne peut plus dire que ce doit être une règle absolue. Dans les autres cas, dans des phrases à la structure grammaticale déjà complexe, ajouter ou ou plusieurs proposition relatives est franchement affreux (répétition du "qui..., qui... et qui...") et rend la phrase quasi incompréhensible (surtout s'il faut plusieurs proposition relatives, là ou plusieurs participes accordés sont nettement plus faciles à comprendre et à dire, l'accord du participe permettant aussi de lever des ambiguïtés de sens qui existent avec des relatives). Certains affirment que c'est un anglicisme, je n'en suis pas convaincu quand on voit que l'usage est attesté depuis très longtemps pour certains verbes mais n'a fait que se généraliser : l'origine de cette forme n'est d'ailleurs pas l'anglais même s'il a influé pour accélérer cette généralisation, mais bien le latin qui ne se privait pas de cette forme. Aujourd'hui les adjectifs ne sont plus des mots "outils" mais font bien partie du lexique de base de la même façon que les noms ou verbes (et les utilisations des verbes en tant que noms, c'est à dire leur substantivation se sont aussi généralisées). Le tableau de conjugaison n'est pas là pour indiquer la nature grammaticale lors de l'analyse, mais bien pour montrer l'ensemble des emplois (certains y ont ajouté d'autres temps dérivés courants comme le passé proche et le futur proche avec aller et venir devenus des auxiliaires)

On peut peut-être alors modifier légèrement la présentation en indiquant les accords sous la dénomination "adjectif dérivé du participe" et non participe présent seulement. C'est un peu lourd quand même quand tout le monde comprend ce que signifient ces accords : ce n'est pas une conjugaison à proprement parler (à cause du type grammatical: des adjectifs et non des verbes) mais il y a pourtant bien des accords (et ces accords ne sont pas si évidents que cela, car ils ont des exceptions connues (ne serait-ce déjà que dans la prononciation, qui est correctement gérée).

On peut aussi éventuellement mettre une courte note sous le tableau pour dire qu'il s'agit d'adjectifs accordés et non de verbes conjugués, il n'y a pas de quoi supprimer toutes ces flexions correctement accordées et prononcées).

Note bien que les cas où l'adjectif ne se forme pas du tout (cas des verbes impersonnels uniquement, un cas finalement assez rare, et plus une exception que la règle), peuvent être marqués facilement comme invariables (et dans ce cas il n'y a aucun problème : le modèle gère le mode impersonnel et ne cherche pas à les accorder).

Pouvez-vous donner des exceptions où le règle utilisée nécessite autre chose que la gestion du mode impersonnel ? Pour l'instant je n'ai pas encore vu la moindre exception à cette règle simple déjà gérée.

Je note aussi que les différences orthographiques pour certains adjectifs viennent du fait que ces adjectifs exceptionnels sembleraient issus principalement du substantif (par exemple : fabricant) et non du participe présent, et dans ce cas il suffit de déclarer le participe présent (p.ex. : fabriquant) comme invariable. Ce n'est pas plus simple ? Pour le gérer il n'y a rien à toucher aux modèles, le paramètre pp.inv=1 est suffisant (et j'ai mis en place ce paramètre dès le début).

verdy_p 13 janvier 2009 à 20:15 (UTC)

Note: je n'ai pas le Grévisse sous la main (en tout cas pas une version assez récente). Tu mentionnes une courte liste d'adjectifs dérivés distincts, ne peux-tu pas la donner afin de le prendre en compte (il suffira alors juste d'ajouter pp.inv=1 pour ces verbes, à priori tous personnels puisque les verbes impersonnels sont déjà gérés) ? Il faudrait aussi lire dans le Grévisse si cela résulte d'une règle de style plus que d'une règle grammaticale. Ce que tu mentionnes comme "imparable" ne concerne que ces exceptions, mais certainement pas le cas général dans la langue actuelle (et on a bien aussi dans nos conjugaisons des formes qui a priori n'existaient pas dans le Grévisse ou le Bécherel qui mentionnait des temps ou personnes défectives : l'usage a évolué, par soucis de simplification et de généralisation, et accepte des formes autrefois considérées comme "fautives" ou "impropres"). Ce qui compte ce n'est pas tant ce que recommande une règle de style (ce dont on peut se passer) mais si la forme a un sens bien défini et bien compris (et dans ce cas le tableau donne bien les accords corrects pour ces usages, car il serait faux de dire que ces emplois adjectivaux ne s'accordent pas alors que justement l'accord aide à préciser le sens et s'impose très justement). verdy_p 13 janvier 2009 à 20:23 (UTC)

Euh, désolé de t'avoir dérangé, mais je jette l'éponge. Voir ma pu (j'en suis très content, en vérité). --Szyx 13 janvier 2009 à 21:33 (UTC)

Salut. [Désolé de m'incruster mais je n'ai pas retrouvé la précédente discussion à ce sujet.] J'attire simplement votre attention sur notre article participe (issu du DAF8) : « Forme verbale ainsi appelée parce qu’elle participe à la fois de la nature du verbe et de celle de l’adjectif. » L'article nous rappelle aussi que le participe présent « était variable dans l’ancienne langue ». Je suis d'accord pour garder les formes adjectivales dans le tableau de conjugaison et (pour contenter tout le monde, y compris Grevisse) mettre en regard la mention "adjectif verbal". A+. Stéphane8888 discuter 14 janvier 2009 à 10:26 (UTC).

• "adjectif verbal" ce serait un néologisme. Pour moi il n'y a que des participes avec deux emplois possibles :
  • verbal (gérondif impersonnel avec préposition ou gérondif personnel temporel, ou causal personnel, les formes personnelles induisant le sujet de la proposition principale)  : il ne s'accorde pas et reste au masculin singulier sous la forme transitive (directe ou indirecte) mais s'accorde sous la forme intransitive (sans objet) de la même façon que l'adjectif épithète.
  • ou adjectival (épithète ou attribut, même si l'emploi comme attribut est maintenant assez rare au présent mais il existe en français dans des poèmes d'auteurs célèbres ou quand l'adjectif a pris un sens particulier légèrement différent comme malfaisant, puisque le verbe gérondif s'est lui raréfié) si le verbe est personnel (lequel adjectif peut alors être substantivé aussi, comme aussi l'infinitif impersonnel).
  • Tout ça c'est bien compliqué à mettre dans un tableau, mais la distinction entre invariable et accordé n'est pas strictement celle de l'emploi adjectival ou non (pour le gérondif, purement verbal, on a une autre ligne dans le tableau qui le mentionne déjà comme invariable lorsqu'il s'emploie avec une préposition qui se substitue au sujet pour l'emploi impersonnel car le sujet/agent n'est pas celui de la proposition principal). On a tous les emplois permis sauf pour les rares verbes purement impersonnels qui ne peuvent s'employer au participe présent que comme gérondifs invariables. Et encore... On note même des emplois accordés (intransitifs, sans objet) dans ce cas, comme dans les mois de décembre neigeants ne sont pas rares par dérivation d'une forme personnelle renversée au figuré (pour dire il n'est pas rare qu’il neige les mois de décembre), de la même façon que la forme personnelle figurée décembre ne neige pas rarement lequel peut parfois être aussi transitif avec un objet indirect !). Ces formes accordées sont assez courantes dans les phrases énumérant une liste de participes présents intransitifs (sans objet mais avec un adverbe encore possible), ou lorsqu'ils s'accompagnent d'un adverbe (souvent quantitatif) en poésie, et littérature classique (qui adore les énumérations). verdy_p 14 janvier 2009 à 13:24 (UTC)

Moi je suis contre pour plusieurs raisons :

• aucun dictionnaire de conjugaison n'indique d'accord des adjectifs : il doit bien y avoir des raisons ;
• ambigüité : on ne distingue pas le participe passé de l'adjectif, alors que leurs emplois sont différents ;
  • pas d'ambiguïté: la flexion seule suffit à indiquer l'usage, les flexions sont formantes et très régulières ; à de rares exceptions près pour (1) quelques verbes personnels qui adoptent une orthographe légèrement différente tirée du substantif et non du verbe (bien que le substantif vienne à l'origine du participe lui aussi, suite à une bizarrerie d'évolution orthographique pour la forme substantivée du participe) ; ou (2) pour tous les verbes strictement impersonnels très peu nombreux). verdy_p 14 janvier 2009 à 13:24 (UTC)
• ce sont des pages de conjugaison des verbes : on indique leurs formes, pas leurs dérivés ;
  • l'adjectif est bien une flexion du verbe et se déduit directement de sa conjugaison. L'usage, lui, n'est pas défini dans les tabeaux de conjugaison qui devraient donner toutes les flexions. verdy_p 14 janvier 2009 à 13:24 (UTC)
• le participe présent n'est pas toujours utilisé comme adjectif, même pour des verbes courants (mangeante, travaillante, livrante ?).

  Tu es sûr ? Ce sont des exceptions apparente car il y a une autre forme courante plus évidente pour l'adjectif (mangeur/mangeuse, travailleur/travailleuse, livreur/livreuse, mais avec une nuance de sens qui n'indique pas l'action effectuée mais une fonction attribuée à une personne et pas ce qu'elle fait ou a fait réellement dans le contexte d'utilisation de la phrase mentionnant le participe), mais rien n'interdit cet usage grammaticalement (et sémantiquement). Le véritable équivalent est la proposition relative (qui mange, qui travaille, qui livre) mais elle est terriblement lourde dans certaines phrases et conduit à des ambiguités de sens en cas de conjonction de plus de deux relatives, là où la forme adjectivale n'introduit pas d"ambiguïté et est même plus précise que la relative (selon le sens ou la fonction qu'on peut donner au pronom personnel relatif qui). Pour mois ce que tu mentionnes n'es qu'une préférence de style pour les cas courants, mais pas une obligation universelle. verdy_p 14 janvier 2009 à 13:24 (UTC)

L'accord du participe passé est tout à fait justifié, mais le participe présent non : il est sensé être invariable, laissons-le comme ça. -Dakdada (discuter) 14 janvier 2009 à 11:20 (UTC)

• Selon la définition même des participes, ils peuvent s'employer tous comme adjectifs sauf s'ils sont strictement impersonnels. verdy_p 14 janvier 2009 à 13:36 (UTC)

  Après réflexion, je pense qu'on peut adopter adjectif verbal (et mentionner alors la petite vingtaine d'exceptions orthographiques qui diffèrent du participe présent, ainsi que les ceux dérivés des verbes en -guer -> -gant(es) ou -quer -> -cant(es)). Réf. : http://www.lepointdufle.net/participepresent.htm verdy_p 14 janvier 2009 à 14:34 (UTC)

Merci, je vais y réfléchir. - Dakdada (discuter) 14 janvier 2009 à 13:43 (UTC)

• Pour résumer, les exceptions pour les adjectifs verbaux sont : adhérent(es), affluent(es), coïncident(es), convergent(es), déférent(es), détergent(es), différent(es), divergent(es), émergent(es), équivalent(es), excellent(es), expédient(es), influent(es), négligent(es), précédent(es), résident(es), somnolent(es) et violent(es), les verbes en -guer et -quer (et les verbes impersonnels normalement sans adjectif verbal). Maintenant je me demande l'utilité de la ligne "gérondif" si on fait la distinction entre participe présent invariable et adjectif verbal (les deux étant très liés et traités ensemble dans les cours de grammaire).
• Si on garde la ligne du gérondif positif (en+participe présent ou en ayant+participe passé), il ne serait pas inutile de donner sur une autre ligne sa négation (gérondif négatif), au présent (de préférence sans+infinitif présent, au lieu de en ne+participe présent+pas, assez lourd même si on le rencontre dans la langue commune) comme au passé (car il se base de préférence sur l’infinitif passé positif en changeant la préposition sans avoir+participe passé, au lieu du participe présent négatif de l'auxiliaire en n'ayant pas+participe passé, d'emploi encore plus lourd). De plus le gérondif n'est pas réellement un mode impersonnel : il y a bien un agent personnel même s'il n'y a pas de sujet explicite, le en remplaçant le sujet induit de la proposition principale (simultanée ou causée ou conditionnée). verdy_p 14 janvier 2009 à 13:57 (UTC)

Je viens de voir cette discussion et je voudrais juste dire : non, un participe n'est pas un adjectif, et un adjectif n'est jamais un participe. Un participe est une forme verbale, c'est tout. Simplement, certains adjectifs et certains noms dérivent de participes (par exemple sucré, repentant, le passé, l'allant, le fabricant...) On les appelle parfois adjectifs verbaux et noms verbaux (ce qui est assez trompeur), mais ce ne sont pas des participes, simplement des mots qui ont un participe comme étymologie. Et non, il n'y a aucune règle qui généralise cette dérivation participe -> adjectif ou participe -> nom. Le participe présent est toujours invariable, le participe passé le plus souvent variable, mais pas toujours. — Lmaltier 19 janvier 2009 à 21:18 (UTC) (ta signature est corrigée depuis l'historique) verdy_p 19 janvier 2009 à 21:31 (UTC)

Visiblement tu manques de références et tu es mal informé... La quasi-totalité des traités de grammaire traitent les deux cas ensembles (justement car ils sont tellement proches que c'est presque une règle en français et que les cas où ce n'est pas le cas sont traités comme des exceptions à la règle; c'est la séparation des deux qui est contraire à l'usage de la langue) ! On a une flexion principale (parfois mais rarement deux) du verbe, deux types d'usages avec leurs règles d'accord (comme on a aussi des règles d'accord assez complexes des participes passés avec des exceptions assez complexes, bien plus complexes en fait que pour les participes présents).

Et les dénominations "adjectif verbal" et "nom verbal" sont attestées dans ces traités de grammaire, et justement le cas de la dérivation des participes présents (ou du gérondif qui est un mode verbal comme l'est l'infinitif ou le participe, et qui suit d'autres règles bizarre pour la négation qui change sa conjugaison...) est très ancien puisque cela vient du latin (où les gérondifs s'accordent même en cas !), ces gérondifs étant à l'origine des noms et adjectifs actuels... Quant aux rares bizarreries d'orthographes différentes entre participe et adjectif, cela vient là encore du latin (parfois aussi par amuïssement phonétique selon l'usage) : la dérivation est venue du gérondif plutôt que de l'infinitif... verdy_p 19 janvier 2009 à 21:29 (UTC)

Merci de fournir une liste de cette "quasi-totalité". (parce que ce n'est pas ce qu'on apprend à l'école).

Ca dépend de quelle école et de quel prof ! Ils insistent plutôt pour les accorder là où il le faut (presque partout en fait !), et ne mentionnent que très rarement les rares cas d'invariabilité ! verdy_p 19 janvier 2009 à 22:03 (UTC)

Si tu n'en trouves pas suffisamment, je te conseille d'écrire un traité de grammaire sur le sujet, et d'en reparler quand il aura eu du succès. Il est facile de vérifier sur Internet : les sites Internet sont nombreux sur ce point, et insistent tous sur le fait qu'un adjectif verbal et un participe, ce n'est pas la même chose. Lmaltier 19 janvier 2009 à 21:48 (UTC) Ah, je crois que je comprends : si on en parle ensemble dans les traités de grammaire, c'est pour expliquer la différence, parce que la confusion est facile. Lmaltier 19 janvier 2009 à 21:50 (UTC)

Tu viens donc comprendre toi aussi qu'on doit bien évoquer les deux. La seule chose que ne distingue pas le tableau c'est l'utilisation faite entre les deux, mais on doit pourtant bien mentionner les deux. Ce qui avait été retenu ci-dessus c'est de préciser "adjectif verbal" (attesté partout, même sur Internet sauf ceux qui se contentent de conjuguer les verbes mais pas de faire un vrai traité de grammaire et n'expliquent rien du tout) pour arrêter les critiques. Et dans ce cas, on doit l'accorder (car les règles ne sont pas si simples, le mot "invariable" seul pouvant être encore plus trompeur!). verdy_p 19 janvier 2009 à 22:00 (UTC)

Non, tout au contraire. Personne ne mentionne d'adjectif dans un tableau de conjugaison (cite-moi une seule table de conjugaison qui mentionne un adjectif, ou qui mentionne un participe présent variable), tout simplement parce que ce n'est pas une forme du verbe, et que ça ne pourrait donc qu'entraîner des confusions si on le mentionne dans la liste des formes du verbe (on le voit bien dans tes propos). Ce que j'ai déjà proposé, c'est de mettre une note explicative dans les pages concernées (pages de flexion / adjectif) quand on le juge utile. Lmaltier 20 janvier 2009 à 06:42 (UTC)

Je rejoins l'avis de Lmaltier. Le participe présent est une forme de verbe et doit donc figurer dans les tableaux de conjugaison, tandis que l'adjectif, quand bien même fût-il formé à partir du participe présent, n'a rien à y faire. Tout ce qu'on réussira à faire à les mélanger c'est perdre nos lecteurs (dans les deux sens). - Dakdada (discuter) 20 janvier 2009 à 08:45 (UTC)

Petit reproche

Cher Verdy_p, tu m'avais demandé ce qu'on (ou en tout cas moi) te reprochais, voici un de ces reproches : tu écris trop, sans beaucoup d'aération, en évoquant beaucoup de points, et ça ne donne pas envie de te lire (en supposant déjà qu'on en ait le temps). Les discussions en deviennent souvent des fleuves qu'il est presque impossible de relire, surtout si on débarque au milieu de la discussion. Ne pourrais-tu faire un effort pour synthétiser tes propos (quitte à ne pas répondre tout de suite) ? - Dakdada (discuter) 14 janvier 2009 à 10:50 (UTC)

Wiktionnaire:Gestion des modèles/Suppressions : tu ne devrais pas faire des modifications comme celles-là

Faire ainsi ce genre de modifications globales [4] ne peut être que considéré ainsi : une volonté de faire en sorte que les autres contributeurs ne puissent pas comprendre ce que tu voulais faire. En conséquence, je vais annuler ta modification, et tu seras gentil de la refaire section par section, en commentant tes modifications. Merci. --Szyx 19 janvier 2009 à 20:36 (UTC)

Euh, cela ne veut pas dire que je pense que tu as tort, non. Juste qu'il faut que tu expliques. --Szyx 19 janvier 2009 à 20:53 (UTC)

La structure des tritres dans la page donnait un sommaire faux. C'est normal que ce n'était pas fait section par section. Les titres de dates n'apportent rien (on a des archives au besoin et les messages sont dates dans les signatures). verdy_p 19 janvier 2009 à 20:55 (UTC)

Je n'ai pas mis en doute ton intégrité (désolé si j'ai laissé penser le contraire) mais ta vérifiabilié, ce qui est important sur un wiki. --Szyx 19 janvier 2009 à 20:58 (UTC)

Je te présente mes excuses, mon procédé n'était pas correct. --Szyx 20 janvier 2009 à 08:55 (UTC)

{{fr-accord-ef}}

Pas plutôt redondant ? Voir ici. Urhixidur 24 janvier 2009 à 04:32 (UTC)

Je ne suis pas d'accord, le modèle -if n'est pas fait pour ça, et en fait c'est un modèle générique en -f qui doit être créé. Le nombre de paramètres optionnels et leur signification dépendante de la position milite plutôt en faveur de la suppression du modèle en -if qui est mal fichu. Le modèle en -f est bien plus simple, et le modèle -if ne supporte plus toutes les options: les paramètres sont fixes. Il n'y a plus redondance et c'est nettement plus clair dans les articles (on avait fait une trop grande unification en faisant perdre tout le sens commun). verdy_p 24 janvier 2009 à 04:35 (UTC)

Note j'avais déjà fait les modifs : le modèle en -if est celui à supprimer en fait : il n'est plus utilisé que pour les mots en -if(s)/-ive(s) et avec 4 paramètres, là où 2 paramètres suffisent avec le modèle en -f... Si j'ai gardé le modèle if, c'est uniquement pour le cas simple, mais c'est bien lui qui est redondant et devrait être remplacé (il n'y a plus de mots en -f utilisant le modèle en -if si ces mots ne se terminent pas eux-mêmes en -if : les autres mots utilisent déjà le modèle en -f. Le travail de simplification peut être achevé par bot (si c'est nécessaire, bien que la séparation des mots en -if a un avantage: on n'y trouve tous les nombreux mots en -if sans aucune exception, alors que si on remonte à -f, on va mélanger les mots en -euf et -ef, ce qui n'est pas un gros problème ici puisque ce ne sont pas de vraies exceptions; les mots en -ef sont en revanche séparés la liste de ces exceptions sort de la grande liste générale).

Cela n'avait aucun sens d'utiliser un modèle nommé en -if pour lui fournir un nombre variable de paramètres utilisés de façon conditionnelle pour finalement traiter des mots qui ne sont pas en -if...

Pour la stabilité (et les évolutions futures de ces modèles), il ne faut pas les surcharger de façon à ce qu'un même paramètre puisse prendre différents sens selon le nombre des autres paramètres. C'est ce que j'ai réglé : le nombre de paramètres positionnels (obligatoires) est maintenant fixe (les paramètres optionnels sont nommés). verdy_p 24 janvier 2009 à 04:56 (UTC)

Modèles de langues

Salut,

Une discussion a commencé sur la Wikidémie (qui a un peu dévié) où j'ai proposé de simplifier l'usage des modèles de langue, en remettant seulement le nom des langues dans ces modèles, comme c'était l'usage auparavant.

Après réflexion, il me semble que cette modification ne devrait pas remettre en cause la présence des modèles de données supplémentaires que tu as créés, genre {{en/type}} (bien que je sois encore sceptique quant à leur usage, mais là n'est pas la question). Il suffirait en effet de définir le nom de langue dans le modèle, et d'invoquer ce modèle dans la liste des données : le modèle de langue {{en}} ne contiendrait donc plus que le nom de la langue, comme auparavant. Cela te poserait-il un problème que je fasse cette simplification ? - Dakdada (discuter) 28 janvier 2009 à 16:28 (UTC)

Oui énormément ! Tout bonnement car il y a énormément de modèles, et que ta demande revient à les dupliquer et oublier le paramétrage. C'est déjà compliqué de vérifier plus de 800 modèles, si il faut refaire ce travail pour plus 800 autres, je ne vois pas l'intérêt. (D'autant que le nombre de langues continue de monter, le coût de maintenance va donc croître si on multiple les modèles à modifier...) La page d'aide donne aussi immédaitement un rendu permettant de vérifier que le paraétrage s'est fait correctement, sans "se mélanger les pinceaux".

Franchement qu'est-ce qui te dérange étant donné que ces modèles étendus n'ont pas modifié ni compliqué les articles ou les autres modèles qui les utilise ? Note bien que dans nombre de cas ces modèles savent ainsi prendre des valeurs par défaut (ce qui simplifie le paramétrage et réduit considérablement le travail), et que ce que tu demande rendra ces valeurs par défaut inutilisables.

Je ne veux plus revoir des propositions comme des modèles avec des noms "imbitables" comme "en2" ou "en3" et impossibles à généraliser car leurs noms sont ambigus ou non homogènes, ou qui ne sont plus à jour et entre eux se contredisent, comme ça s'est vu (ensuite le travail pour savoir ce qui devait être indiqué à un endroit et pas modifié dans un autre devient hardu : on perd la trace des sens initiaux; le nombre d'endroits à modifier se multiplie alors vite de façon exponentielle, avec certaines langues supportant certaines fonctions prétendues généralisées à toutes, et certaines autres en manquant, ce qui poussera alors tout le monde à devoir en ajouter à tout instant, ce façon inhomogène ou contradictoire).

J'ai évité la multiplication des modèles inconsistants et centralisé leur documentation dans une seule page (qu'il n'est pas nécessaire de corriger à chaque fois et qui contient les tests nécessaires de rendus). Au passage plein de modèles annexes dépendant de la langue ont pu ainsi être généralisés, on a allégé les articles.

Qu'est-ce que ta proposition va apporter ? Combien manque-t-il de langues non supportées ? Quelle est la fréquence de ces ajouts nécessitant un paramétrage ? Franchement tout cela est quasi-voisin de zéro puisque tout y est ou presque. La méthode actuelle permet une syntaxe très simple (voir "Modèle:la" pour le cas le plus simple du latin), quitte à ce que les autres paramètres soient renseignés plus tard en fonction des besoins rencontrés. Je ne vois pas du tout "qui" ni "ce que" le système étendu vient bloquer. Et en quoi cette syntaxe est compliquée à lire même dans les cas de paramétrages plus avancés (qui de toute façon n'a pas besoin d'être édité tous les jours).

Je pense donc que ton "après réflexion" ne prend pas en compte du tout les avantages apportés en terme de maintenance. Il est très approximatif. RIEN dans ces modèles étendus n'a compliqué les modèles et pages qui les utilise, puisque la syntaxe d'appel est restée inchangée pour afficher le nom de langue. Ta proposition aura une conséquence rapide : celle de favoriser l'émergence de variantes pour certaines langues, ou l'ajout intempestifs de paramètres optionnels pour certaines et pas pour toutes (comme on a pu le voir pour le chinois), ce qui cassera la structure logique des pages et compliquera leur compréhension non seulement par les robots mais aussi par les contributeurs qui devraont se demander à chaque fois quels paramètres mettre en fonction d'une langue ou d'une autre langue "similaire" (mais au paramétrage oublié ne disposant pas de la prise en compte de cette spécificité, ou des paramètres différents).

verdy_p 30 janvier 2009 à 10:19 (UTC)

Ce qui me dérange c'est que, encore une fois, tu me fais une réponse très longue tellement alambiquée que j'ai l'impression de devoir faire une dissertation chaque fois que je veux te répondre. Tu n'as manifestement même pas compris ce que je voulais faire, et tu parles à côté de problèmes qui ne se posent même pas ! Relis donc et tu verras que je ne propose rien d'aussi terrible que ce que tu sembles croire. - Dakdada (discuter) 30 janvier 2009 à 12:58 (UTC)

Trois inconvénients incontestables (et extrêmement gênants) :

• c'est beaucoup plus compliqué quand on veut toucher au modèle (tellement compliqué que beaucoup renoncent, est-ce que c'est le but ?)
  • Ce n'est pas une bonne raison, ces modèles sont rarement modifiés, et ce n'est pas si compliqué que ça: tout est dans un modèle dont la syntaxe est limitée au maximum, et en plus la plupart sont déjà tous paramétrés (donc "l'effort" à fournir est très occasionnel et ne touche pas au reste des articles). Ta proposition ne permettra pas de toute façon de gérer les autres valeurs que le nom, et donc le problème reste entier (et je ne veux pas non plus multiplier le nombre de sous-modèles, même si cela simplifierait le paramétrage, justement à cause du problème des performances et du nombre de modèles ***distincts*** inclus dans les pages.
• utiliser les paramètres de ces modèles rend les pages illisibles (y'en a qu'ont essayé, et ça a été révoqué, à juste raison, c'était absolument incompréhensible)
  • Ce n'était pas le but, mais la solution simple que je voulais a été bloquée avant que je puisse l'appliquer (voir ci-dessous).
• ça ralentit tout le monde. Si tu n'es pas convaincu, essaie la page Inde en mode modification, et regarde la liste des modèles utilisés : on pourrait diviser le nombre de modèles par 2 en revenant à la raison. Et ça veut dire que la page à afficher par le navigateur est plus lourde en mode modification, et toujours plus gourmande sur le serveur, même en lecture. Lmaltier 30 janvier 2009 à 13:36 (UTC)
  • Quelle "raison" ? Ce n'est pas vrai que cela divisera le nombre de modèles par deux (je m'en explique plus bas, il y a autre chose que la seule indication du nom des langues); les pages contenant des centaines d'utilisations sont très peu nombreuses dans le Wiktionnaire; chrono en main, ces modifs, même faires par un Bot dans un tel article prennent moins d'une seconde, et la plupart du temps moins de 10 millisecondes, loin de la limite, ce qui laisse encore largement la place pour des modifs massives d'articles par Bot, qui se font au rythme maximum d'une page par seconde selon la politique actuelle des Bots: le temps pris par les bots n'est pas celui de l'inclusion mais du chargement et de la sauvegarde des articles, les modèles eux-mêmes restant en cache la plupart du temps lors de modifs massives et même lors de modifs indépendantes par des utilisateurs distincts: le temps n'est un peu plus long QUE lorsqu'il y a peu de monde sur le site, et pas de Bot actif car les modèles ne sont plus en cache).
    • En lecture seule, cela ne ralentit pas non plus: MediaWiki stocke les expansions de modèles dans un cache final, lors de la sauvegarde (il n'invalide ce cache qu'en cas de modif d'un modèle lié dépendant, ce qui ici veut dire: modif d'un modèle langue existant, cas exceptionnel).
    • verdy_p 4 février 2009 à 20:01 (UTC)

Je vais essayer de résumer ce que je souhaite faire, apparemment je n'ai pas été clair. Actuellement on a :

{{en}}	{{lang/}}	{{en/type}}
{{lang/{{{type|}}}|en}}	renvoi vers {{en/type}}	{{#switch:{{{1|}}}|'=oui|mp|mp.cat|=anglais|ISO name=English|?}}

Le modèle {{en}} inclus donc le(s) modèle(s) {{lang/}}(type), lui-même redirigeant vers le sous-modèle {{en/type}}.

Ce que je propose, simplement :

{{en}}	{{en/type}}
anglais	{{#switch:{{{1|}}}|'=oui|mp|mp.cat|={{{{BASEPAGENAME}}}}|ISO name=English|?}}

Le modèle {{en}} inclus seulement le nom de la langue, qui est récupéré automatiquement par le modèle {{en/type}}. Pas de modèles intermédiaires qui encombrent les articles.

De cette manière on peut toujours utiliser les données supplémentaires en utilisant {{en/type}}, et les modèles de langue redeviennent simples, comme auparavant. L'ajout d'une nouvelle langue est là aussi tout aussi simple (création du modèle avec juste le nom de la langue dedans).

Je ne vois pas de problème que ça poserait. - Dakdada (discuter) 3 février 2009 à 16:53 (UTC)

Je vais y réfléchir. Désolé la suite va être un peu longue, il y a plein d'idées différentes et de cas à considérer et je suis bien conscient que la solution actuelle donne un compromis "simple" pas si lourd à gérer (la complexité toute relative concerne des modifs exceptionnelles très rares quand on doit modifier certaines valeurs par défaut).

Je voulais aussi que tous les modèles de langue utilisent le même modèle de base lang/type pour déduire toutes les valeurs par défaut, aussi au départ {{lang/type}} était utilisé à cette fin; cependant je me suis rendu compte assez vite qu'on pouvait appeler directement lang/type en substituant le paramètre type sans passer par un modèle intermédiaire (ce qui a réduit le nombre d'inclusions).

Note toutefois que la paramètre 1 a un autre usage : il contient le texte optionnel dans cette langue, et s'il est renseigné, ce n'est pas {{lang/}} qui sera appelé mais {{lang/span}} avec le même paramètre 1 (passé en 2, le 1 étant le code langue) : le type par défaut devient "span" et le sous-modèle appelé sera {{lang/span}} et non {{lang/}} (c'est en place dans certaines langues, pas dans toutes à cause du blocage actuel des modèles les plus fréquents comme mobilien).) Le but était de ne pas avoir à paramétrer deux modèles mais un seul (contenant toutes les valeurs non déduites par défaut par un des modèles lang/type.

Ce que je voudrais c'est bien avoir un code du genre {{en|texte en anglais}}, mais pas un code compliqué {{en/span|texte en anglais}} (qui mercherait aussi mais impose de multiplier les modèles), ni {{lang/span|en|texte en anglais}} (qui fonctionne sans avoir à créer plein de modèles) pour formater le texte dans la langue (et aussi déduire les polices et tailles par défaut, ou positionner les classes CSS (indication de l'écriture et de la langue) afin d'avoir un rendu correcte des écritures.

Actuellement, les classes CSS d'écriture n'existent pas (pas encore) dans la feuille de style générale (le code CSS pour indiquer les polices et adaptations de taille est généré en ligne dans {{lang/span}} ou {{lang/div}}).

Mon idée a été reprise sur le Wiktionnaire anglais où j'ai communiqué ces idées (il a lui aussi défini des classes CSS pour les écritures et langues, afin de paramétrer des listes de polices par écriture ou par langue-écriture, mais n'a pas été jusqu'au bout de la logique, et la méthode utilisée se fait par substitution de tous les modèles dans toutes les pages, c'est à dire des milliers/millions de pages à mettre à jour de façon lourde par Bot à la moindre modification, et la présence de Bots chargés de tout corriger en permanence, donc un problème permanent de maintien de la cohérence d'ensemble et de très nombreuses et fréquentes modifs dans les articles).

La seconde idée était aussi de permettre aux utilisateurs de définir leurs propres listes de polices si nécessaire dans leur Monobook.css s'ils ont des polices supplémentaires (j'ai fait des recherches sur les polices Windows, Office et polices libres, mais il en manque encore pour les polices MacOS X (les polices libres sont en général de qualité trop insuffisantes pour Windows et MacOSX qui ont leurs propres polices commerciales certes, mais bien meilleures); c'est possible grace aux classes (à condition de transférer les listes de police dans la feuille CSS générale du Monobook du site).

Si on ne met pas du tout ces polices, la plupart des écritures ne sont pas supportés par les navigateurs, sauf au prix d'un paramétrage très compliqué à faire par tout le monde, sans possibilité non plus d'afficher ces écritures correctement pour ceux qui n'ont pas de compte ou ne sont pas connectés). Les listes prédéfinies de paramétrage au sein du dialogue de configuration des navigateurs sont aussi trop insuffisantes encore aujourd'hui (il manque trop d'écritures, et le paramétrage ne peut se faire correctement par langue ou langue-écriture, ce qui a trop d'effets de bords dans les pages multilingues), ce qui impose de préciser des classes CSS autour du texte à mettre en forme.

Ça peut s'arranger, et ce serait d'ailleurs bien mieux que ce qu'on a actuellement (il suffit de regarder le code source des pages contenant des modèles {{trad}} : chacun inclus une description de style : si ça, ça n'alourdit pas les pages…). Si tu me donnes le code qu'il faudrait intégrer au css (classes, :lang), je pourrais le faire vite fait (la page concernée est Mediawiki:Common.css). On pourra alors se contenter de mettre une classe et des attribut lang= dans les span sans avoir à réécrire le style à chaque occurrence. - Dakdada (discuter) 16 février 2009 à 16:02 (UTC)

J'ai bien essayé de réduire le nombre d'inclusions au maximum, mais il est difficile d'avoir un modèle qui ne fait que retourner le nom de langue et un autre général (avec le suffixe "/type") retournant certaines valeurs (mais pas toutes car la plupart prennent des valeurs par défaut avec un code partagé dans toutes les langues). L'alternative aurait été de ne pas avoir du tout de valeurs par défaut, mais alors il faudrait paramétrer TOUTES les valeurs explicitement, et la longueur globale des modèles inclus s'en ressent fortement (alors que le code partagé par un modèle inclus plusieurs fois n'a pas de coût important sur le serveur qui maintient les modèles déjà inclus une fois en cache et n'a pas besoin de les relire par un accès disque ou base de données): cette solution augmente nettement les performances (et réduit nettement la taille en mémoire lors de l'expansion des modèles).

On peut trouver un compromis, mais ce ne sera pas si évident que ça. La solution actuelle n'oblige pas à faire un paramétrage complet d'une langue dès le départ: pour ajouter une langue, on donne son nom, on paramètre plus complètement plus tard et cela autorise les traductions avec un affichage correct immédiatement (au moins pour les langues à écriture latine, puisque l'écriture latine supposée par défaut). L'uniformisation des modèles simplifie aussi la maintenance déjà lourde: on a déjà plus de 800 langues (ou variantes d'écriture), et si on doit paramétrer 2 modèles ou plus, ça multiplie le nombre de modèles à maintenir (ce n'est pas infaisable, on peut imaginer que le modèle en/type de paramétrage est utilisé comme référence source, le modèle de base en pourrait se fabriquer automatiquement ou se régénérer par substitution par un Bot simple.

Jusqu'à présent je n'ai pas vu le moindre problème de performance ni de saturation mémoire ou plantage sur les pages les plus lourdes (mentionnant les modèles de langue des centaines de fois). De ce fait je ne vois pas encore où est l'urgence de la modification que tu veux proposer. Je me suis arrangé dès le début pour maintenir la compatibilité (pour ne pas avoir à éditer des milliers/millions d'articles, puisque la logique interne est invisible dans le codes des pages ou des autres modèles qui référencent les modèles de langue ne serait-ce que pour indiquer le nom de langue). Note bien qu'il n'y a pas que le nom de langue à afficher, même pour les traductions: l'affichage est aussi à gérer pour les mots traduits eux-même (de ce fait cela ne réduira pas du tout le nombre de modèles inclus dans les pages, bien au contraire!).

Si vraiment c'est le nombre de modèles restant lors de l'expansion qui te pose problème, la seule solution serait de forcer l'inclusion par subst, mais il faudra un bot de maintenance permanente (comme sur le Wiktionnaire anglais), mais on n'a pas ici les ressources et le suivi nécessaire pour assurer la cohérence.

verdy_p 4 février 2009 à 19:48 (UTC)

Modèles de langues : ?/type

Tu constateras ici que quelque chose cloche avec {{lang}} : on a 886 cas où le « modèle » ?/type est appelé. Ça semble provenir d’appels aux champs span et div dudit modèle. Peux-tu régler ça ? Urhixidur 20 avril 2009 à 13:45 (UTC)

OK, c'est un problème mineur, spécifique aux pages de documentation des sous-modèles, mais qui n'affecte pas les articles.

Je vais voir comment éviter cette exception, sans que cela complique trop le code.

au passage je vois que certains modèles langue/type manquent encore il faudra que je repasse en revue cette liste ce sera moins compliqué et plus urgent que l'autre modification qui est plus risquée. 11 août 2009 à 18:44 (UTC)

Modèle aide

Salut Verdy_p,

j'ai créé le modèle {{aide}} à titre expérimental pour le distinguer du modèle {{documentation}} qui a un autre rôle. Pourquoi fusionner les deux ? - Dakdada (discuter) 5 février 2009 à 13:20 (UTC)

Il a le même rôle. Exactement. C'est le nom qui choquait ça se fusionne (j'ai gardé ton nom "aide", même si "documentation" est là depuis un bon moment, alors qu'il y a eu dans le passé des modèles aide supprimés depuis, le nom "documentation" vient de Wikipédia; ce sont des synonymes ici). Il gère seulement plus de choses (y compris les bacs à sables et pages de tests, et d'autres fonctions). verdy_p 5 février 2009 à 13:24 (UTC)

Si je l'ai créé, c'était pour avoir un modèle différent, avec un rôle différent (une boîte à lien vers la doc / une inclusion de la doc, ce n'est pas la même chose). Soit on utilise l'un, soit on utilise l'autre, mais les fusionner n'a aucun sens, sauf à vouloir imposer l'un sur l'autre (j'espère que ce n'est pas ce que tu essayes de faire). - Dakdada (discuter) 5 février 2009 à 14:19 (UTC)

Je ne vois pas du tout l'intéret d'avoir un lien vers la page de doc, quand le fait de mettre noinclude suffit totalement dans tous les cas ! D'autant que ta proposition oblige à mettre les métadonnées dans le modèle et non dans la page de doc puisque tu ne veux pas l'inclure (pour une mauvaise raison, car tu t'es trompé à ce sujet: les sous-pages inclues dans noinclude dans un modèle ne sont jamais comptées et n'impacte jamais les articles ou autres modèles qui utilisent ces modèles, la preuve étant que ces inclusions ne sont PAS ajoutées aux listes de dépendance des pages: cette inclusion dans noinclude n'affecte QUE la page courante (c'est à dire la page du modèle lui-même quand elle inclue localement la sous-page d'aide; c'est vrai depuis plus de 2 ans sur TOUS les serveurs de MediaWiki, dans TOUS les projets et TOUTES les langues) !). verdy_p 5 février 2009 à 14:26 (UTC)

C'est un sujet à discuter : la seule chose que tu as faite jusqu'à présent c'est imposer tes modifications sans concertation. - Dakdada (discuter) 5 février 2009 à 14:37 (UTC)

S'il te plaît, arrête de flooder les Modifications récentes. Ce travail doit être réalisé par un vrai bot, et après concertation. - Dakdada (discuter) 5 février 2009 à 14:15 (UTC)

Ce n'est pas vrai: une modif a été forcée avant moi avec de mauvaises raisons (arguments faux). verdy_p 5 février 2009 à 14:39 (UTC)

Tu parles de mes essais sur {{pron}} et compagnie ? C'était à but démonstratif (je concède que j'aurais dû le faire sur des modèles de moindre importance). Mais en quoi cela te donne-t-il le droit de tout modifier à ta guise ? - Dakdada (discuter) 5 février 2009 à 14:52 (UTC)

Justement, ce modèle d'importance a seulement été restauré. Car la démonstration n'est pas du tout probante (les causes et les conclusions sont fausses, de même que la tentative de "correction" d'un problème qui n'est pas là où tu l'as dit, si problème il y a). verdy_p 5 février 2009 à 14:58 (UTC)

Tu dévies de ce dont je parle : ce que je dis c'est que tu ne devrais pas continuer de modifier les modèles alors qu'on est en train d'en discuter et qu'on n'est — de toute évidence — pas d'accord sur les changements effectués. Ne serait-ce que par courtoisie, merci d'arrêter la modification de ces modèles. - Dakdada (discuter) 5 février 2009 à 15:29 (UTC)

64 pages en 3 minutes, c'est un flood ? Tout a été validé à la main. verdy_p 5 février 2009 à 14:27 (UTC)

Ben… oui, c'est du flood. Et c'est d'autant plus embêtant que ce sont des modifications sur un sujet que nous sommes en train de discuter. Bref, encore une fois ça donne l'impression que tu cherches à imposer ton point de vue. - Dakdada (discuter) 5 février 2009 à 14:37 (UTC)

Tu n'as toujours pas justifié la fusion des deux modèles. Si tu ne trouves rien de convainquant, je remettrais le modèle {{documentation}}, parce que, au cas où tu ne l'aurais pas remarqué, le modèle {{aide}} est un modèle expérimental que j'ai créé pour être différent de {{documentation}}. — Dakdada (discuter) 6 février 2009 à 09:44 (UTC)

en:Template:cs-decl-noun-auto

Je découvre la puissance et la flexibilité du modèle de déclinaison des substantifs tchèques sur le Wiktionary. Tu pourrais me l'adapter ? --Diligent 18 février 2009 à 05:06 (UTC)

Je me méfie de la méthode employée, car l'auteur de la spécification de base admet qu'elle est incomplète et peut souffrir de pas mal d'exceptions qu'il sera alors très compliqué de maintenir sans obtenir un modèle énorme à terme.

(Heureusement qu'on n'a pas employé cette méthode brutale pour le français, et notamment les conjugaisons !)

On peut s'en passer pour l'instant en séparant les modèles, même si on retient les principes généraux pour classer les différents cas avec des modèles plus simples (même s'il faut faire l'effort de choisir le modèle). De plus les modèles séparés permettent de plus facilement glisser des notes spécifiques, des références, et citer les exceptions ou règles générales dans chaque modèle (ce qui peut donner un résultat plus didactique facilitant l'apprentissage des tableaux les plus importants, et des exceptions), comme on l'a fait dans les conjugaisons françaises (déjà bien compliquées par elles-mêmes en dehors de la conception, spécifique à MediaWiki, des modèles).

Cela ne me semble pas insurmontable de faire ce choix, surtout si les pages de docs des modèles sont liées entre elles pour aider à la classification et la recherche des exceptions, et avec une convention de nommage à peu près homogène. verdy_p (d) 11 août 2009 à 18:52 (UTC)

Modèle:article langue --> Modèle:infobox langue

Je pense avoir montré que ton travail sur les modèles de langues était utile (même si ce modèle n'est pas stabilisé, et pourrait même être supprimé). J'ai rappelé ceci sur la Wikidémie. --Szyx 24 février 2009 à 21:04 (UTC)

Fonts de police peu conventionnelle

Bonjour, suite à une discussion sur la Wikidémie, Darkdadaah (d · c · b) m'a redirigé vers toi. Est ce que tu pourrais jeter un oeil à la discussion ? Pamputt ^[Discuter] 20 mars 2009 à 21:16 (UTC)