Discussion utilisateur:Verdy p/archive3

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)

---

Modèle:fr-conj-3-uire

Tu es sûr pour la double conjugaison ? (...)

Fait. La suite de cette discussion se passera sur Discussion modèle:fr-conj-3-uire où je l'ai copiée. verdy_p (d) 11 août 2009 à 19:02 (UTC)

C'est bien. --Szyx (d) 11 août 2009 à 19:26 (UTC)

{{cf}}

Salut. Tu as modifié {{cf}} [1], et ce n’est pas mal. Mais à ma connaissance, l’ancien code marchait aussi bien. Quel était ton problème ? — TAKASUGI Shinji (d) 11 août 2009 à 16:05 (UTC)

Je l'ai indiqué dans le commentaire, certains sauts de lignes non cachés par le modèle ne sont pas toujours éliminés (après l'expansion), j'ai eu le cas dans une page contenant des listes ou des tableaux et où ces sauts provoquaient une rupture de paragraphe au milieu de l'expansion du modèle.

Ceci dit, je cherchais surtout autre chose : au départ comment passer un suffixe de nature grammaticale pour les ancres cibles de liens: peut-on le passer simplement via le même paramètre 'lang=' ? Je pense que oui, puisque ces suffixes ne sont pas utilisables sans les préfixer par le code langue.

D'autre part le code est plus lisible ainsi, et plus facile à modifier si on doit rajouter des paramètres sans se tromper sur l'imbrication des '#if' (et sans oublier non plus le ' ' qui manquait dans le dernier !). verdy_p 11 août 2009 à 16:11 (UTC)

> certains sauts de lignes non cachés par le modèle ne sont pas toujours éliminés

C’est généralement le cas, mais as-tu des problèmes spécifiquement avec {{cf}} ? Je te le demande parce que j’ai écrit ce modèle avec prudence pour éviter l’illisible <!-- -->. {{#if:}} élimine toutes les espaces au début et à la fin du résultat,

Non justement, pas toujours ! En fait ils sont seulement compactés, mais un saut de ligne est gardé pendant une partie de l'expansion, et n'est pas toujours éliminé ensuite). verdy_p 11 août 2009 à 17:25 (UTC)

et je n’ai utilisé aucune espace entre le }} fermant et le {{ ouvrant. Si tu n’avais pas de problème avec l’ancien code, je voudrais annuler ta modification. — TAKASUGI Shinji (d) 11 août 2009 à 16:58 (UTC)

Je pense que ma façon d'écrire est plus lisible, et évite aussi certains blancs indésirables (notamment car c'est un domaine où les versions de MediaWiki sont assez instables, particulièrement sur le filtrage des sauts de lignes ou la prise en compte ou non des blancs dans les expressions conditionnelles, comme cela arrive encore). Un <!-- --> n'est pas illisible en soit, surtout si on l'utilise comme ici de façon régulière. Les autres blancs en début ou fin de paramètres peuvent avoir (et ont eu de façon instable entre les versions) des effets indésirables). D'une façon générale, j'évite les blancs non indispensables, et ici il s'agit surtout d'unifier l'écriture des lignes du modèle (où il est plus facile d'ajouter des paramètres si nécessaire et de bien voir ce qui les unifie entre elles, avec des différences claires entre les lignes centrales et les première et dernière lignes).

Note qu'au passage j'ai aussi corrigé un bogue (sur la sixième ligne où il manquait un   avant le et)

verdy_p 11 août 2009 à 17:21 (UTC)

> Non justement, pas toujours !
C’est toujours le cas. Il semble que tu ne comprennes pas ce que j’ai dit. Tu peux comparer les deux codes suivants :

"{{#if: t | exemple
}}{{#if: t | 1
}}"

"{{#if: t | exemple }}<!--
-->{{#if: t | 2 }}<!--
-->"

Les résultats sont : "exemple1" et "exemple2" . Il n’y a pas d’espace entre les guillemets. Je crois que tu as parlé du code suivant, qui ne marche pas :

"{{#if: t | exemple }}
{{#if: t | 3 }}"

Le résultat est : "exemple 3" . L’espaces entre les deux expressions n’est pas éliminée. — TAKASUGI Shinji (d) 12 août 2009 à 00:04 (UTC)

Toi non plus tu ne me comprends pas. Je te laisses à tes méditations, pour comprendre exactement ce qui se passe, et qui n'est pas le cas que tu cites ici, et aussi pour comprendre que les cas tordus existent réellement qui cassent les modèles (penses tableaux, listes, légendes, et inclusions récursives de modèles), et qui changent d'une version de MediaWiki à l'autre (ne pas oublier que le wiktionnaire est exploité aussi sur plusieurs versions simultanément). J'ai déjà réglé de tels problèmes sur Wikipédia dans des boîtes complexes. verdy_p (d) 12 août 2009 à 00:13 (UTC)

Peux-tu me donner un code qui ne marche pas, s’il te plait ? Les exemples 1 et 2 ci-dessus n’ont pas de problème dans une liste :

• "exemple1"
• "exemple2"

et dans un tableau non plus :

"exemple1"

"exemple2"

L’exemple 3, bien sûr, ne marche pas. — TAKASUGI Shinji (d) 12 août 2009 à 00:42 (UTC)

Paronymes en ...

Bonjour. Je viens de voir que tu as créé les catégories La catégorie Paronymes en français  et La catégorie Paronymes en vietnamien . Des récentes études auprès des wiktionnariens et quelques discussions enflammées ont montré que ce genre de catégorie... ne sert à rien, n'apporte aucun renseignement intéressant, est très gourmande en ressources Wikimedia, ralentit tout le système... bref, est plus un parasite qu'autre chose. Personnellement, je rejoins cette idée et pense qu'il vaudrait mieux les supprimer. Déjà une raison : sur 500 mots vietnamiens, tu en as 490 qui ont des paronymes... Chrisaix 12 août 2009 à 05:52 (UTC)

J'ai créé la catégorie vietnamienne uniquement (la française existait déjà, créée par Urhixidur qui a du faire le même constat que moi) car elle apparaissait en rouge (générée par le modèle {{-paro-}} employé dans la page), et j'ai vu qu'il y a vait d'autres catégories similaires dans d'autres langues. Je ne me suis pas posé la question, et je n'ai pas vu cette discussion. Désolé. verdy_p (d) 12 août 2009 à 08:55 (UTC)

Justement pour le vietnamien, cette catégorie serait éventuellement utile, car il est difficile de taper les accents nécessaires sur un clavier non vietnamien. Ceci dit, on a déjà le modèle {{voir}} en tête de page pour faire les renvois nécessaires sur les orthographes proches (aux diacritiques près), et ça limite effectivement l'intérêt de la catégorie. verdy_p (d) 12 août 2009 à 09:09 (UTC)

Modèle:cs-décl-adj

Bravo ! Superbe travail ! --Diligent 12 août 2009 à 07:18 (UTC)

Surseoir

Pourrais-tu regarder Wiktionnaire:Questions_sur_les_mots#Annexe:Conjugaison_française:surseoir, merci. --Szyx (d) 13 août 2009 à 08:05 (UTC)

Ma question ne porte que sur surseoir. Suite de ma réponse là-bas. --Szyx (d) 13 août 2009 à 17:33 (UTC)

Et je n'aime pas du tout ton « Tu dois probablement habiter dans le sud de la France pour douter », c'est une remarque déplacée, et qui prouve accessoirement que te tu ne suis pas ce que je dis sur le Wiktionnaire. --Szyx (d) 13 août 2009 à 17:39 (UTC)

Excuse-moi mais je ne croyais pas être offensant en faisant cette remarque sybilline, qui ne me semblait pas déplacée mais bien à propos concernant les différences historiques d'emploi de ces verbes. Je ne vois pas ce qu'il y a d'offensant à doûter d'une utilisation qu'on n'a pas l'habitude d'entendre soi-même dans sa région ou son milieu social, sans savoir que d'autres formes sont préférées ailleurs.

Concernant des verbes irréguliers comme ceux-ci qui admettent déjà pas mal de variantes, on peut encore être surpris quand on en voit d'autres et se demander de l'utilité d'en rajouter d'autres, alors qu'elles sont finalement assez naturelles. Si le but du tableau de conjugaison est de montrer une norme, certains peuvent être tentés de les utiliser pour "corriger" systématiquement des formes qu'ils peuvent penser comme fautives. Personnellement je m'abstient de les juger dans de tels cas, je ne peux pas dire ou écrire que certains qui ont plus l'habitude d'autres formes en font un usage fautif. Si j'ai un doûte je peux chercher des références littéraires, mais dans le cas présent on a des références assez nombreuses dans des livres sérieux qui ont présenté une forme ou une autre, et je ne me permet pas encore de déclarer par moi-même que des formes sont obsolètes, ou vieillies quand elles ont été en emploi et mentionnées dans des références d'il y a moins de 200 ans (je ne vais pas parler du vieux français de Rabelais, ou du moyen français de François Ier), c'est-à-dire bel et bien en français moderne, dans des ouvrages qu'on retrouve encore reproduits tels quels actuellement, sans réadaptation, et qui restent tout à fait lisibles dans la langue actuelle.

Donc avant de décréter par moi-même ou en petit comité ici qu'une forme est inutile, je préfère m'en remettre aux grammairiens, et auteurs de dictionnaires (à ce sujet, il n'y a pas que le Larousse ou le Bescherelle, et même pour eux il faut tenir compte des éditions dont le contenu a pu évoluer, puisqu'ils font toujours des choix éditoriaux fondés sur les usages qu'ils ont pu constater dans une période assez récente pour eux, sans que leur décision ne s'impose aux autres auteurs; et je ne me contente pas non plus des seules éditions franco-françaises). Donc pour moi tout ouvrage sérieux qui date de 100 ans ou moins est une preuve d'emploi en français moderne, et non juste un signe, sutout si l'ouvrage ne mentionne pas explicitement que c'est un régionalisme et se veut didactique pour un public large. verdy_p (d) 14 août 2009 à 09:19 (UTC)

<br>

Salut. Maintenant nous n’avons pas besoin d’écrire <br /> : MediaWiki traite <br> correctement. — TAKASUGI Shinji (d) 21 août 2009 à 00:52 (UTC)

C'est une question de bonne habitude, à conserver malgré tout. On fera de plus en plus d'XML et de moins en moins d'HTML4. Avec HTML5 les conditions sont plus strictes, et avec XHTML (qui a encore du mal à décoler) mais surtout la compatibilité avec d'autres schémas de documents, le renforcement des règles XML est presque obligatoire (car il n'est pas dit que MediaWiki restera définitivement en HTML, même s'il y a peu de chance qu'il ne le reconnaisse plus dans les sources). (Des extensions sont en cours de développement qui permettent de mixer du XML dans le HTML généré, on pourra y mettre du HTML au milieu du XML à condition de le baliser correctement ; parmi elles on trouvera des extensions pour SVG ou RDF, des extensions de langage pour formulaires interactifs (client/serveur) ou pour processeurs de traitement conditionnel plus puissants que le moteur de templates actuel). Sans compter aussi que les exports XML de MediaWiki sont bien plus faciles à traiter de façon non ambiguë avec une syntaxe normalisée. verdy_p (d) 21 août 2009 à 02:50 (UTC)

tamazight et zayane

Nous aurions besoin de ton avis sur Wiktionnaire:Wikidémie/septembre 2009#tamazight et zayane. Merci. --Szyx (d) 1 septembre 2009 à 21:39 (UTC)

Langues

Bonjour. Je ne comprends pas pourquoi tu fais tous ces changements dans les langues. Je viens de voir que tu as changé "nahuatl" en "langues nahuatles". Pour quelles raisons ? Ça bouleverse complètement les catégories qui étaient jusqu'alors en place. Chrisaix 10 septembre 2009 à 18:18 (UTC)

Non cela ne bouleverse rien: les catégories sont en migration.

Le problème c'est que le nahuatl est une familel de langue et toutes tes entrées ont oubliée de préciser laquelle.

Il y a des codfes langues pour les langues individuelles (par exemple nci pour le nahuatl classique).

Les migrations de catégories je m'en occupe. Il ne manquera rien.

Toutes les familles de langues ont déjà été faites depuis longtemps, je corrige les dernières qui reste (depuis que l'ISO 639-5 a été finalisé au début de ce mois-ci en version officielle). verdy_p (d) 10 septembre 2009 à 18:21 (UTC)

Et alors ? C'était correct. Il a récemment été décidé officiellement et collectivement une politique sur les langues, et entre autres d'utiliser le nom le plus courant. Nahuatl rentre dans ce cas (cf. l'article de Wikipédia, par exemple). Tes modifications ne sont donc pas conformes à notre politique. Cela n'empêche pas de créer des articles dans chacune des langues qui ont leur propre code ISO-639-3. Il faut donc revenir en arrière. Pourrais-tu en profiter pour répertorier les noms et orthographes les plus courants qu'il va falloir modifier (par exemple, changer occitan provençal en provençal) ? Mais merci de ne plus toucher à aucun des modèles liés aux langues avant d'en avoir discuté auparavant. Sinon, on sera obligé de protéger tous ces modèles. Lmaltier 10 septembre 2009 à 18:39 (UTC)

Non, car le code est incorrect: même si une langue a un nom courant, ce n'est pas le cas ici: il y en a 18 différentes, plus le nahuatl classique (qui concerne je pense la plupart des entrées que tu as mises (vu les sources de 1800 et quelques).

Consulte le site SIL pour plus d'infos. Sur les autres wiktionnaires, le code nah n'a justement pas été utilisé: il est incorrect pour désigner une langue précise.

Notre politique est d'utiliser strictement la norme ISO 639, et de ne pas utiliser pour les mots et traductions les codes de collections de langues (en revanche en admet les macro-langues comme le chinois ou l'arabe).

On a déjà eu ces discussions au sujet du sorabe. Tu pèches par ignorance ici: "le" nahuatl n'est pas une langue en tant que tel aujourd'hui (même si les sources du XIXe le considérait alors encore comme une langue, ce n'est plus le cas aujourd'hui: ces anciens livres parlent du nahuatl classique, distinct du nahuatl central le plus courant aujourd'hui, mais il y en a bien d'autres avec leur vocabulaire propre, et leur orthographe). verdy_p (d) 10 septembre 2009 à 18:44 (UTC)

Depuis longtemps on a un avertissement dans la liste des langues qui mentionne de bien vouloir préciser la langue pour les cas où le code employé désigne une collection et non une langue individuelle ou macro-langue. verdy_p (d) 10 septembre 2009 à 18:46 (UTC)

Tu réponds à côté. Le nom des langues pour lequel on a des articles doit être le nom le plus courant. On a des articles pour le nahuatl et, clairement, le nom le plus courant est bien nahuatl. Cela ne veut pas dire qu'on n'a pas le droit de créer les sections en nahuatl classique, etc. si on en est capable. On a choisi une politique, tout le monde était d'accord, tu dois la respecter. Lmaltier 10 septembre 2009 à 18:53 (UTC)

TU réponds à côté de la plaque : de quelle langue tu veux parler quand tu mentionnes "nahuatl" ? C'est totalement ambigu (le terme seul n'en désigne clairement AUCUNE). L'ISO 639, ou SIL dans son rapport The Ethnologue, ou tous les linguistes sont d'accords à ce sujet. On ne peut pas se passer de la précision.

Avant l'introduction de l'ISO 639-3 (qui a ajouté les codes langues individuels), on n'avait que l'ISO 639-2 qui contenait des collections: dès qu'il fallait pouvoir préciser, on n'avait pas d'autre choix que d'ajouter à chaque fois cette précision à côté du code langue nah.

Hors rien n'indiques dans ce que tu as fait (les articles et traductions que tu as insérées) de quelle langue nahuatle tu parles. Bref toutes tes entrées sont ambigües.

On a eu ce débat sur le sorabe (qui était dans un cas totalement similaire). La seule façon de lever les ambiguïtés a bien été de ne plus utiliser {{wen}} (de la collection), mais {{dsb}} et {{hsb}}. Note aussi que la wikipédia en "nahuatl" a été refusée pour cette raison (pas d'utilisation du code nah), mais on permet la création de nouvelles éditions linguistiques dans les langues individuelles. C'est une politique adoptée bien plus largement pour l'ensemble des projets Wikimedia qui appliquent STRICTEMENT la classification ISO (hormi quelques codes PRIVES qui ont été conservés comme aliases pour les domaines à condition qu'ils ne rentrent pas en conflit avec la codification ISO 639). verdy_p (d) 10 septembre 2009 à 19:13 (UTC)

Alors au lieu de vouloir tout mélanger (et laisser en plus les autres mélanger le tout et d'avoir ensuite à retrouver toutes les références pour classer les mots) il faut s'y prendre assez tôt. Dans l'état des choses le code nah est bien celui de la collection entière, et ne devrait pas être utilisé du tout.

Je ne te parles pas du tout du problème de nom courant: un nom courant doit cependant désigner une langue unique et pas plusieurs... verdy_p (d) 10 septembre 2009 à 19:13 (UTC)

Je reprends un autre exemple: imagine qu'on ait utilisé un code langue désignant toutes les langues d'oïl, et qu'on avait décidé de l'appeler "français" (prce que c'est la langue d'oïl la plus courante); avec ce code il aurait fallu y mélanger le wallon ! C'est exactement ce qu'on a fait avec le code "nah": on ne sait pas de quelle langue on parle, le second problème étant que TOUTES les langues nahuatles ont le mot "nahuatl" dans leur désignation, comme si on avait l'oïl de France et l'oïl de Belgique mélangés dans la même pseudo-langue "oïl" (qu'on aurait rebaptisée avec le nom courant trompeur "français")...

Dans l'état actuel des choses, il est IMPOSSIBLE de savoir de quelle langue nahuatl on parle dans les articles utilisant "nah", sans les rechercher un par un et en reprenant les sources. Le "nahuatl" est bien une collection et pas une macro-langue comme le chinois. verdy_p (d) 10 septembre 2009 à 19:20 (UTC)

Tu n'es pas autorisé à changer tout seul dans ton coin la politique du Wiktionnaire. Si tu ne comprends pas ça, tu ne vas pas tarder à être bloqué. Wikipédia parle bien d'une famille de langues, mais je cite : Le nahuatl appartient à la branche méridionale de la famille uto-aztèque. Il s'agit d'une langue agglutinante. ou encore en anglais : Nahuatl has been spoken in Central Mexico since at least the 7th century AD.[5] It was the language of the Aztecs, who dominated what is now central Mexico during the Late Postclassic period of Mesoamerican chronology.. Je dis donc que c'est le nom le plus adapté, parce qu'il est évident que c'est le plus courant pour caractériser les articles que nous avons, et qu'il ne faut donc pas le changer. Il ne faut pas non plus, évidemment, supprimer les articles, parce qu'ils peuvent être utiles, même s'ils ne sont pas assez précis. Propose une méthode pour améliorer cette situation, mais ne change pas le nom. Lmaltier 10 septembre 2009 à 19:24 (UTC)

Je ne supprime rien du tout (et ne veut rien supprimer). Et d'ailleurs je ne songe pas à reclassifier les éléments existants moi-même.

Les mots seront réaffinés au fur et à mesure, mais on a malgré tout besoin d'avoir un classement plus fin que l'ambigu "nahuatl", et mentionner le fait que c'est bien une familel de langues avec le pluriel... Quand on parle des temps ancien sous sa forme écrite on n'a qu'une seule langue: le nahuatl classique, et pas d'ambiguité, bref autant parler plus précidément du nahuatl classique. Ce qui s'applique justement au début de la définition du nahuatl en tant que langue, mais ne recouvre pas toutes les langues actuelles (qui sont largement créolisées et disséminées dans des isolats géographiques au milieu aujourd'hui d'une marée espagnole, avec des adaptations locales très différentes). Ta référence oublie ce fait attesté par SIL et approuvé par l'ISO.

Bref je ne contreviens pas du tout à la règle: si on ne sait pas de quelle langue on parle, on peut encore utiliser {{nah}} tout en soulignant qu'il reste un doute sur la classification réelle du mot (qui n'est pas forcément adapté à toutes les langues nahuatles (raison de plus pour indiquer le pluriel et non le singulier qui voudrait en faire une langue uniforme, ce qui n'est justement pas le cas, ou ne l'est plus depuis au moins le XIXe siècle). verdy_p (d) 10 septembre 2009 à 19:32 (UTC)

Tu contreviens en tout cas à la règle qui dit qu'il faut utiliser le nom le plus courant pour ce qu'on veut désigner. Encore une fois, reviens en arrière. Lmaltier 10 septembre 2009 à 19:39 (UTC)

Mais il faudrait des avertissements un peu partout... dans les catégories, et donner une aide pour une classification meilleure. Mais admet tout de même que c'est bien une famille de langues (28 et non 18 comme je l'ai indiqué par erreur plus haut, dont la nahuatl classique jusqu'au début du XIXe, qui n'est plus la langue parlée aujourd'hui, mais uniquement une langue d'étude littéraire, qui a servi a fonder le "nahuatl central" moderne). Alors le nom courant "nahuatl" n'est-il pas plutôt pour le "nahuatl central", qui a un code différent {{nhn}} ? Si c'est le cas on a de toute façon un bogue dans tous les artcicles qui voulaient mentionner le nahuatl central (moderne): tous ces codes sont à changer. Je ne vois pas du tout comment on peut dire si nah désigne actuellement dans les articles toute la famille, ou seulement le nahuatl central (dont le nom courant serait donc nahuatl). Sans spécialiste de ces langues, on ne peut pas décider auquel code attribuer ce "nom courant" (abrégé).

D'ailleurs Chrisaix (qui est le seul à avoir réellement cré des entrées en nahuatl) ne connait pas cette langue, il s'est servi d'un vieux dictionnaire du XIXe (qui ne mentionnait pas encore la possibiltié qu'il puisse y avoir plusieurs langues, ou alors il faudrait disposer de la préface si l'auteur d'en explique, mais je n'ai pas ce livre).

Les sources universtaires pour cette langue font la distinction. On ne peut pas se contenter d'une seule source ancienne. verdy_p (d) 10 septembre 2009 à 19:47 (UTC)

Effectivement, je ne connais pas cette langue. J'ai trouvé ces mots sur un site qui rassemblait un dictionnaire nahuatl-espagnol datant du XVII^e siècle, un dictionnaire nahuatl-français du XIX^e et un dictionnaire nahuatl-anglais du XIX^e également. Les articles rentrés correspondent au nahuatl que l'on parlait il y a au moins 150 ans, ce n'est pas du tout le "nahuatl moderne". Ne connaissant pas cette langue et ne connaissant personne qui la parle, il sera donc impossible de savoir à quelle langue précise se rapportent les mots. Chrisaix 10 septembre 2009 à 19:55 (UTC)

Non, on ne peut pas dire, sauf en enquêtant sur les sources. Et c'est pour ça qu'en attendant de pouvoir le dire, il ne faut pas changer, qu'il faut conserver le nom imprécis, mais courant, pour désigner les articles qu'on a, en attendant. Encore une fois, reviens en arrière. Lmaltier 10 septembre 2009 à 19:56 (UTC)

Avec ces dates de sources, ce ne peut être QUE le nahuatl classique (le nahuatl central ne s'est unifié que tardivement, bien après l'indépendance du Mexique, puisque longtemps seul l'espagnol était reconnu, et il s'est donc développé des tas de créoles ou de différenciations locales quand les amérindiens autochtones ont été isolés, sans production autrement que par une minorité plus éduquée ayant cherché à transcrire "une" langue théorique pour donner naissance plus tard au nahuatl central, qui n'a pas réussi à unifier les différents dialectes qui se sont développés ensuite en langues mutuellement difficilement incompréhensibles).

Alors le nom courant "nahuatl" devrait être celui employé pour le code "nci" et non le code ambigu "nah" (le nahuatl central, qui est la langue moderne la plus courante actuellement n'est pas la langue dont sont issues nos étymologies, la plupart du temps, car il n'y a pratiquement plus d'import depuis les langues nahuatles actuelles; il nous reste seulement ceux du nahuatl classique, que je veux bien qu'on nomme à ce moment là "nahuatl") ! verdy_p (d) 10 septembre 2009 à 19:59 (UTC)

Mais non, il ne faut pas utiliser nahuatl (seul) pour le nahuatl classique, puisque le nom actuel le plus courant est nahuatl classique, nahuatl étant le nom courant pour la famille de langues. Mais je demanderais d'abord leur avis à des spécialistes avant de changer tous les codes. Il ne faut pas se presser. Et, encore une fois, reviens en arrière. Lmaltier 10 septembre 2009 à 20:09 (UTC)

Tu connais de meilleurs spécialistes aussi fiables que SIL et l'ISO 639 ? Tu admets toi-même ici qu'il faudrait mentionner "nahuatl classique" pour les sources qu'on a (et pour nos étymologies) ! Pour les autres cas, c'est ridicule d'appeler cela "nahuatl", ces langues sont trop différentes, et on n'a aucune raison de les mélanger avec un terme faisant penser qu'il s'agit d'une langue unique (ce qui est faux).

Bien sûr on ne peut pas tout changer pour l'instant, mais no peut préparer le terrain pour quand viendront les spécialistes et les sources plus précises: que fera-t-on si elles arrivent et doivent alors continuer à mentionner seulement "nahuatl"? Elle diront que c'est nul puisqu'on mélange tout, et apprécieront qu'on puisse faire les distinctions nécessaires. L'ancienne catégorie "nahuatl" est donc condamnée à se vider progressivement à terme, quand on aura affiné et reclassé les traductions, les grammaires, et le lexique, etc... D'ailleurs ce n'est pas différent des autres sources ambigues : on a fait progressivement le ménage pour "sorabe", un terme qu'on n'mploie plus même s'il est encore courant (l'usage courant n'est pas forcément le meilleur, s'il laisse des ambiguités). Dans un dictionnaire on se doit d'être le plus précis possible.

Je n'ai pas fait ce travail pour rien : je compte bien qu'il y ait une recherche de mots par familles ou sous-familles de langues, avec au minimum la classification de l'ISO 639-5 qui est maintenant officielle et publiée depuis peu (elle ne reprend qu'une partie de la classification SIL, encore instable, c'est à dire la partie compatible avec ISO 639-2 complétée avec des familles incontestées). C'est pour ça que j'ai créé la page Wiktionnaire:ISO 639-5 (en plus de celle qui existait déjà pour ISO 639-2).

De même depuis quelques jours, on a la publication officielle de RFC 5645 et RFC 5646 (qui succèdent à RFC 4645 et RFC 4646, désormais obsolètes dans BCP 47, après plus d'un an d'une version "bis" de ces deux anciennes RFC qui ont été approuvées avec leur nouveau numéros) en intégrant ISO 639-5 dans le registre IANA des sous-labels normalisés de langues (opérationnel lui aussi depuis quelques jours).

Grace à ces normes, il devient possible d'avoir une classification exhaustive des langues (en abandonnant celle de ISO 639-2 qui était partielle et instable puisque définie avec des groupes exclusifs: grâce à ISO 639-5, ISO 639-2 est définitivement stabilisé et ne variera plus). verdy_p (d) 10 septembre 2009 à 20:25 (UTC)

Tu es donc incapable de lire ce que j'écris ? J'ai répété plusieurs fois qu'on pouvait créer des articles en nahuatl classique, etc. Et on utilise les noms les plus courants, il y a de bonnes raisons à ça (sauf impossibilité, bien sûr). 'On n'utilise pas ce qu'on estime être le meilleur nom. (d'ailleurs, chacun peut avoir sa propre opinion sur le meilleur nom). Alors, encore une fois, reviens en arrière. Lmaltier 10 septembre 2009 à 20:35 (UTC)

Encore une fois ce n'est pas mon opinion mais celles des spécialistes. Si tu ne fais pas confiance à SIL et à l'ISO 639 et ses très nombreux contacts scientifiques dans le monde, à qui vas-tu te fier ? Au premier qui viendra ici et se prétendra plus compétent que ces deux organismes qui travaillent depuis longtemps avec tous les vrais spécialistes concernés. Je me fie donc à une source fiable (et vérifiable, elle !) : s'ils ont estimé qu'il fallait mentionner le pluriel pour la famille de langues, ils ont de bonnes raisons, meilleures que les nôtres. C'est la même raison que pour l'indo-européen qui n'est pas une langue non plus : si on l'emploie il faut soit le nommer au pluriel, soit le qualifier pour le préciser (d'où le terme ajouté "indo-européen commun" pour cette langue hypothétique, totalement construite, mais qui n'a pas encore de code langue propre pour désigner clairement la convention). Le cadre de BCP 47 est clair (et stable en plus !) sur la façon de codifier les langues. Pour les noms à donner à ces codes ce sont les normes ISO 639 qui servent de référence. On peut effectivement adapter ces noms orthographiquement, ou vouloir choisir un autre terme, ou corriger des fautes d'accord ou anglicismes encore présents dans ces normes (pas toujours très bien traduites en français, l'anglais seul étant souvent plus correct, car des termes attestés en français et plus courants ont été omis de façon inexpliquée : c'est ce que corrige de son côté le référentiel CLDR sans contrevenir aux principes des normes ISO 639, ni au principe de stabilité ajouté par BCP 47 et très utile pour nous), à condition de ne pas introduire d'ambiguïté supplémentaire, ni tromper nos lecteurs (sinon on nous le reprochera toujours). verdy_p (d) 10 septembre 2009 à 20:48 (UTC)

Tu ne veux pas comprendre qu'on a choisi de toujours utiliser le nom le plus courant. J'ai été obligé de tout annuler, c'est pénible. Lmaltier 10 septembre 2009 à 20:51 (UTC)

Tout ça pour revenir à un nom qui ne signifie rien, et ne règle rien, puisqu'il ne démontre pas le problème. "La" langue nahuatle est une utopie même s'il y a une terminologies commune (avec des différences notables sur leurs évolutions phonétiques et orthographiques comme sur les emplois, puisque les différentes langues nahuatles actuelles sont largement créolisées et n'ont plus rien à voir avec "le" nahuatl classique). Je retiens que (pratiquement) tous les mots qui ont été importés actuellement sont du nahuatl classique, et que toi-même tu as admis qu'ils devraient être classés comme nahuatl classique avec le bon code, et pas comme "nahuatl" qui est la famille à laquelle elle appartient. D'ailleurs aucune des langues nahuatles actuelles ne s'appelle "nahuatl", puisqu'une précision est toujours ajoutée (ou même un autre terme utilisé comme "mexicano" lui-même qualifié...).

Bref, avec ton revert on n'est pas près d'arranger les choses et on continuera à tout mélanger, alors que justement du tri était nécessaire (et tant pis si dans le cadre du vieux codage ISO 639-1 on y trouvait pèle-mêle des langues et familles de langues, car on a effectivement commencé à faire le tri partout ailleurs avec les codes plus précis (et je ne vois pas pourquoi on ne le ferait pas pour les langues nahuatles). Quand le nom "courant" ne signifie rien d'autre que de perpétuer une ancienne confusion issue d'une ancienen claissification très imprécise, je ne vois pas ce qu'il apporte. Ce nom a beau être "courant" il reste ambigu, et comme tel on devrait l'indiquer plus clairement (car "le" nahuatl n'a rien d'une macrolangue, contrairement au chinois ou l'arabe, ce qui est confirmé par sa classification moderne aussi bien dans ISO 639-3 que ISO 639-5, BCP 47, et les normes bibliographiques de type INMARC à la BnF ou à la National Library des Etats-Unis, et sur le site officiel de la Commission des langues nationales du Mexique, qui en mentionne encore d'autres pas encore toutes codifiées, et qui pourtant ont reçu des statuts officiels dans la constitution et la législation mexicaine qui les reconnait comme langues). verdy_p (d) 25 octobre 2009 à 07:08 (UTC)

Familles de langues

Pourquoi créer tous ces modèles pour les familles de langues ? On a l'habitude de ne créer des modèles que quand c'est utile. Et là, non seulement c'est inutile, mais c'est nuisible, puisque leur usage est fortement déconseillé. Je te le répète, n'interviens plus sur les modèles de langues avant d'en avoir discuté. Tout ce que tu fais dessus sans en avoir discuté sera probablement défait un jour ou l'autre, alors ça ne sert à rien. Lmaltier 11 septembre 2009 à 05:16 (UTC)

C'est du contenu destiné à la classification, et ça fait partie d'une page en cours de construction puis va servir à classer les langues très nombreuses pour les trouver. Je ne vois pas en quoi c'est nuisible, puisqu'on a eu justement des débats sur les langues pas assez détailées (c'est bien pour ça qu'elles sont nommées au pluriel pour éviter les confusions).

Vu le nombre de langues qu'on a, c'est utile de les classer. Le wiktionnaire anglais a lui aussi décidé de les classer, et de créer les catégories correspondantes.

Et à cˆté de ça, on a aussi du contenu à classer par famille de langues, qui ne sera pas nécesssairement des mots (de nombreux exemples aussi dans le witionnaire en anglais).

Je ne vois pas ce qui te gène quand à côté des millliers d'articles sont créés tous les jours presque sans contrôle en important des tas de termes de divers lexiques (certains le font par des robots avec des centaines d'entrées par heure, on ne leur dit rien, même si ce ne sont que de très faibles ébauches), et certains mpots importés sont mal classés. Il est ensuite difficile de les reclasser car on ne sait pas toujours comment redistribuer les contenus si des erreurs de classifications ont été faites. Certains peuvent aussi hésiter sur les codes à utiliser, et on doit les aider.

Note : cela ne fait pas énormément de codes, en tout dans l'ISO 639-5 il y a 55 familles (il ne s'agit pas de reprendre toute la classification SIL, seulement celle de l'ISO 639-5) qui est simplifiée et ne concerne que les classifications les plus stables alors que les classifications SIL ou Linguist.org sont encore en chantier (ce qui bloque encore l'ISO 639-4 qu'on n'a pas à faire pour l'instant); parmi ces familles, une vingtaine existaient déjà dans ISO 639-1 et -2, et on les avait déjà toutes (et parmi les autres, on en avait déjà quelques unes). verdy_p (d) 11 septembre 2009 à 17:45 (UTC)

{{reli}}

Bonjour. Je viens de lire ton commentaire sur le paramètre 1 qui devrait être obligatoire. Je t'approuve totalement et je pense même que ce devrait être général pour tous les modèles de ce genre. Il suffit de voir les pages liées à ces modèles pour s'en rendre compte. Si tu veux le proposer en wikidémie, je te soutiendrai sans aucun problème. Chrisaix 13 septembre 2009 à 17:30 (UTC)

En effet cela éviterait de classer dans les thématiques françaises des tas de termes qui n'ont rien à y faire.

Je pensais mettre un test dans le modèle pour détecter dans une catégorie de maintenance les articles à corriger oubliant ce paramètre, mais avant de le faire (cela aurait un impact sur le serveur qui va devoir réanalyser des milliers d'articles utilisant le modèle), il n'est pas inuitile de poser la question.

Ensuite, on pourrait reprendre cette catégorie, l'exporter dans une liste à relire, pour ensuite soumettre les corrections, via cette liste relue pour les termes qui sont effectivement français, à un robot (qui videra progressivement cette catégorie de maintenance). Il me semble avoir déjà vu qu'une telle catégorie existait déjà pour un certain nombre de modèles du même genre.

Mais un robot (un peu plus compliqué à écrire, car il doit gérer et mémoriser une valeur dans un contexte bien plus long) pourrait aussi faire le travail automatiquement en détectant la section de langue (dans l'article) où le modèle est employé sans paramètre. Ceci dit, une telle détection serait nécessaire pour éviter de mettre fr dans deux sections de langues distinctes pour le même mot employant ce modèle dans chaque langue du même article.

En attendant rien n'interdit de mettre un test dans le modèle pour autocatégoriser en maintenance (tout en gardant pour l'instant le paramètre comme encore optionnel). verdy_p (d) 13 septembre 2009 à 17:36 (UTC)

Si on modifie le modèle pour que le paramètre devienne obligatoire, on peut faire en sorte que les articles contenant le modèle sans langue soient répertoriés dans une catégorie Catégorie:Lexique sans langue de la religion, après quoi il sera possible de faire le tri à la main. Ce serait plus long mais, à mon avis, nécessaire. Malheureusement, il y a peut-être une centaine de modèles (voire plus) qui présentent le même problème... Chrisaix 13 septembre 2009 à 17:52 (UTC)

Faut-il vraiment des centaines de catégories de maintenance (une par modèle terminologique) ? Une seule pour tous les modèles de terminologie (qui autocatégorisent dans "Lexique en <langue> de <xyz>") devrait suffire (par exemple Catégorie:Lexique sans langue indiquée), et ce serait déjà pas mal:

Il n'est alors pas inutile de lister dans la page de cette catégorie les noms des modèles concernés (on peut lister automatiquement les pages de l'espace modèle qui utilisent le modèle {{term}}, mais tous ne font pas de la catégorisation automatique, seulement certains pour lesquels il a été jugé utile de créer des catégories).

Bref il serait utile de d'abord obtenir une liste des modèles utilisant {{term}} (ou indirectement via son synonyme), pour ensuite voir s'ils contiennent un test du paramètre "nocat=" standard pour ce genre de catégorisation, ce qui affinera la liste. Ensuite dans ces modèles, on pourra ajouter un test d'absence du paramètre 1 (test à ne pas faire si nocat=1).

Avant de faire ça sur tous les modèles, on pourrait commencer par un des modèles terminologiques pas trop utilisés (il y en a peut-être des moins courants que celui pour la religion qui a de nombreux termes associés, mais on peut très bien tester ça déjà sur celui-là, et voir ce que ça donne avant de faire tous les autres). verdy_p (d) 13 septembre 2009 à 17:56 (UTC)

Ce listage a déjà été fait, notamment pour déterminer la liste des catégories qui renvoient à une liste. Les mots restants dans le modèle {{term}} appartiennent soit à un domaine que l'on n'a pas voulu catégoriser, soit à un domaine qu'on a oublié. Mais ce n'est pas le plus important. On peut très bien commencer par la religion. Ce n'est pas la catégorie la plus remplie ! Néanmoins, tu m'as donné une idée. On pourrait peut-être remplacer cette ribambelle de modèles par un seul, qu'on appellerait par exemple {{C}} (très simple) qui accepterait deux paramètres : l'un pour le lexique, l'autre pour la langue, sous la forme {{C|reli|fr}}, et qui catégoriserait automatiquement en [[:Catégorie:Lexique en <langue> <lexique>]], où langue="français" et lexique="de la religion" (pour séparer les masculins des féminins et des pluriels). Qu'en penses-tu (c'est peut-être ce que tu proposais d'ailleurs) ? Chrisaix 13 septembre 2009 à 18:18 (UTC)

Non je ne proposais pas ça, et ta solution ne résout rien puisque il lui manquerait encore le nom de la catégorie cible. Il me semble que cela doit être fait directement dans chaque modèle terminologique: dedans il n'est pas nécessaire de mentionner "reli", mais on doit transmettre le paramètre de langue à tester et le nom de la catégorie cible, et on doit tenir compte de nocat.

Je ne vois pas l'intérêt de créer un sous-modèle pour ça: on peut passer ces informations directement au modèle {{term}} qui fera ce travail, sans passer par un autre modèle intermédiaire, ou faire tous les tests (test du paramètre nocat, et test de présence du paramètre 1 de langue) dans le modèle terminologique lui-même si on ne touche pas à {{term}}.

Bref je ne propose pas de changement de la syntaxe dans les articles, seulement d'ajouter le code langue (comme c'est déjà demandé et fait dans de nombreux endroits, donc garder {{reli|fr}} et très rarement {{reli|fr|nocat=1}} présent de temps en temps pour désambiguer les listes de traductions, et ne pas y demander {{C|reli|fr]}} qui sera une pollution nuisible et lourde). verdy_p (d) 13 septembre 2009 à 18:24 (UTC)

1°) Concernant la catégorie cible, elle peut être incluse dans le modèle grâce aux Switch (reli=de la religion). 2°) Le modèle {{term}} peut difficilement servir pour catégoriser les mots parce qu'il est destiné à ne contenir justement que les catégories que l'on ne veut pas créer, les autres possédant leur propre modèle. 3°) Écrire {{reli|fr|nocat=1}} ne veut rien dire. Soit c'est "fr", soit c'est "nocat", mais pas les deux. Mais, bon, ce n'est pas important. Déjà, pour transmettre le paramètre de langue correct, si j'avais à programmer ça (mais je ne connais pas le python malheureusement), je ferais une recherche caractère par caractère jusqu'à tomber sur la séquence de six caractères "== {{=". Le code de langue est écrit après, entre les deux =. Je récupèrerais ce code et vérifierais ce qui est marqué après "{{reli". Soit c'est un "|" et on ne touche pas, soit c'est "}}" et on remplace par "|<code langue>}}". Une fois que c'est fait, on continue dans l'article pour voir s'il y a une nouvelle section de langue, et on recommence jusqu'à la fin de l'article. De cette façon, ce serait inutile de lister les mots (sauf à créer la liste de ceux qui ont été modifiés), il suffirait de lister ceux qui contiennent le modèle {{reli}} (il y en a 1422). Est-ce que j'ai bien compris ? Chrisaix 13 septembre 2009 à 18:52 (UTC)

Pour le 3°) tu as raison, si nocat=1, le paramètre de langue n'est pas utile puisque justement avec nocat=1 on n'aura pas à le tester. Mais ce n'est pas important pour ce qui nous concerne.

Mais pourquoi faire un switch? Un modèle comme reli contient seulement une section includeonly qui déclenche la catégorisation. On doit juste y mettre dans cette section includonly le test if pour nocat, et à l'intérieur faire le test du paramètre 1 pour y mettre la catégorie cible. Passer par un modèle intermédiaire ne sert à rien et alourdit la charge serveur (il faut comprendre comment fonctionne le cache des modèles: il n'est pas utilisé pour les appels de modèles qui ont des paramètres, et donc chaque invocation va devoir lire et relire le code du modèle appelé, donc provoquer des accès supplémentaires à la base de donnée où les codes des modèles sont stockés: minimiser le nombre de transclusion et de passages de paramètres est donc très utile). Cela ne se passera pas avec des if intégrés dans des modèles comme {{reli}}. C'est bien pour ça que soit on met le test de catégorie dans le modèle terminologique comme {{reli}}, soit on passe le nom de la catégorie au modèle {{term}} qui fera le test des paramètres nocat et du paramètre de langue avant d'insérer la catégorie indiquée, s'il y en a une; si {{term}} ne reçoit pas de nom de catégorie cible, il ne catégorisera pas du tout (donc inutile aussi de tester nocat ou le paramètre de langue).

Voilà ce que ça donnerait dans le modèle {{reli}} :

{{term|[[religion|Religion]] {{{rel|}}}|nocat={{{nocat|}}}|lang={{{2|}}}|cat.suff=de la religion<!-- {{{rel|}}}-->}}<noinclude> ...doc/méta... </noinclude>

et dans le modèle {{term}} (qui autocatégorise de façon conditionnelle seulement) :

''(<span class="texte">{{UCFIRST:{{{1}}}}}</span>)''<includeonly>{{#if:{{{nocat|}}}||{{#if:{{{cat.suff|}}}|{{#if: {{{lang|}}}|[[Catégorie:Lexique en {{{{{lang|}}}}} {{{cat.suff|}}}]]|[[Catégorie:Terme sans indication de langue]]}}}}}}</includeonly><noinclude> ...doc/méta... </noinclude>

Ceci dit, je préfèrerais qu'on passe le nom de la catégorie cible en entier (il y a des exceptions aux noms de catégories) dans {{reli}} :

{{term|[[religion|Religion]] {{{rel|}}}|nocat={{{nocat|}}}|cat.préf=Lexique en|lang={{{2|}}}|cat.suff=de la religion<!-- {{{rel|}}}-->}}<noinclude> ...doc/méta... </noinclude>

et dans le modèle {{term}} :

''(<span class="texte">{{UCFIRST:{{{1}}}}}</span>)''<includeonly>{{#if:{{{nocat|}}}||{{#if:{{{cat.préf|}}}{{{cat.suff|}}}|{{#if: {{{lang|}}}|[[Catégorie:{{cat.préf|}} {{{{{lang|}}}}} {{{cat.suff|}}}]]|[[Catégorie:Terme sans indication de langue]]}}}}}}</includeonly><noinclude> ...doc/méta.. .</noinclude>

Bref, aucun changement immédiatement nécessaire dans l'utilisation actuelle des modèles {{term}} et {{reli}}, on peut faire une migration des différents modèles terminologiques un par un. verdy_p (d) 13 septembre 2009 à 19:32 (UTC)

OK, pour les transclusions, je pense avoir compris. Merci pour tes explications. Pour le reste par contre, j'ai du mal à te suivre. Mais, si j'ai bien compris, il vaut mieux que le test se fasse uniquement sur le modèle {{reli}} et pas sur le modèle {{term}} qui a, je te l'ai marqué au-dessus, une autre fonction. Chrisaix 13 septembre 2009 à 19:48 (UTC)

Je ne pense pas que ce modèle {{term}} ait une fonction différente (on peut y faire le test une fois comme ci-dessus, ce qui simplifie tous les autres modèles terminologiques), puisqu'il sert déjà à afficher une terminologie (à moins qu'on veuille aussi des catégorisations terminologiques non affichées avec {{term}}.

Que penses-tu alors de cette version de {{reli}} qui fait tout lui-même (au moins dans un premier temps) ?:

{{term|[[religion|Religion]] {{{rel|}}}}}<includeonly>{{#if:{{{nocat|}}}||{{#if:{{{1|}}}|[[Catégorie:Lexique en {{{{{1|}}}}} de la religion]]|[[Catégorie:Terme sans indication de langue]]}}}}</includeonly><noinclude>{{aide}}</noinclude>

verdy_p (d) 13 septembre 2009 à 19:54 (UTC)

Tu peux voir l'effet du code sur l'article personne où {{reli}} ne passe pas de langue. Même chose dans l'article du mot grec άγγελος où la valeur par défaut (fr) de la langue était nuisible. Pour l'instant je n'ai pas créé la catégorie de maintenance (qui s'affiche en rouge en bas d'article : si on la crée elle contiendra __HIDDENCAT__ comme les autres catégories de maintenance). verdy_p (d) 13 septembre 2009 à 20:00 (UTC)

La waiting list de MediaWiki a tourné : la catégorie a rempli les 1500 environs utilisations sans code langue adéquat.

On y voit par exemple : Ceres (un terme uniquement en latin, qui était classé avant parmi les termes de religion français).

En conséquence, tous ces termes (la plupart français) ont été retirés de la Catégorie:Lexique en français de la religion, et placés dans Catégorie:Terme sans indication de langue (sauf une grosse centaine, ceux qui mentionnaient eux-même la catégorie explicitement en bas d'article : ils sont classés alors dans les deux catégories), en attendant qu'on leur restitue un code langue. verdy_p (d) 13 septembre 2009 à 20:37 (UTC)

J'ai peur que le nom choisi pour la catégorie Catégorie:Terme sans indication de langue ne soit trop général. Tu ne préfèrerais pas changer en Catégorie:Lexique sans langue de la religion ? Je pense que ce serait plus explicite et ça permettrait de la séparer des catégories suivantes qui seront traitées (avec le même principe). Merci pour le travail que tu fais. Chrisaix 13 septembre 2009 à 21:22 (UTC)

La catégorie générale (que j'ai en fait normalisée en Catégorie:Wiktionnaire:Terminologie sans langue précisée avec le préfixe "Wikitionnaire:" pour nos catégories de maintenance, et le suffixe "sans langue précisée" commun à d'autres catégories similaires que cette catégorie va contenir) reste utile pour regrouper les autres plus spécialisées si on en a besoin. Je suis en train de les chercher dans les catégories cachées.

Pour l'instant il n'y a que la religion (un millier de termes actuellement). Je vais voir ensuite s'il faut des catégories spécialisées. Mais comme ce sont des catégories destinées à être vidées, je ne pense pas qu'il faille aller trop loin dans les précisions (à moins que ça aide les rédacteurs à situer l'erreur dans l'article). verdy_p (d) 13 septembre 2009 à 21:26 (UTC)

Difficile de répondre. Tes deux arguments sont justes : 1°) cette catégorie est destinée à être vidée, donc inutile d'en faire une pour chaque cas, MAIS, 2°) tout mettre ensemble ne va certainement pas aider pour savoir où est l'erreur. En général, quand deux arguments contradictoires coexistent, il faut alors en chercher un troisième qui serait les deux à la fois sans être ni l'un ni l'autre. Donc, je te propose une autre solution : on ne garde qu'une seule catégorie, mais on rajoute comme clé de tri dans le modèle au niveau de la catégorie "Terminologie sans indication de langue" le nom de la catégorie traitée, c'est-à-dire :

{{term|[[religion|Religion]] {{{rel|}}}}}<includeonly>{{#if:{{{nocat|}}}||{{#if:{{{1|}}}|[[Catégorie:Lexique en {{{{{1|}}}}} de la religion]]|[[Catégorie:Wiktionnaire:Terminologie sans indication de langue|religion]]}}}}</includeonly><noinclude>{{aide}}</noinclude>

Ce sera au moins une indication de là où il faut chercher. Qu'en penses-tu ? Chrisaix 13 septembre 2009 à 21:37 (UTC)

Cela n'aidera pas du tout, et aura pour effet au contraire de présenter la liste dans le désordre le plus complet (classement dans l'ordre historique d'insertion dans la catégorie, au sein de grands groupes où il sera impossible de naviguer facilement, même avec un index minimum qui ne présentera que la première lettre du nom de lexique, en favorisant aribtrairement les noms de lexiques commençant par 'a') !

Je suis plutôt partisan, pour celles qu'on va trouver assez peuplées (rencontrées par exemple suite aux imports massifs de lexiques tiers), de les distinguer, mais certaines sont vraiment très peu peuplées. Pas de précipitation.

Déjà on finit ce qu'on a commencé pour la religion, on peut ensuite voir pour les autres. Certaines catégories terminologiques "sans langue indiquée" sont déjà TRES peuplées (notamment celles des niveaux de langue), mais la religion n'est pas si peuplée que ça, si on songe qu'on commence à peine à s'en occuper, et que ces termes seront rapidement vidés pour l'essentiel. verdy_p (d) 13 septembre 2009 à 21:44 (UTC)

Très bien, je suivrai ton conseil. Merci à toi. Chrisaix 13 septembre 2009 à 22:03 (UTC)

Paronymes

Je viens de voir que tu as créé une catégorie pour ce genre de mots. Mais il n'a jamais été question d'en faire une catégorie. Je pense que tu peux l'éliminer, elle ne servira jamais, tout comme "synonymes", "antonymes", "holonymes", "méronymes", "hyponymes" ou "hyperonymes". On s'est dit en conseil de guerre que ce genre de catégorie était totalement inutile. Merci. Chrisaix 13 septembre 2009 à 22:09 (UTC)

Non je n'ai pas créé cette catégorie, enfin si je l'ai fait c'est il y a longtemps avant ces discussions, ou alors seulement en suivant un lien rouge avec un modèle existant qui ajoutait des termes dans cette catégorie. Je n'ai pas d'avis sur la question; il me semble en avoir déjà discuté il y a quelques temps (je ne sais plus où), et vous avoir répondu la même chose. en elle même cette catégorie ne m'intéresse pas (d'ailleurs le concept même de paronyme ce n'est pas moi qui l'ai introduit ici, il me semble bancal et impossible à juger sans un large degré d'incertitude). verdy_p (d) 13 septembre 2009 à 22:16 (UTC)

Donc, aucune raison de la garder. Autrement, je viens de survoler ton travail de ce soir et je trouve que tu as fait vraiment de l'excellent travail. Bravo. Chrisaix 13 septembre 2009 à 22:17 (UTC)

Je viens de vérifier, demande à Urhixidur (création le 14 avril 2009 à 19:35)... verdy_p (d) 13 septembre 2009 à 22:18 (UTC)

Service

Je reviens pour te demander un service. Penses-tu qu'il serait possible de faire la liste des articles ne contenant pas le modèle {{R:...}}, c'est-à-dire sans références à un ouvrage donné, comme {{R:DAF8}} ou {{R:Littré}} ou n'importe quel autre, et qui ne fassent pas partie des flexions ni des caractères ni des conventions internationales ? Il faut aussi prendre en compte le fait qu'il peut y avoir plusieurs sections de langue dont certaines peuvent ne pas avoir de référence, ainsi que le problème des articles contenant à la fois des flexions et des mots non fléchis. Pour ces derniers, je pencherais pour les mettre quand même. Le but est de savoir dans quels articles il serait nécessaire de mettre une référence. Penses-tu que ce soit possible ? Chrisaix 13 septembre 2009 à 23:03 (UTC)

On a des listes définies par inclusion (ajouts depuis une base nulle) de références, pas par exclusions (soustraction depuis l'infini) de références (par "référence" j'entends toute utilisation directe ou indirecte d'une page via un lien ou une transclusion ou une classification dans une catégorie). bref Le premier critère ne peut PAS être "liste des articles ne con tenant pas tel ou tel modèle", d'autant plus que ce critère est imprécis car cela voudrait dire faire autant de recherches qu'on trouve de noms de modèles commençant par "R:", pour finalement les retrancher de l'ensemble des articles. Il faut donc être plus restrictif.

Même chose pour le critère suivant "ne fait pas partie des flexions", ce qui veut dire les articles ne contenant pas certaines séries de modèles comme "Modèle:fr-*-flex", mais en acceptant malgré tout certains... Brrrrr.... Ce critère de sélection primaire fait froid dans le dos !

Les suivants sont aussi flous, et pas sélectifs : "pas des caractères", donc aussi négatif et n'utilisant pas un modèle comme "Modèle:car" ou "Modèle:conv" (l'immense majorité des articles en fait!)...

Bref pour moi il n'y a pas moyen de faire ce genre de requête directement sur la base de données Wiki. Il faut passer par quelqu'un utilisant un dump importé chez lui sur sa machine et disposant de toute la capacité de recherche sur sa machine, pour balayer presques tous les articles (en fait pour lui la méthode sera plus simple en commançant par retirer ceux contenant une référence à un modèle dans l'espace de nom 14 (Modèle:) et commençant par "R:" (cela devrait en éliminer pas mal: au moins tous ceux en français du DAF et du Littré). Ensuite, toujours sans exporter les articvles mais en faisant une requête SQL sur les références, on peut filtrer plus loin les flexions françaises.

A mon avis il faut faire ces filtrages en travaillant langue par langue: le but est de constituer une liste par langue, et c'est le moyen le plus rapide de travailler car on peut extraire facilement la liste complète des mots de chaque langue, et toujours en ne travaillant que sur les références, rechercher plus facilement un seul nom à la fois sur une liste qui décroit au fur et à mesure.

La vérification finale devra de toute façon balayer les articles pour vérifier les cas spéciaux, mais ce doit être la dernière étape.

On ne peut pas faire ça en Python, même avec les Bots existants, mais avec une base MediaWiki installée chez soi sur son serveur: Python est trop lent pour parcourir plein de fois le gros fichier XML directement, alors que les serveurs SQL sont faits pour ça. (Je n'ai pas de telle base personnellement, ça fait longtemps que j'ai arrêté de charger les dumps devenus trop gros pour mes disques et trop longs à charger sur ma bande passante, et souvent avec différents problèmes liés au transfert, qui oblige à les recommencer plusieurs fois, car MediaWiki ne gère pas un outil de téléchargement différentiel avec vérification de segments de taille raisonnable, par exemple un segment tous les 10 mégaoctets, puis des signatures numériques précalculées sur le serveur de téléchargement, puis des signatures sélectives à la demande pour les segments de taille inférieure, pour éviter d'avoir à tout recharger en cas d'erreur). verdy_p (d) 13 septembre 2009 à 23:22 (UTC)

OK, j'ai compris. Il ne me reste plus qu'à télécharger un dump et faire la recherche moi-même. Mais je ne suis pas sûr de le faire. Dommage. Merci quand même pour ta réponse et tes explications. Chrisaix 13 septembre 2009 à 23:34 (UTC)

Tout ça pour dire qu'en général on ne travaille pas comme ça : on regarde les catégories surpeuplées, on tente de les subdiviser, et on laisse le serveur travailler quelques temps pour remplir les catégories qu'on veut). Ensuite on se colle à récupérer les listes d'articles filtrées et on les analyse., pour ensuite trouver les modifications à faire, ou ajouter des catégories de maintenance pertinentes (et limiter ce travail manuel futur. Derrière le travail d'analyse, on laisse les robots constituer des listes pour ce qu'on cherche quand ça nécessite de parser le code. Le robot qui a envie de faire des modifications peut, avant, poster une liste des articles afin que d'autres puissent collaborer au nettoyage manuel (une tâche éprouvante, mais souvent nécessaire), ou bien ajouter des labels de catégories dans les articles qui demandent un contrôle (même chose: on regarde rapidement ensuite la liste des articles dans la catégorie, on élimine ceux qui ne devraient pas y être). Une fois cela fait, il reste une catégorie sur laquelle on peut demander des transformations à un robot (qui va faire le gros du travail de lecture, en faisant le moins d'erreurs possibles par rapport à un humain qui va en laisser souvent et s'y reprendre à plusieurs fois, ou faire d'autres impasses sur des modifs supposées être faites totalement).

Ca doit être possible encore de prendre un dump du Wiktionnaire, car il est très compact si on exclut les pages de discussions (j'y ai renoncé pour Wikipédia), et si on demande uniquement un dump partiel (ne comprenant pas tous les journaux d'historiques ni les diffs entre versions de pages). Mais ma bande passante ne le permet pas en un temps et avec une fiabilité acceptables (ma ligne ADSL est trop pourrie, avec trop de microcoupures intermittentes.) verdy_p (d) 13 septembre 2009 à 23:40 (UTC)

Note bien quand même: on ne fait pas tout avec un robot. Avant il faut "se frotter" manuellement au terrain pour se rendre compte de la diversités des situations. Dans bien des cas, ce travail manuel est ingras (et souvent malcompris par les autres qui se demande pourquoi on fait ça). C'est pour ça qu'il estutile de tenter des expériences dans un espace limité. Bien souvent, on n'y parviendra pas seul, mais il faut que quelqu'un ait tenté d'améliorer les choses pour que d'autres comprennent l'intérêt. Ensuite c'est plus facile si on peut se partager le travail (et c'est alors beaucoup moins ingras : on voit son projet avancer bien plus vite et on obtient des résultats bien plus visibles). Mon gros du travail dans le Wiktionnaire est de la classification même s'il marrive aussi de faire des corrections au vol, histoire de changer un peu. J'utilise très très peu les robots. En revanche je prépare le terrain pour eux (et si dans certains cas, aucun ne passe, de temps en temps je vais continuer la tâche assidue, et réduire le travail qui reste à faire sur une durée plus longue). verdy_p (d) 14 septembre 2009 à 00:00 (UTC)

{{fr-rég}}

Bonjour. Les changements que tu as opérés sur ce modèle posent un problème d'affichage, apparemment dû à la présence en fin de ligne des "|" (→ voir shah). Il faudrait corriger ce que tu as fait. Chrisaix 14 septembre 2009 à 08:53 (UTC)

Je sais et je m'en étais rendu compte, c'est déjà corrigé (en fait c'est une accolade manquante bizarrement placée dans la version d'avant). verdy_p (d) 14 septembre 2009 à 08:55 (UTC)

Modèles chiffres romains

Bonjour. Je ne comprends pas du tout l'utilité de ces modèles. Il est même plus facile d'écrire les chiffres romains SANS ces modèles. Personnellement, je supprimerais tout ça avec une grande facilité. Si encore ça transposait un nombre en chiffres arabes vers un nombre en chiffres romains, mais ça ne le fait même pas ! Sincèrement, je ne comprends pas. Chrisaix 15 septembre 2009 à 09:06 (UTC)

Il ne s'agit pas de les orthographier mais de les mettre en forme (d'autant que ce n'est pas si évident, certains ne pouvant PAS être écrits avec les polices standards, et de plus adoptant une présentation avec ces polices qui les rends difficilement interprétables, car il y a d'autres chiffres que seulement IVXCLDM...), et de les rendre accessible au lecteur. Ces modèles sont là depuis longtemps, ils étaient seulement incomplets pour être aussi utilisés qu'ils le sont dans Wikipédia (avec un confort pour le lecteur qui n'a pas besoin de les déchiffrer quand ils sont longs). verdy_p (d) 15 septembre 2009 à 09:15 (UTC)

De plus la transposition est un autre problème: ça demande cette fois des modèles particulièrement complexes et lourds (là c'est inutile, on n'a pas de nombres de valeurs inconnue à transcrire, autant mettre la valeur romaine directement dans ces modèles). Ce n'est pas le cas ici, le but est de ne pas avoir à taper une syntaxe HTML compliquée (comme j'en trouve encore à certains endroits où justement il manquait des modèles, et dans d'autres où la manque de formatage n'est pas évident à lire si on a juste la suite des lettres). verdy_p (d) 15 septembre 2009 à 09:17 (UTC)

OK, pour la transposition, on laisse tomber. Mais je ne vois pas en pratique ce qui différencie une écriture classique (XX^e siècle, XX^e siècle) d'une écriture avec ces modèles. Tu pourrais me montrer un exemple où le modèle donne une écriture qu'on ne peut pas avoir simplement ? De plus, de quels autres chiffres tu parles ? Sont-ils utilisés ? Chrisaix 15 septembre 2009 à 09:23 (UTC)

Tu dois être aveugle, c'est pourtant visible dans l'exemple que tu donnes (un est faux, l'autre est à moitié OK). D'autre part, les petites capitales ne sont PAS des lettres en taille réduite ! Enfin les romains ne devraient toujours être "sérifés" pour les distinguer des abréviations ou mots transcrits en capitales ou petites capitales. Au Moyen-Âge, les scribes étaient bien conscients de ça et utilisaient un point médian au début et en fin de nombre avec l'onciale; quand l'onciale a été abandonnée avec les lette simplifiées, les points ont été remplacés par les différences de sérifs dans les textes imprimés.

Enfin tu ne vois pas non plus la différence entre ce que tu as écris (XX^e siècle, XX^e siècle) et ce que fait par exemple Modèle:XXe de façon plus correcte (respect des normes typographiques) et plus simple en fait à écrire en plus. N'oublie pas de passer le curseur au dessus du nombre (les lecteurs Braille peuvent distinguer les classes romaines et s'ils ne le font pas, peuvent rendre les titres affichés pour distinguer les éléments, car en Braille, chiffres et lettres s'écrivent aussi de la même manière avec un dispositif de préfixe et suffixe pour les chiffres similaire au point médian des écritures médiévales; mais sans cette aide, cela deient totalement ambigu). Et bien des gens ont un grand mal à lire les nombres en chiffre romain, les bulles d'aide les y aide. verdy_p (d) 15 septembre 2009 à 09:37 (UTC)

Au niveau de l'écriture, sur mon écran, je ne vois aucune différence, sauf le "e" un petit peu plus haut, c'est tout. Je n'avais pas remarqué pour les bulles d'aide. Sincèrement, il faut le savoir car rien ne l'indique ! Si tu ne me l'avais pas dit, jamais je n'aurais eu l'idée d'aller mettre ma souris dessus. Et je ne pense pas que quelqu'un qui regarde l'article comme ça en ait l'idée également, sauf si ça se passe par hasard. Il faudrait dans ce cas mettre un signe distinctif, quelque chose qui montre qu'on obtient des renseignements en mouse over parce que, tel quel, ça ne sert à rien du tout. Chrisaix 15 septembre 2009 à 09:45 (UTC)

PS. Je ne pense pas que le parallèle avec le braille soit utile. Je le trouve un peu hors sujet. mais bon, ce n'est pas important. Chrisaix 15 septembre 2009 à 09:47 (UTC)

Le signe distinctif n'est pas nécessaire pour les bulles d'aide (la différence de police devrait déjà suffire) : ceux qui buttent sur une lecture ont naturellement tendance à placer le pointeur dessus pour tenter d'en trouver une définition ou un lien. Pour les autres, ou pour la présentation ce n'est pas nécessaire de mettre quoi que ce soit (et les lecteurs y sont déjà habitués sur Wikipédia dans ses diverses langues où on en trouve couramment).

En revanche les distinctions entre mots et nombres sont importantes et l'usage typographique recommandé est bien établi (mais comme ici on utilise des polices sans empattement, cela ne respecte plus la recommandation). Pour preuve, Unicode a produit des caractères de compatibilité pour les chiffres romains, et ceux-ci ont un dessin bien distinctif des lettres usuelles : en principe il faudrait une police différente. Je ne marque pas les polices dans les modèles, j'utilise seulement la classe "romain", comme sur Wikipédia (qui a défini des polices par défaut correctes pour afficher les nombres romains complexes (notamment les nombres archaïques présents dans les textes anciens commentés ou analysés), mais qui permet aux lecteur de les remplacer en cas de besoin. Note: la classe romain fait partie du Monobook standard sur Wikipédia et a été importée aussi dans le Wikitionnaire et Wikibooks... verdy_p (d) 15 septembre 2009 à 09:58 (UTC)

Le braille n'est pas hors sujet: on, parle bien ici d'accessibilité, le Braille ayant les plus fortes contraintes (puisqu'ils n'ont pas la possibilité de transcrire la typographie, il leur faut aussi autre chose: pour les aveugles qui ne lisent que le Braille, les chiffres romains sont carrément inconnus ou incompréhensibles ! La bonne solution c'est alors d'utiliser l'attribut title qui leur sert aussi à "lire" les images (chez nous on voit une bulle d'aide, mais eux ne les voient pas comme des bulles mais comme un assistant disponible à un endroit bien précis de leur tablette de lecture et qui signale leur présence, un endroit qu'il leur suffit de cliquer pour les lire sur la tablette.) Enfin, bon nombre de personnes n'arrivent jamais à lire les romains si on ne leur répète pas la lecture à un endroit conventionnel pour se rappeler les règles. Ces aides sont didactiques. verdy_p (d) 15 septembre 2009 à 10:02 (UTC)

Je ne savais pas tout ça au sujet du braille. J'ai vu qu'il existait des caractères unicode pour les chiffres romains (U2160 à U217F). Je ne sais pas si c'est utilisable en pratique, mais tu dois déjà connaître ça. Chrisaix 15 septembre 2009 à 10:08 (UTC)

En pratique les caractères Unicode pour les petits nombres entre I et XX sont inutiles (sauf peut-être I, V, X, L, C, D si on veut aligner leur présentation avec ceux des grands nombres). En revanche, certains chiffres n'ont pas d'équivalent dans l'alphabet latin (les formes pour 5 000, 10 000, et plus, et diverses autres notations pour les grands nombres, qui nécessitent des polices plus avancées).

On a des recommandations officielles en France, de l'imprimerie nationale (les mêmes qu'on retrouve aussi dans d'autres pays) sur la typographie distinctive recommandée des romains. On est pas obligé d'aller aussi loin (car il faudrait forcer tout le monde à utiliser certaines polices bien précises, ce qui n'est pas possible). Donc pour l'usage courant on continue d'utiliser les lettre latines avec une mise en forme minimale mais suffisante pour respecter la convention chaque fois qu'on le peut. verdy_p (d) 15 septembre 2009 à 10:18 (UTC)

L'autre intérêt c'est celui des citations de textes anciens qu'on peut reproduire plus exactement. Une transcription moderne directe avec l'alphabet latin actuel rend des textes totalement incompréhensibles, par exemple les textes en vieux français. rendre ces textes accessibles (surtout quand ils sont manuscrits) sans les casser trop est une tâche ardue. Si on doit pourrer ce texte de code HTML pour y parvenir, c'est une tâche pénible et longue, produisant de nombreuses erreurs. Alléger l'écriture pour ces transcritions exactes est une nécessité (on a du vieux français, ou du vieil anglais ici aussi)... verdy_p (d) 15 septembre 2009 à 10:24 (UTC)

Modèle:pronoms personnels/fr

Bonjour. Tu as tort dans ce tableau : ni moi ni toi n’est pronoms datifs. Et pourquoi as-tu changer {{lien2|je|code=pronom-pers|gras=1}} en [[je#fr-pronom-pers|je]] ? Avec ce dernier, tu peux voir dans la page de je que le mot je ne s’écrit pas en gras. — TAKASUGI Shinji (d) 15 septembre 2009 à 12:54 (UTC)

Je n'ai pas changé du tout les cas qui sont comme avant, donc ton reverse ne sert à rien ! Et ce sont bien des datifs (comme indiqué avant) : donne-moi = donne à moi (le datif est le COI qui contracte implicitement une préposition (à souvent) avec le pronom tonique. Et les datifs ont aussi des contractions. voir les articles pointés pour les exemples d'emploi. verdy_p (d) 15 septembre 2009 à 13:01 (UTC)

Compare donne-moi qqch, donne-toi qqch, donne-lui qqch, donne-z’y qqch, donne-nous qqch, donne-nous qqch, donne-leur qqch : seule la personne change, pas le cas. Tous ces pronoms répondent à la question À qui ou quoi ?, parfois aussi De qui ou quoi ?.

En fait les mots nominatif, accusatif et datif dans le tableau sont un peu impropres en français : on devrait mettre sujet, COD et COI. verdy_p (d) 15 septembre 2009 à 13:04 (UTC)

Et pour répondre à ta remarque sur lien2, je n'ai rien changé du tout : il n'était pas là du tout (mots bruts sans cible explicite du lien, donc vers la tête de page), c'est aussi pour ça que j'ai complété les liens vers la bonne section.

Enfin j'ai commenté correctement les modifs : le tableau est ordonné dans l'ordre d'emploi dans la phrase affirmative (plus facile de voir lequel on emploie), avec les liens précis, complété avec les formes élidées obligatoires, les pronoms personnels oubliés d'usage général (je ne mets pas les démonstratifs, les partitifs, etc. qui contiennent des qualifications/restrictions sur la personne ou la chose désignée). verdy_p (d) 15 septembre 2009 à 13:15 (UTC)

Ta remarque "inanimé" est fausse: en et y peuvent désigner des personnes, ou être impersonnels. La ligne on désigne tout emploi indéfini. Mais si tu remonte ça dans la ligne il parce que c'est un masculin, alors il faudrait remonter aussi on dans la même ligne, puisque on est aussi masculin grammaticalement (et peut aussi être inanimé !). verdy_p (d) 15 septembre 2009 à 13:23 (UTC)

Bref, les cas latins sont mal fichus pour décrire les pronoms français. J'ai toujours lu des références concernant leur distinction en tant que sujet, COD (réfléchi ou non), ou COI ("de" ou "à", les deux hésitant souvent suivant les verbes où ils sont employés). verdy_p (d) 15 septembre 2009 à 13:25 (UTC)

Les cas et les relations grammaticales sont différents. Qu’est-ce que vous savez de leurs définitions ? — TAKASUGI Shinji (d) 17 septembre 2009 à 03:15 (UTC)

Les cas sont utilisés uniquement pour expliquer l'étymologie des termes actuels. Ils ne permettent pas de distinguer les emplois d'une forme ou l'autre. C'est bien pour ça qu'ils sont mal fichus. Si on doit en parler c'est dans l'étymologie de chaque forme. Mais ce modèle étant utilisé dans une liste terminologique de mots français voisins, on se concentre sur le français moderne, pas sur le latin ni l'ancien français. Sinon il faudrait encore parler du supin en français (qui a disparu mais a donné d'autres formes apparentées...). ces listes sont fondées sur l'emploi et non l'étymologie, les cas n'ont plus aucun sens en français et ne déterminent pas l'orthographe, les accords grammaticaux et autres formes fléchies ou élidées des pronoms.

D'ailleurs le latin n'avait pas de pronoms personnels, juste des adjectifs; on conjuguait sans pronom, et ces flexions de verbes ne s'accordaient pas en cas (sauf les participes quand ils sont transitifs, comme en français encore, ou dans les épithètes, la forme passive étant assimilée à l'emploi des adjectifs avec le verbe être : mais en français, même dans ce cas, il n'y a pas d'accord de cas et les accords ne concernent pas vraiment les pronoms personnels mais les possessifs dérivés).

Même le Wikitionnaire ne fait référence que partiellement aux cas dans la page annexe des pronoms en français, uniquement pour montrer les origines, sans parvenir par ce tableau à montrer l'mploi correct d'une forme ou l'autre. verdy_p (d) 17 septembre 2009 à 03:40 (UTC)

Le cas, c’est une forme. L’accord en cas n’est pas nécessaire pour avoir des cas de pronoms. En anglais non plus, il n’y a pas d’accord en cas, mais on distingue le nominatif I et l’objectif me. Lire des thèses linguistiques t’aidera à comprendre la différence entre les cas et les relations grammaticales. — TAKASUGI Shinji (d) 17 septembre 2009 à 03:56 (UTC)

C'est une théorisation, mais ça ne permet toujours pas de distinguer les formes tonales (proclitiques et enclitiques) et atones nécessaires pour choisir quel pronom employer : le cas ne varie pas entre les deux positions clitiques, pourtant le pronom DOIT varier. Par exemple : tu me donnes ou tu me le donnes (emplois proclitiques, à l’indicatif par exemple) deviennent donne-moi ou donne-le-moi (emplois enclitiques, avec trait d'union, à l’impératif par exemple, où ce ne sont pourtant pas des formes toniques). verdy_p (d) 17 septembre 2009 à 04:03 (UTC)

RdAc, etc.

Selon ma source (A glossary of terms in nuclear science and technology), on écrivait RdAc, non pas Rd^Ac. Quelle est ta source pour la deuxième orthographe ? — TAKASUGI Shinji (d) 17 septembre 2009 à 03:15 (UTC)

Le Journal of Physics (copie accessible aux abonnés, je ne les trouve pas sur Google Books), qui lui utilise une notation homogène (ta source de 1953 ne l'est pas et varie sa notation selon les passages...), compatible avec la notation chimique (notamment pour la séparation des isotopes par précédé chimique, jouant sur la différence du taux d'équilibre entre deux réactions chimique inverses l'une de l'autre : la séparation chimique est encore très largement utilisée et met en jeu des molècules, et ions polyatomiques, et la notation de ta source ne permet pas les distinctions faciles; les nouveaux symboles ont été ajoutés bien après les procédés chimiques). D'ailleurs même ta source admet qu'elle utilise une notation simplifiée, pour alléger le texte, puisqu'on n'y traite pas tellement des utilisation chimiques mais pratiquement seulement des réactions de fusion/fission des nucléides, sans tenir compte des composés moléculaires ou ionisés dans lesquels ils sont pourtant très souvent extraits. verdy_p (d) 17 septembre 2009 à 03:27 (UTC)

Note quand même: Rd n'étant le symbole d'aucun élément, ne pose pas de problème de confusion, mais ce n'est pas le cas de bien d'autres. Ta source contient bien des notations de type _XY^Z, là où maintenant on toujours cet exposant, mais on le place à gauche, et où on supprime la plupart du temps l'indice à gauche (redondant avec le symbole de l'élément) pour ne conserver que ^ZY (et non plus ^Z_XY) pour noter les poids atomiques des isotopes et les variantes isomères d'un même isotope (variantes métastables par exemple), tout en laissant l'exposant de droite (en fin d'expression moléculaire) pour indiquer la charge électrique totale des particules et nucléons ou des ions polyatomiques, et la place indicielle de droite (partout) pour les multiplicités de nucléides (dans une molécule ou un ion polyatomique). verdy_p (d) 17 septembre 2009 à 03:47 (UTC)

Si tu es sûr, il faut utiliser {{titre alt}} pour avoir deux orthographes et écrire ta source (nom de l’auteur, nom du libre, an) dans la section de référence. Merci. — TAKASUGI Shinji (d) 17 septembre 2009 à 03:56 (UTC)

La façon avec laquelle tu as renommé UX1 est une erreur. Il te faut lire w:Aide:Comment renommer une page#Erreur courante. — TAKASUGI Shinji (d) 17 septembre 2009 à 10:35 (UTC)

N'est-ce pas toi qui a fait l'erreur de la renommer? Les caractères précomposés indices et exposants doivent être évités absolument (sauf les quelques-uns qui sont dans les pages de code classiques... et encore leur présentation est souvent mauvaise par rapport aux autres chiffres avec qui ils ne s'alignent pas). Ce sont des caractères de compatibilité ajoutés uniquement en référence à d'autres normes, et trop de polices n'en implémente qu'une petite partie et ne savent pas afficher les autres, on obtient des résultats assez désastreux. Mais la plupart des polices ne les définissent pas, et on obtient des carrés à l'affichage. Ce n'est pas utile en HTML, et le W3C dit la même chose: ils ne sont pas faits pour le HTML, uniquement pour la compatibilité avec les codages en texte brut. D'ailleurs ils ne sont même pas codés consécutivement. Bref ils sont à éviter autant que possible, même si on admet quelques-uns qui sont codés comme symboles et pas comme chiffres sur les claviers de base comme le carré, exposant 2, et éventuellement le cube, exposant 3) dans des notations classiques comme m² (avec le symbole) au lieu de m² (avec le chiffre normal). Note comment ils ont des présentations différentes : pas la même taille, pas le même alignement. verdy_p (d) 17 septembre 2009 à 10:42 (UTC)

Non, c’est toi. On ne peut pas copier le contenu d’une page vers une redirection. C’est une règle du GNU. Je ne parle pas du caractère. — TAKASUGI Shinji (d) 17 septembre 2009 à 10:50 (UTC)

Dans le cas présent, le GNU n'a rien à voir. Les auteurs sont tous là et bien liés. C'est une convention juste pratique locale, mais vu ce qu'il y a dans l'historique de l'autre page, ça ne va pas loin, il n'y a que des auteurs qui travaillent en permanence sur les articles des uns et des autres (avec des licences toutes identiques par défaut), et des Bots... Bref tout reste sur la même licence. Note bien qu'il n'a pas été demandé de supprimer la page de redirection (qui d'ailleurs ne serait pas supprimée mais cachée des historiques accessibles), car on peut encore conserver des redirections sur ces caractères au cas où ils seraient copiés d'une autre source (vu qu'on ne les tapera pratiquement jamais directement sans passer par une charmap). Ces caractères ne sont d'ailleurs pas proposés (heureusement) parmi les caractères des boites d'édition. verdy_p (d) 17 septembre 2009 à 10:55 (UTC)

Moralité, merci de parler de toute modification importante sur WT:W afin qu'on ne doive pas annuler des dixaines me modifications. Mglovesfun (disc.) 17 septembre 2009 à 11:16 (UTC)

Il n'y a pas "des dizaines de modifications", ni de modification "importante"... (que des mineures qui ne portent pas sur le contenu lui-même). verdy_p (d) 17 septembre 2009 à 11:20 (UTC)

Tu ne comprends pas comment renommer des pages. Bon, je vais renommer UX₁‎ vers UX1 pour toi. — TAKASUGI Shinji (d) 17 septembre 2009 à 22:48 (UTC)

Si tu peux le faire, OK. Moi je ne le peux pas... verdy_p (d) 17 septembre 2009 à 22:51 (UTC)

{{R}}

Bonjour. J'ai vu que tu avais créé ce modèle. J'ai peur qu'il prête à confusion avec les modèles de référence de livres qui commencent tous avec le R (ex : {{R:DAF8}}). Il aurait peut-être mieux valu trouvé autre chose. À voir. Chrisaix 17 septembre 2009 à 11:55 (UTC)

Il est similaire au modèle {{*}} mais vers une autre section. Je ne suis pas très favorable à un symbole visible dans le texte qui ne "parle pas". J'aurais pu prendre le + mais ça fait trop penser aux listes déroulables avec leur lien [+]...

Le [R] est l'initiale de Références, mais si j'avais marqué [Références] dans le texte, le nom du modèle n'était pas si évident car il serait aussi trompeur avec les autres modèles générant la section ou appelant une référence numérotée (ces derniers modèles sont inutiles pour moi, il suffit d'assigner des id nommés symboliquement aux références numérotés <code><ref id="XYZ">...</ref></code> pour pouvoir créer un lien dessus en réutilisant cette même référence sans y mettre aucun contenu avec <code><ref id="XYZ"/></code>).

Le modèle {{R}} a justement l'avantage de se référer aux références qu'on place avec des modèles comme {{R:DAF8}} justement dans cette même section.

La question que je me suis posé c'est la possibilité de mettre un libellé court dans le [R] visible, pour afficher par exemple ^{[R: DAF8]} dans le texte, le libellé court apparaissant aussi sur la ligne de la référence elle-même sous la même forme (pour permettre l'identification visuelle). L'autre solution est évidemment d'utiliser les balises <code><ref>...</ref></code> dans le texte, mais elles sont souvent assez lourdes... verdy_p (d) 17 septembre 2009 à 12:02 (UTC)

OK, c'est logique. Merci pour ta réponse. Chrisaix 17 septembre 2009 à 12:04 (UTC)

Discutez avant de renommer

Takasugi a raison. Mglovesfun (disc.) 20 septembre 2009 à 10:05 (UTC)

Je l'ai fait... verdy_p (d) 20 septembre 2009 à 10:06 (UTC)

Modification de fr-conj

Salut,

pourquoi n'utilises-tu pas tes pages personnelles pour tester les modèles ; n'est-ce pas plus prudent que d'altérer un modèle aussi répandu que {{fr-conj-1}} ? Si certains modèles sont protégés, c'est aussi pour éviter qu'ils ne soient modifiées à la légère pour ce genre de choses. — Dakdada (discuter) 22 septembre 2009 à 08:21 (UTC)

Justement parce que cela ne marche pas avec les modèles liés. J'ai expliqué ça dans la page de discussion. Ce paramètre n'a pas d'impact là où il est et permet justement de faire ces tests en vraie grandeur. Sinon on doit recopier une batterie de modèles, sans savoir si ça marchera.

Regarde la correction proposée: elle marche effectivement et corrige les gros bogues actuels. verdy_p (d) 22 septembre 2009 à 08:24 (UTC)

Note: ce paramètre ne fait STRICTEMENT RIEN dans toutes les autres pages (il ne touche AUCUNE des pages annexe existantes). Il ne sert QU'AUX TESTS. verdy_p (d) 22 septembre 2009 à 08:25 (UTC)

Et puis tu noteras quand même que la discussion n'avait abouti à aucune solution, le problème restait à corriger et à tester. C'est bien ce que j'ai fait, la discussion étant ouverte.

Le problème sérieux d'affichage vient du fait que quelqu'un (un administrateur) a modifié le codage des liaisons de façon totalement incorrecte dans le modèle bloqué. verdy_p (d) 22 septembre 2009 à 08:27 (UTC)

OK, merci pour les précisions. Évite seulement de modifier les annexes de conjugaison pour les tests, j'imagine que ça ne pose pas de problème de faire ces tests dans tes sous-pages. L'idée est surtout de ne modifier aucune des pages avant que les tests soient finis (et idéalement revus par les autres contributeurs). — Dakdada (discuter) 22 septembre 2009 à 08:33 (UTC)

J'ai encore des corrections à faire dans la version bac à sable

• pour les verbes impersonnels (le gérondif est en trop aussi bien au présent qu'au passé, raison pour laquelle le verbe importer n'a pas utilisé le modèle fr-conj-1 pour ce cas)

  Réflexion faite, le gérondif n'est pas incorrect pour les impersonnels (même pour importer), même ceux au singulier seul (pleuvoir, neiger...) à partir du moment où ils ont un participe présent (en pleuvant, en neigeant, en important... en ayant plu, en ayant neigé, en ayant importé...), le gérondif restant impersonnel lui-même ; il n'y a que les défectifs sans participe présent (apparoir) qui n'ont pas de gérondif. verdy_p (d) 22 septembre 2009 à 09:11 (UTC)

• pour la gestion correcte de la liaison des composées avec eusses/fusses, fussent/fussent, justement quand il n'y a pas de liaison (la syllabisation est différente, et le e muet se prononce en plus avec eusses/fusses en cas de liaison). Ça va demander une séparation liaison/non-liaison.

Cette possibilité de référencer une version bac à sable depuis les modèles normaux est très intéressante pour les tests.

verdy_p (d) 22 septembre 2009 à 08:39 (UTC)

soir en tant que verbe

salut, tu as ajouté soir en tant que verbe. est-ce seoir dont il s'agit ? pour info : la partie verbe est proposée à la suppression.

Il s'agit d'une lecture incorrecte du rapport de 1990 : presque partout il indique que les listes comprennent les dérivés (qui ne sont donc pas tous mentionnés) sauf dans ce cas où il le met dans une liste restreinte. Effacer doc, c'est une erreur. verdy_p (d) 24 septembre 2009 à 04:02 (UTC)

Article traité. verdy_p (d) 24 septembre 2009 à 04:30 (UTC)

merci ! Par ailleurs, j'ai vu que tu as été très actif sur les modèles de langue. Je peux avoir ton avis sur cette discussion dans la wikidémie ? --Diligent 24 septembre 2009 à 11:48 (UTC)

Suppression des modèles

Salut,

Tous les modèles avec le bandeau {{supprimer}} sont sur la page actuelle (WT:PPS) mais s'il y en a sans bandeau qu'on devrait supprimer, propose-les et on verra. Mglovesfun (disc.) 25 septembre 2009 à 11:55 (UTC)

De quels modèles tu parles ? J'ai posté là-bas déjà une demande de revue et de nettoyage sur les anciens modèles de conjugaison française (oubliés dans la page archivée). Sont-ce ceux-la ?

Si tu parles des anciens modèles renommés qui ont eu un bandeau provisoire (le temps de corriger les références) et qui ne sont plus utilisés du tout (et déjà discutés), on peut mettre {{supp}} (avant nommé suppr) dedans une fois le nettoyage terminé et vérifié (demande de suppression rapide, car plus aucune référence: c'est la phase 3, la phase 1 étant la demande, la phase 2 la période où le modèle est obsolète et devrait être remplacé, la phase 3 ne demandant plus rien d'autre).

De plus les erreurs de nommage ne nécessitent pas de discussion, si on est soi-même l'auteur du modèle renommé, et de toutes les utilisations, et du renommage... Ça peut passer par la suppression rapide (sans discussion, mais qui n'exclue pas que l'admin qui l'effectue vérifie les références, au cas où quelquechose aurait été oublié, et sinon qu'il repasse en suppression normale). verdy_p (d) 25 septembre 2009 à 12:04 (UTC)

Au fait non, mais les pages proposées à la suppression, s'il y a des modèles qui méritent une discussion. Mglovesfun (disc.) 25 septembre 2009 à 12:51 (UTC)

y avoir

Bonjour. Fais attention, ce verbe peut être tout à fait personnel lorsque "y" est un adverbe. Exemple : Je connais Tours. J’y ai des amis. Il existe aussi en tant que verbe impersonnel, aussi faut-il, je pense, laisser la conjugaison entière pour ne pas amener de quiproquo.

• Il y a des gens que je connais (impersonnel) = il existe des personnes que je connais.
• Il y a des gens que je connais (personnel) = cette personne a dans cet endroit des gens que je connais aussi.

Plutôt tendancieux, comme verbe, tu ne trouves pas... ? Chrisaix 2 octobre 2009 à 17:57 (UTC)

Non, car il s'agit ici de la conjugaison impersonnelle (pour il y a), où le y n'a pas du tout le sens de locatif. Cette conjugaison impersonnelle est spécifique (de même que son sens), et toujours défective.

Le y dans j'y ai des amis est un complément circonstanciel de lieu, tout à fait normal et cela reste le verbe avoir (avec sa conjugaison personnelle normale et non défective).

Ce verbe n'est pas du tout tendancieux.

Je suis en train de régler le problème des pronoms proclitiques (dans une forme très générale).

Ca fait déjà un bon moment que j'y travaille, avec plein de tests en cours dans des bacs à sable (qui corrigent aussi plein d'autres problèmes liés aux liaisons très mal codées actuellement dans le tableau de conjugaison bloqué).

Seul ce verbe y avoir emploie encore directement ce bac à sable (déjà il corrige divers problèmes, même si le tableau n'affiche pas encore le proclitique). verdy_p (d) 2 octobre 2009 à 18:04 (UTC)

Bon courage alors. Chrisaix 2 octobre 2009 à 18:15 (UTC)

Je sais c'est assez compliqué, mais je progresse bien. Au passage je corrige aussi d'autres problèmes liés aux verbes réfléchis.

Et j'espère aussi aboutir aux cas des formes interrogatives du présent (plus tard), des accords de participes de verbes transitifs avec COD, aux exceptions des quelques verbes intransitifs malgré qu'ils soient réfléchis (se taire) ou se conjongue avec être (aller, laisser suivi d'un infinitif)... C'est bien pour ça que je passe par des modèles bac à sable (que je lie aux autres modèles normaux via une convention de passage de paramètre "bac à sable" pour pouvoir nommer les quelques modèles modifiés mais non utilisés encore par les pages annexes de conjugaison, ce qui évite de tout casser pendant les tests).

verdy_p (d) 2 octobre 2009 à 18:49 (UTC)

Excuse-moi d'intervenir encore, mais la phrase que tu as rajoutée (pour décrire un état, dans cette forme d’inversion du sujet et de l'objet ou attribut de ces verbes impersonnels ou d’état, similaire au mode passif des verbes d’action) est complètement incompréhensible. Je serais même incapable de t'aider à la transformer parce que je n'ai rien compris du tout. Il faut absolument que tu trouves une formulation plus courte, plus simple, plus abordable, plus compréhensible par une personne quelconque... S'il te plaît, trouve autre chose. C'est pire que du chinois ! MERCI. Chrisaix 2 octobre 2009 à 19:32 (UTC)

C'est pour indiquer que les verbes d'action s'utilise au mode actif ou passif, au contraire des verbes d'état et verbes impersonnels. L'emploi de y avoir sert à faire cette inversion du sujet et de l'attribut, dans le cas des verbes d'état, et du sujet impersonnel et de l'objet indirect pour les verbes impersonnels.

Si tu vois comment mieux formuler ça, c'est difficile, je me suis remis à plusieurs reprises (en mre relisant plusieurs fois) pour trouver une formulation pas trop lourde... verdy_p (d) 2 octobre 2009 à 19:39 (UTC)

Tu noteras que la simple définition ne permet de faire un réel synonyme, puisque le replacement de y avoir par un des verbes proposés change complètement la fonction grammaticale des autres éléments de la phrase (notamment du complément d'objet après y avoir qui devient un sujet...) C'est exactement ce que je veux mentionner : ces définitions seules ne suffisent pas car elles font croire à des synonymes, ce qu'elles ne sont pas. C'est pour ça qu'il m'a fallu ajouter les lignes signifie en dessous pour montrer commet avait lieu cette inversion. verdy_p (d) 2 octobre 2009 à 19:43 (UTC)

Ça y est, j'ai bien compris maintenant. Ta remarque est tout à fait judicieuse et je n'y avais jamais pensé. Elle est pourtant totalement juste. Je vais réfléchir à une formulation plus simple et je te la soumettrai dès que j'aurai trouvé. Merci pour tes explications. Chrisaix 2 octobre 2009 à 21:50 (UTC)

Je l'ai déjà changée et expliquée dans les notes plus bas, les exemples montrent que ce changement de fonction grammaticale modifie la personne avec laquelle se conjugue le verbe (ce qui démontre encore une fois que ce ne sont pas des synonymes, juste une explication du sens qu’il faut alors replacer dans son contexte d’utilisation). verdy_p (d) 2 octobre 2009 à 22:13 (UTC)

{{la-décl-adj}}

Bonjour, tu avais fait un superbe travail sur Modèle:cs-décl-adj, on commence à avoir pas mal d'adjectifs latins et avant d'en ajouter d'autres, j'aimerais avoir les modèles adéquats. Pourrais-je te demander de de créer nos modèles sur celui de

• en:Template:la-decl-1&2
• en:Template:la-decl-1&2-ER
• en:Template:la-decl-3rd-1E
• en:Template:la-decl-3rd-2E

Puis-je aussi suggérer une modif du modele anglais : inverser les parametres de

1. nominatif sans diacritique
2. nominatif avec diacritique
3. radical sans diacritique
4. radical avec diacritique

vers :

1. nominatif sans diacritique
2. radical sans diacritique
3. nominatif avec diacritique
4. radical avec diacritique

et mettre 3 et 4 en optionnel (on ne les connait pas toujours)

--Diligent 8 octobre 2009 à 10:02 (UTC)

Les modèles que tu proposes en exemple pour le latin sont assez mal fichus, et surtout ils sont inutilement trop larges (trop de colonnes, d'ailleurs ils ne tiennent même pas dans la largeur de mon l'écran quand on affiche leur propre page) et d'une présentation spécifique pas homogène.

Que penserais-tu de les remettre en forme comme les tableaux qu'on a en français ou en tchèque ?

Il me semble en plus qu'on doit pouvoir aussi trouver des généralisations, et former un modèle de base sur lequel on crée des modèles dérivés, afin qu'ils aient tous la même forme.

J'en ai vu d'autres qui ont le même problème (je pensais refaire par exemple les modèles du grec pour la même raison, par étape successive de transformation, en leur ôtant éventuellement aussi l'article inutile, car pas spécifique, des noms communs et le nom/déterminant passe-partout des adjectifs).

verdy_p (d) 8 octobre 2009 à 16:43 (UTC)

je suis 110% d'accord avec toi. c'est pour cette raison que je ne me suis pas lancé dans l'entreprise d'importer un truc mal fait et pas harmonisé avec nos modèles existants en russe et tchèque (pour ne parler que des langues que je connais). je ne me suis pas (encore) posé la question du grec, mais oui, je comprends sans pouvoir donner de conseils, ce que tu dis. --Diligent 8 octobre 2009 à 16:47 (UTC)

D'autre part, les paramètres avec numéros posent sans arrêt des problèmes de maintenance. Par soucis d'homogénéité, ne devraient être numérotés que les paramètres stables toujours obligatoires. Les autres devraient être nommés.

oui. radical nominatif, comme on a pour le tchèque. En fait, la diacritique latine est une vue de l'esprit, créée par les linguistes pour 1. reconstituer la prononciation initiale et 2. surtout, grace a cela, expliquer l'evolution vers les langues romanes. Elle est indispensable pour les lignes de forme (et souvent renseignée) inutile pour les flexions. => laissons tomber cet aspect du probleme.

Or, dans le cas présent, seul un radical serait obligatoire et ce serait le radical sans diacritique, éventuellement suivi du radical avec diacritique, puisque la plupart du temps, dans les modèles dérivés, soit le nominatif sera déduit, soit on fournira toutes les finales des déclinaisons. Enfin, nous faut-il obligatoirement les deux (avec ou sans diacritiques de longueur) ? La question demande à être posée : sous quel nom crée-t-on les mots latins ? Il me semble que c'est sous la forme sans diacritique (la forme classique, puisque les diacritiques sont une invention ultérieure, ajoutée pour les besoins liturgiques ou pour l'enseignement moderne du latin, et ils n'existaient pas dans le latin antique et du Moyen-Âge, puisque l'alphabet était encore monocaméral).

je repondais au premier paragraphe sans avoir lu celui-ci. 100% d'accord.

Enfin y-a-t-il eu une décision concernant les lettres ajoutées à l'époque moderne (consonne J et voyelle U, au lieu des lettres I et V utilisées aussi bien pour les voyelles que les consonnes ?) Adopte-t-on par défaut uniquement l’orthographe qui distingue ces lettres ? verdy_p (d) 8 octobre 2009 à 17:00 (UTC)

oui → voir {{la-note-ij}} pour le J. pas de vote mais idem pour le U/V qui se trouve dans tous les dictionnaires franco-latins.

Note: il y a déjà des modèles pour les noms et adjectifs latins, que devrait-on en faire ? Par exemple : Modèle:la-tab-3i-1f et les autres de la même catégorie. Peut-on les rebaser sur un même modèle de base (qu'on crée et teste d'abord, pour ensuite qu'ils utilisent les nouveaux, puis qu'on fasse les migrations par soucis d'homogénéité) ? verdy_p (d) 8 octobre 2009 à 17:03 (UTC)

tiens ! je le découvre. la forme est pas bonne (singulier/pluriel, plutot que droite/gauche => singulier en haut, pluriel en dessous > ce qui laisse la place à gauche pour les définitions et les exemples sans trop envahir). Perso, je suis pour un renommage des modèles latins suivant une nomenclature langue-décl/conj-nom/adj-spécificité_compréhensible_au_premier_abord, un peu comme on a pour le tchèque. Une solution (super batarde) est donnée dans amicus (adj.). Pour la forme du modèle latin, je vote, avec quelques adaptations (instrumental inutile) pour celle que tu as développée pour le tchèque (élégante, simple, claire) il y a trop de gras dans les modèles latins actuels.

J'ai vérifié, ces modèles ne servent pratiquement que pour la page annexe de présentation des déclinaisons latines (où ils prennent une grande largeur puisqu’ils n'y a pas de définitions à côté. Et ils sont pratiquement pas utilisés ailleurs (les rares endroits où ils le sont, c’est ultra-moche et ça gène la lecture). Donc ce n'est pas grave de changer et les réadapter à la présentation dans les articles (au besoin, le modèle général peut prévoir un paramètre de réalignement/centrage du tableau, alors que par défaut ce sera cadré à droite... verdy_p (d) 8 octobre 2009 à 21:20 (UTC)

C'est bien ce que je pense ! --Diligent 8 octobre 2009 à 23:20 (UTC)

j'ai découvert que Modèle:la-tab-adj-1 existe. discussion un peu obsolète du coup... --Diligent 21 octobre 2009 à 15:45 (UTC)

code pour le braille

Pourrais-tu me donner un code pour le braille, stp ? -C'est, semble-t-il le code chiffré 570, des systèmes d'écritures- Ne pourrait-on pas le créer comme un code de langue pour permettre de mettre le bandeau Braille en tête de l'article ⠉ par exemple et éviter la redondance Caractère ? -Béotien lambda 9 octobre 2009 à 11:19 (UTC)

Ce n'est pas une langue du tout mais une écriture. On a des modèles séparés pour les écritures (à 4 lettres commençant par une majuscule, tous issus de ISO 15924, par exemple {{Latn}} pour le latin, {{Cyrl}} pour le cyrillique, et déjà {{Brai}} pour le braille). verdy_p (d) 9 octobre 2009 à 11:33 (UTC)

A mon avis la redondance est inutile et ne nécessite pas de remettre un titre "Braille". Cela reste un caractère, la section étymologie est sans doute inutile pour les caractères, on peut la mettre directemetn dans ses définitions, et aucun titre entre les deux.

En revanche, les correspondances entre caractères braille et différents alphabets dépendent de la langue. Bref, s'il faut une section de langue, c'est pour celle-ci, par exemple pour le français directement, où ce caractère a la valeur de la lettre A (ou du chiffre 1 après le caractère braille du préfixe numérique)... verdy_p (d) 9 octobre 2009 à 11:39 (UTC)

Si tu veux un code langue absolument, il faudra préfixer le code Braille par le code de la langue dans lequel il est utilisé, par exemple "fr-Brai". Il ne PEUT PAS exister de code langue pour les écritures seules. verdy_p (d) 9 octobre 2009 à 11:42 (UTC)

Merci pour tes réponses. ---Béotien lambda 9 octobre 2009 à 12:00 (UTC)

Au passage j'ai réajusté la taille de cette écriture dans le modèle, mais il lui manque une liste de polices adaptées. (voir dans {{Brai/type}} et renseigner "polices="). J'ai rensigné aussi "exemple=" avec les 64 premiers caractères du Bloc Unicode U+2800-U+28FF qui représente tous les caractères de la matrice de base 2x3. Cela permet immédiatement de tester les polices Braille. verdy_p (d) 9 octobre 2009 à 12:02 (UTC)

Tu noteras si tu repasses par là que j'ai mis en place les polices par défaut pour l’écriture Braille, j'ai finalement rétabli la taille de 120% pour la lisibilité des gras (qui marquent les mots vedettes dans les citations). Les exemples dans les articles qui employaient déjà le modèle (auparavant uniquement pour mentionner le nom de l'écriture), sont maintenant mis en forme pour cette écriture. Consulte la liste des utilisations du modèle {{Brai}} pour voir ce que ça donne (tu verras qu’ils sont lisibles avec une des 3 polices disponibles mentionnées pour cette écriture, toutes libres mais aucune préinstallée sous Windows, même sous Windows Seven que j'ai déjà en version finale depuis fin août en toutes langues...)

Normalement on devrait aussi indiquer la langue mais il faudrait créer des modèles pour chacune fr-Brai, ja-Brai, el-Brai, ru-Brai). La mise en forme par un modèle d’écriture ne fait que mentionner l’écriture et ne renseigne pas du tout la langue comme le font les modèles de langue (qui peuvent, eux, parfois mentionner l'écriture en plus). verdy_p (d) 9 octobre 2009 à 16:04 (UTC)

Gentilés

Pourquoi remets-tu des régions dans les pays ? Un gros travail a été fait pour alléger la page Annexe:Pays et leurs gentilés en français et la rendre plus claire suite à Discussion Annexe:Pays et leurs gentilés en français et des pages spéciales ont été créées

• Annexe:Départements de France et leurs gentilés en français
• Annexe:États des États-Unis et leurs gentilés en français
• Annexe:Pays et leurs gentilés en français
• Annexe:Provinces dans le monde et leurs gentilés en français
• Annexe:Régions dans le monde et leurs gentilés en français

---Béotien lambda 10 octobre 2009 à 04:52 (UTC)

Parce qu'il y en avait déjà pas mal... De plus certaines régions ont été aussi des pays à part entière. verdy_p (d) 10 octobre 2009 à 05:38 (UTC)

Quant aux pages citées, celles des régions est à peine commencée (lettre A seule).

Je veux bien qu'on en place ailleurs, mais la notice est récente (et je ne l'avais pas vue). Que celui qui a commencé la pages sur les régions continue le travail alors... verdy_p (d) 10 octobre 2009 à 05:43 (UTC)

Je note que ces pages sont en chantier depuis très longtemps (le "gros" travail dont tu parles est tout bonnement inexistant depuis plus de 3 ans !) verdy_p (d) 10 octobre 2009 à 05:46 (UTC)

Note à Lmaltier, qui a détruit les lignes non-relatives aux pays : cette annulation est destructrice d'informations (assimilable selon nos principes à du vandalisme, mais je n'irai pas jusque là : il appartient à Lmaltier de réimporter les lignes supprimées sur la page appropriée, et je lui laisse le temps nécessaire, sinon je rétablirai ces lignes en annulant à nouveau ses modifs), car les régions supprimées n'ont même pas été reportées dans la page mentionnée sur les régions qui ne contient que la lettre A (partiellement, car à peine commencée et inutilisable).

Le minimum, avant la suppression, aurait été de transférer ces régions, ce qui n'a pas été fait. Bref supprimer des lignes sans les transférer, je ne vois pas en quoi la destruction est bénéfique, car la page n'en est pas allégée pour autant, mais les infos suppriémes ne se retrouvent plus nulle part.

Bref, à moins que quelqu'un fasse les pages en question, cela ne sert à rien "d'alléger les pages" qui ne sont pas si lourdes que ça. Si on veut restructurer les listes, c'est à l'initiateur de cette restructuration de faire ce travail si cette lourdeur le gène. Mais ne pas se débarrasser du problème en supprimant le travail des autres. verdy_p (d) 22 octobre 2009 à 05:33 (UTC)

Modèle:étyl

Tu me fais un peu ch**r, t'es modifications à ce modèle veulent dire qu'il y a au moins 50 catégories à supprimer. C'est précisément le genre de chose dont on doit parler avant de le faire, donc blocage de 24 heures parce qu'on t'a déjà prevenu. Merci de parler des grands changements aux modèles avant de le faire, et casser 100 catégories. Mglovesfun (disc.) 17 octobre 2009 à 12:04 (UTC)

Je ne dis pas que t'es modifications sont mauvaises, simplement qu'on aurait du supprimer plus ou moins 100 catégories sans aucune discussions sur la Wikidémie. Je ne veux pas te décourager de modifier les modèles, simplement de ne plus ignorer ce qu'on te dit. Ça fait des semaines qu'on te dit ça. Mglovesfun (disc.) 17 octobre 2009 à 12:35 (UTC)

discussion en cours sur la pdd du modèle au sujet des « sous-langues ». je pense que tu peux etre tres utile... --Diligent 21 octobre 2009 à 14:39 (UTC)

Quelle page? quel modèle ? verdy_p (d) 22 octobre 2009 à 05:36 (UTC)

Pour info à toi, Mglovesfun, qui m'a bloqué en invoquant la réaction d'un utilisateur qui s'est demandé ce qui se passait, ce même utilisateur t'a répondu lui-même que cela ne méritait pas un blocage.

D'ailleurs il m'autorise à copier la réponse qu'il m'a faite personnellement à mon email, et qui défend ma position (j'ôte son nom complet visible dans son email, conformément à sa demande) :

Tu noteras que Mglovesfun m'a bloqué immédiatement pour 24 heures (sans même tenter de me prévenir si problème il y a eu), avec le motif que j'ai modifié plein de choses, ce qui n'est pas le cas ici puisque la seule chose que j'ai faite c'est de emplacer le nom de langue employé comme adjectif au masculin singulier par une référence à ce masculin singulier et non le nom, afin que ne pas générer les liens rouges ou noms incorrects.

Je ne suis pas responsable du choix initial de la convention de nommage des catégories qui était déjà là avant moi. Bref s'il y a eu une incohérence elle était déjà là avant moi.

S'il y a des incohérences de nommage de catégories, c'est justement ce que j'ai tenté de régler en voyant des liens rouges sur des noms de catégories et des doublons de catégories, ce que j'ai justement tenté de régler.

Si on ne peut pas corriger les choses sans se faire bloquer...

Suis-je un vandale pour mériter un tel traitement ?

--

Ce courriel a été envoyé par « Verdy p » à « Diligent » par la fonction « Envoyer un courriel à l’utilisateur » du Wiktionnaire.

Re : Courriel du Wiktionnaire (courriel du 21/10/09 14:53 reçu de « Diligent » )

salut,

oui, j'ai noté et comme tu peux le lire sur sa pdd ou sur la mienne (je ne sais plus) je ne suis pas d'accord avec la méthode. j'ai failli te "réhabiliter" dans la foulée mais j'ai été lâche ou consensuel (au choix).

Martin a tendance a abuser de son pouvoir - j'en suis le spectateur désolé. Ça n'est pas la première fois. Ce que je te conseille, c'est de laisser un message sur la pdd des Admins en disant ce que tu me dis - ça laissera une trace utile le moment venu...

Pour ma part, je trouve ton travail utile, tres utile - ça n'est pas du vandalisme mais de la précipitation ce que tu as fait. errare humanum est...

amitiés,

(prénom supprimé).

ps - prière de ne pas utiliser mon prénom dans les discussions, les moteurs de recherche sont redoutables et je veux dissocier mon identité de mon travail sur le wkt.

Au moins cela va aider à fixer les choses. Et rectifier les allégations de Mglovesfun qui a prétendu que j'ai modifié "pleins de choses" (alors qu'il a gardé la quasi-totalité de mes modifications, et juste supprimé une poignée de caractères, pour régler temporairement un problème qui subsiste encore (et ne concerne finalemant pas des dizaines de catégories comme il n'a annoncé avec précipitation et sans fondement). En attendant, voici la réponse qu'il m'a faite (tardivement une fois le blocage terminé); pendant ce temps là je me suis occupé ailleurs sur d'autres Wikis (Wikipédia, Commons, et sur un gros fichier SVG compliqué en cours de conception (manuelle sans utiliser un verbeux éditeur SVG) pour Commons).

verdy_p (d) 22 octobre 2009 à 05:23 (UTC)

liaison, diacritique double brève souscrit

Toute la (longue) discussion (en plusieurs parties) a été transférée dans la sous-page :

Discussion utilisateur:Verdy p/Codage Unicode de la liaison.

Merci de ne pas la continuer ici. verdy_p (d) 13 novembre 2009 à 03:12 (UTC)

Modèle:cel

Sur le wiktionary le code Modèle:cel renvoie à Celtic ; est-ce que ça te choque de renvoyer ce modèle vers celte plutôt que langues celtiques ?

regarde la catégorisation de cloche pour comprendre pourquoi je pose la question.

merci

--Diligent 10 décembre 2009 à 09:13 (UTC)

Pas question: le code cel est pour une collection de langues (qui comprend le breton, l'irlandais, la galois, ... et le celte, l'ancienne langue qui a son propre code).

verdy_p (d) 12 janvier 2010 à 19:02 (UTC)