Discussion utilisateur:Verdy p/archive1

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)

---

{{clé de tri}} en grec

Bonjour,

Sais-tu si, pour les clés de tri en grec, on doit y laisser le sigma final ou bien lui redonne-t-on sa forme initiale ?

Σπάρτη 25 août 2007 à 18:49 (UTC)

On leur redonne leur forme initiale, pour que cela se groupe avec ayant des lettres supplémentaires. Ceci dit, si tu oublies une forme finale, le modèle l'ignore comme une différence de casse (pris en compte uniquement pour le tri tertiaire).

Le tri est maintenant multiniveau (conforme à Unicode UCA).

Il serait bien de passer un robot charger de vérifier les paramètres de tri et générer les {{clé de tri}} qui vont bien.

Note: il faut tout mettre en minuscules initiales, sans accents ni esprits dans le premier paramètre du modèle: regarde par exemple le mot Adam.

La clé de tri est calculée automatiquement. J'ai réglé les derniers problèmes de stabilité du tri sur les différences de casse car MediaWiki complète la clé fourni avec un identifiant aléatoire ("-UNIQ-" suivi du revision id bogué) pour en faire une clé unique par page indexée!). Verdy p 25 août 2007 à 18:53 (UTC)

• Exemple, pour Αίσωπος :
  • {{clé de tri|αισωποσ}} (la clé de tri composite calculée est "αισωποσ ! !Αίσωπος").
• Exemple, si tu oublies une forme finale :
  • {{clé de tri|αισωπος}} (la clé de tri composite calculée est "αισωποσ !αισωπος !Αίσωπος").
• Exemple, si tu oublies une majuscule :
  • {{clé de tri|Αισωπος}} (la clé de tri composite calculée est "αισωποσ !Αισωπος !Αίσωπος").

Bref tu peux laisser la valeur par défaut et ne rien mettre en paramètre s'il n'y a aucun accent ni esprit dans le titre de l'article. Verdy p 25 août 2007 à 19:04 (UTC)

Correction: maintenant on laisse la casse originale, on ne supprime que les accents et esprits. Et un seul paramètre suffit:

• {{clé de tri|Αισωπος}}

Cas particulier: On doit aussi remplacer le iota souscrit du mot original par un iota minuscule placé après la lettre (car la conversion en majuscules conserve ce iota souscrit); il ne faut pas le supprimer !

Le modèle prend en charge tout le reste. Verdy p 9 octobre 2008 à 21:51 (UTC)

{{pron}}

Salut,

j'ai révoqué ta modification de ce modèle pour plusieurs raisons importantes (voir Discussion modèle:pron). De manière générale, avant de modifier un modèle de cette importance, merci d'en discuter auparavant...

Aussi j'ai bien peur que tu ne créés des catégories de rimes pour rien :( - Dakdada (discuter) 26 août 2007 à 10:15 (UTC)

le premier problème du modèle avant modif est qu'il généère DEUX fois la prononciation API (le paramètre 1): c'est un bogue corrigé par ma première modif.

le second est qu'on êut tout à fait utiliser ce modèle pour générer deux dictionnaires simultanément:

• le dictionnaire des rimes et le dictionnaire de phonétique (classement par le début ou la fin)

Je ne vois pas quel problème j'ai introduit.

Verdy p 26 août 2007 à 17:29 (UTC)

Je persiste : voir re Discussion modèle:pron. Je te déconseille de continuer à créer des catégories jusqu'à ce qu'on se soit entendu. Si on décide que finalement on ne veut pas de ces catégories, il faudra toutes les effacer (à la main °_°). - Dakdada (discuter) 26 août 2007 à 19:18 (UTC)

Tu as parlé du modèle, ok, je ne l'utilise plus (et la poignée d'articles où pron aavait été découpé ont été remis pour afficher la prononciation entière depuis ton revert.

Pour les catégories, rien n'aété décidé ni discuté pour l'instant; Comme toute la série des rimes, ce sont des créations individuelles, à l'état d'ébauches. Je peux bien faire mes ébauches aussi non?surout que pour le reste du travail, un robot pourra faire lesmodifs nécessaires dans les articles.

Sur d'autres wiktionnaires, les dictionnaires de rimes et phonétiques sont activés.

Note: un dictionnaire fonctionne d'abord comme un index et les catégories sont faites pour ça, et fonctionnent très bien pour ce type de recherche, et tous les autres modèles des articles font de la catégorisation automatique pour permettre ce type de recherches croisées. Verdy p 26 août 2007 à 19:26 (UTC)

Je te renvoie à la section Wiktionnaire:Wikidémie/Rimes#Annexes ou Catégories pour la décision (le consensus) qui a été pris en faveur des annexes et non des catégories. Si tu veux qu'on utilise des catégories, tu peux toujours le reproposer sur cette page en avançant tes arguments. Mais pour le moment, ce sont des annexes que l'on fait, ne peux-tu pas attendre que l'on en ais discuté avant de créer tout ça ? Le Wiktionnaire a ses propres règles à ce propos, et les autres Wiktionnaires sont organisés autrement de toute façon. - Dakdada (discuter) 26 août 2007 à 19:59 (UTC)

Le consensus a été pris sur la base que ce serait compliqué à gérer ; avant de faire une proposition, je fait une ébauche séparée montrant que cela peut fonctionner de façon très simple (sans avoir à éditer séparément des annexes en plus des articles). Et que cela permettrait d'avoir un dictionnaire phonétique et de rimes complet, facile à réaliser par un bot pour les articles existants. Ceci dit, on peut avoir des annexes mentionnant les rimes les plus courantes, mais on est sûr d'en oublier un très grand nombre (des dizaines de milliers). Verdy p 26 août 2007 à 20:17 (UTC)

Hm l'avantage des annexes sur les catégories n'est pas la complexité de la gestion... enfin bref. Je te conseille quand même de dire ce que tu fais aux autres contributeurs (Wikidémie ou Wikidémie/Rimes) pour savoir ce qu'ils en pensent, il y en d'autres que ça intéressent (certains ont déjà bien bossé sur les annexes de rimes). Parce que tu es en train de refaire en double tout le travail dont on avait discuté :P - Dakdada (discuter) 26 août 2007 à 21:51 (UTC)

{{voir}} vs. {{-voir-}}

À l’article à (et peut-être ailleurs), tu as remplacé {{voir}} par {{-voir-}}. Ces deux modèles ont des vocations distinctes, et cette substitution était par conséquent erronée. On utilise {{voir}} pour lier les articles qui ne diffèrent en graphie que par les diacritiques, la casse ou un trait d’union. On utilise {{-voir-}} pour lier des articles de graphies différentes mais qui ont un rapport analogique ou thématique. Bonne continuation ! Urhixidur 27 août 2007 à 20:00 (UTC)

J'ai bienremarqué la différence et je ne pense pas m'être trompé. Le modèle sans les moins affiche un bandeau en tête de page pour toutes les langues, celui avec les moins est un sous-titre pour une langue spécifique.

Sur une page avec des définitions pour plusieurs langues, cela fait une différence notable, les liens avec moins étant pertinents uniquement pour une seule langue, et pouvant mentionner les paronymes de cette langue uniquement.

Les graphies avec autres accents ou traits d'union (avec voir sans moins) ne sont pastous pertinents pour une langue,et ondoitdétailler ceux concernant une langue.

Exemple :

• le a accent aigu n'existe pas en français, il ne peut y être dans la sous-section avec -voir-, mais figurera en tête de page avec voir, ET dans la section de la langue qui l'utilise.
• la a accent grave peut être dans le bandeau voir en tête, mais utilisé en français et pas dans les autres langues de la page ; on doit alors le rappeler dans la section française avec -voir- pour montrer qu'il y est en tant que paronyme.

Je me fie au sommaire généré pour le classement, sachant que le modèle voir sans moins ne peut être qu'en tête de page et pas spécifique à une langue.

Verdy p 27 août 2007 à 21:32 (UTC)

nowrap

À propos de {{fr-conj/Tableau}} renommé depuis en {{fr-conj/tableau-temps-simple}}. Note de GaAs 20 août 2012 à 18:20 (UTC) et {{fr-conj/Tableau-composé}}, il semble que style="white-space:nowrap" soit inefficace. Regarde par exemple Annexe:Conjugaison_française:anéantir renommé depuis en Conjugaison:français/anéantir. Note de --GaAs 20 août 2012 à 18:20 (UTC). Il faudra trouver un autre moyen. Urhixidur 30 août 2007 à 02:33 (UTC)

Pas du tout, il marche très bien, mais n'est utilisé QUE pour la partie sujet afin que la partie conjuguée ne se sépare pas sur une ligne différente (surtout si le sujet finit par une apostrophe). Les sauts de lignes restent autorisés dans la partie conjuguée, et dans la partie phonétique.

Ce changement permet d'afficher la page sur un écran en faible largeur, même sur les verbes longs.

Verdy p 30 août 2007 à 02:37 (UTC)

noinclude à la fin

Je suppose qu’il y a une raison technique pour cet arrangement ? Je trouve bizarre de devoir cacher le modèle sur sa propre page (avec <includeonly>) pour ensuite le ré-invoquer depuis sa sous-page d’aide (toujours avec <includeonly>), alors qu’il suffit de placer l’aide en tête de page (comme je l’avais fait). Urhixidur 30 août 2007 à 03:15 (UTC)

Oui le noinclude à la fin est lé au comportement des bots, d'autre part la documentation va utiliser le modèle pourdonner des exemples; l'usage sur tous les projets Wikimedia est de placer le noinclude à la fin (cela évite pas mal de problèmes avec les bots qui essaye d'inclure des interwikis ou catégories, sachant que si la page modèle se termine par un noinclude invoquant directement un seul modèle sans paramètre, c'est sa page de doc, qui contient toutes les métadonnées (aide, interwikis, catégories)

D'une façon générale, un modèle devrait toujours être encadré d’includeonly dans son contenu s'il a des paramètres, et ce contenu toujours placé en tête. l'ordre standard c'est includeonly puis noinclude pour tous les modèles.

Enfin cela évite une surcharge serveur, permet ensuite de protéger le modèle utilisé partout dans les pages; mais pas nécessairement de protéger sa doc ou ses métadonnées qui sont uniques et utilisées à un seul endroit restant modifiable.

La protection "en cascade" évite aussi de protéger la page contenant l'aide, les exemples, les catégories, et laisse les bots ajouter les interwikis. Cette disposition est renforcée depuis que le support des "sous-pages" ont été intégrées.

On peut parfaitement avoir une page d'aide montrant les exemples tels qu'ils figure sur la page du modèle principal.

Cette disposition permet aussi le renommage facile des modèles sans briser les liens, et permet aussi de tester des modifs de modèles sur différentes sous-pages de tests.

Verdy p 30 août 2007 à 04:06 (UTC)

X-SAMPA

J'ai ouvert une discussion sur la disparition du X-SAMPA ici. LBO disc 15 septembre 2007 à 17:57 (UTC)

Note: ce n'est pasmoi qui l'ai fait disparaitre. Il avait déjà été supprimé avant (incorrectement, puiqque X-SAMPA affichait en fait le paramètre 1 (API)... Je me suis contenté de corriger le code généré devenu inutile puis la suppressions du paramètre 2. Verdy p 15 septembre 2007 à 18:56 (UTC)

lien

Salut, Je viens d'essayer 'lien' en template:nl-nombre mais ca ne fonctionne pas..

c'est ton code dans {{nl-nombre}} qui est incorrect ... je l'ai corrigé, il marche !

le modèle génère déjà un lien ! Verdy p 16 septembre 2007 à 01:24 (UTC)

Mais comment le montrer comme 13?

Ah! Je vois. Merci Jcwf 16 septembre 2007 à 01:26 (UTC)

Concernant ton modèle, les liens localisés sont posés partout (donc plus de problème ensuite s'il y a d'autres langues dans les articles nommés en liens). Note bien comment le paramètre 3 peut nécessiter d'être nommé explicitement (3=...) si son contenu contient un signe = (contenu généré par un modèle par exemple, comme ici avec le modèle {{ex}} qui génère un signe égal dans un attribut HTML de mise en forme). Verdy p 16 septembre 2007 à 01:53 (UTC)

drachme

Salut, je viens de voir que tu as supprimé les rimes en -drachme de /aɡm/, leur présence était motivée par le fait que c'est leur ancienne prononciation. Voir l'article drachme du TLFi. Je pense qu'on pourrait les remettre avec une mention {{vx}}. Mais ça laisse à penser que c'est le mot qui est vieilli, alors que ce n'est que la prononciation... va falloir innover dans les modèles ;-) Stéphane8888 (discuter) 8 janvier 2008 à 22:09 (UTC)

Peut-être mais en dehors de ces pages de rimes, il n'en était même pas mention dans l'article lui-même ou les dictionnaires consultés. Je ne suis même pas certain que ce soit une ancienne pronociation, peut-être un accent particulier pour des natifs grecs, mais jamais entendu en français (je ne l'ai même pas entendu non plus en Grèce!)

Je me demande donc vraiement de l'opportunité de ces rimes en -/agm/, sinon il faudra en ajouter aussi partout où un /k/ est normalement prononcé. Dans ce cas on ajouterait alors plein d'autres prononciations comme /p/ > /b/, /m/ > /n/, /t/ > /d/, /b/ > /v/ ... on n'a plus fini et on n'a plus non plus de moyen de retrouver la prononciation normale de laquelle les autres prononciations alternatives se déduisents pour certains locuteurs seulement.

Ensuite il faudrait ajouter l'accent bègue (syllabes répétées), l'accent enrhubé (enrhumé), l’accent seveu sur la langue, l'accent enroué, l'accent parle avec le nez, l'accent chuchoté, l'accent anglais, etc. ! Verdy p 9 janvier 2008 à 00:27 (UTC)

N'ayant pas de compétences en linguistique, je m'efforce de m'appuyer sur des ouvrages. Je faisais référence à l'article drachme du TLFi, que je suis allé consulter après avoir été surpris de trouver des mots (en -achme) dans un dictionnaire des rimes (à /aɡm/) (celui de Léon Warnant (Larousse) et/ou celui d'Armel Louis (Le Robert)). Pour ma part, je n'ai jamais entendu cette prononciation, mais ce n'est pas une raison pour ne pas la signaler au lecteur. Je vais mettre à jour les articles. Stéphane8888 (discuter) 9 janvier 2008 à 08:43 (UTC)

C'est signalé par une réference expliquée dans celui de la rime en /akm/. ça devrait suffire non? Verdy p 9 janvier 2008 à 08:49 (UTC)

Oui je pense. L'essentiel est que cette info figure dans la page des rimes. Les articles sont en cours d'amélioration. Stéphane8888 (discuter) 9 janvier 2008 à 10:30 (UTC)

Modèles

J'attire ton attention sur la Wikidémie : 2.11 Modèles trop compliqués. Il est clair qu'on ne peut pas compliquer encore les modèles existants, surtout ceux qui sont très utilisés, comme trad, ni rajouter des niveaux d'imbrication, mais qu'il faut faire tout le contraire, on n'a pas le choix. Pour les catégories, il faut d'abord discuter si le jeu en vaut la chandelle, et si oui discuter comment faire. Les robots peuvent être utilisés pour rajouter des catégories, par exemple c'est ce qui a été fait pour les palindromes. Peux-tu donner ton avis sur la Wikidémie ? Lmaltier 16 janvier 2008 à 17:55 (UTC)

J'en ai discuté il y a plusieurs mois et ils sont déjà en place. Et j'en ai aussi reparlé hier. Où sont les modèles "trop compliqués"? surtout qu'ils ont hyper simples d'emploi et vraiment très courts. Ils servent aussi à la génération de noms de catégories corrects dépendant des noms de langues.

Si j'ai fait d'autres corrections hier c'est en voyant justement que les traductions généraient des liens incorrects pour un certain nombre de langues, visible dans les articles.

Peux-tu donner un exemple, car là je ne vois pas ce que j'ai pu mal faire. Verdy p 17 janvier 2008 à 00:51 (UTC)

Les modèles (surtout quand on développe leurs appels imbriqués) ont une tendance à devenir de plus en plus compliqués (cf trad, ou fr, par exemple, qui était à la base simplement français), tellement qu'ils empêchent d'ores et déjà d'afficher certaines pages, car leurs appels successifs développés deviennent énormes et dépassent la limite autorisée par page (limite qu'il est indispensable de maintenir). Je faisais allusion à ta suggestion de créer un niveau supplémentaire pour trad, qui aggraverait encore la situation. Par ailleurs, merci d'aller voir la discussion sur la Wikidémie : toute le monde ne pense pas que les modèles sont ultra-simples d'utilisation. En fait, il faudrait réfléchir pour voir comment s'en passer au maximum. Lmaltier 17 janvier 2008 à 06:50 (UTC)

D'une part ils sont déjà utilisés depuis pas mal de temps (et servent à la génération de liens vers des pages ou catégories correctement nommés en fonction de la langue et la bonne grammaire française. Quant à leur taille elle est vraiment ridicule (une dizaine de caractères une fois inclus, confirmé dans les statistiques générées dans les commentaires HTML des pages). Leur poids est sans commune mesure avec celui des pages de discussion ou des articles eux-mêmes et de pratiquement tous les autres modèles.

D'autre part tu as cité une discussion sur la Wikidémie, mais je n'ai absolument rien vu à ce sujet là-bas. J'ai même été voir la liste de tes propres contributions pour savoir où tu avais bien pu en discuter, et je n'ai rien trouvé du tout.

C'est sûr que je ne les ai pas utilisé partout sur tous les modèles de langue, mais ils ont été mis en place au fur et à mesure des besoins (où ils sont utiles par certains modèles spéciaux de navigation, pour les langues qui ont mis en place cette structure).

Je n'ai vu non plus aucun commentaire nulle part ailleurs à ce sujet, ni aucun lien mentionnant un quelconque problème sur ces modèles dans une discussion.

Si il y a bien eu quelqu'un à en discuter sur un espace public, c'est bien moi et uniquement moi, à plusieurs reprises, et sans aucune opposition depuis des mois. Bref je n'ai pris personne "en traître".

Tes références? Verdy p 18 janvier 2008 à 04:32 (UTC)

J'ai donné la référence de la discussion : c'est le chapitre 2.11 actuel de la Wikidémie. Elle donne un exemple de page qui ne s'affiche pas correctement à cause des modèles. Le problème n'est pas la taille apparente de chaque modèle, mais le fait que chaque modèle trad, par exemple, est gros une fois traité, et les appels qu'il inclut développés. On peut voir la taille concernée, quand elle dépasse la limite, en affichant le code source dans son navigateur Par ailleurs, j'avais proposé une nouvelle politique stricte de gestion des modèles, visant, pour diverses raisons, à ne jamais modifier un modèle très utilisé sans discussion préalable suffisante (il faut savoir prendre son temps). Il n'y avait pas eu d'opposition. Lmaltier 18 janvier 2008 à 06:44 (UTC)

Oui je sais que les stats sont visibles dans le source (d'ailleurs je l'ai dit juste au dessus avant que tu me le dises).

Ce qui est bizarre est que ce problème apparaisse seulement maintenant. Alors que les modèles sont là depuis des mois!

Il y a du y avoir un problème dans le code de MediaWiki pour provoquer une telle explosion, car cette expansion soudaine du volume des trad ne posait pas de problème avant.

Je suis en train d'en compacter le code réellement utile, ça résoud la moitié des problèmes. Mais ce n'est pas lié au fait de mes modifs ou des modèles de langue qui sont là depuis longtemps maintenant. je soupçonne plutôt un problème de MediaWiki dans la gestion de ses caches mémoire, il doit certainement étendre des modèles des zones noinclude alors que ce problème avait été réglé.

De plus je note que MediaWiki ajoute beaucoup de traitement en plus maintenant pour gérer des listes de métadonnées supplémentaires, et j'ai bien l'impression qu'il inclut ce travail supplémentaire dans ses statistiques.

Je note que des problèmes similaires sont apparus récemment dans plusieurs Wikipédias... avec des pages qui ne marchent plus, ou de sérieux problèmes de performance sur certaines pages qui ne posaient aucun problème jusqu'à présent. Verdy p 18 janvier 2008 à 06:52 (UTC)

Bon j'ai trouvé ce qui a changé: le #switch alloue beaucoup trop de mémoire (en fait deux fois trop) et étend aussi à nouveau toutes les clauses, même celles dont on ne se sert pas, ce qui multiplie le nombre d'invocations des sous-modèles (et peut donc nécessiter 10 à 20 fois plus de mémoire que nécessaire). C'est bien un bogue de MediaWiki.

J'ai trouvé un contournement propre, maintenant les articles sont convertis à nouveau sans problème et sans explosion en mémoire (le switch sur des valeurs constantes toutes connues est remplacé par des invocations de sous-modèles distincts). Il y a un problème similaire, mais moins critique, pour le #if (qui lui aussi alloue quatre fois trop de mémoire). Verdy p 18 janvier 2008 à 08:11 (UTC)

Les problèmes sont venus de la sophistication progressive des modèles. Je ne sais pas si on peut parler de bug, puisque le logiciel marchait, mais il n'est pas impossible qu'ils puissent faire mieux. La page repousser s'affiche bien maintenant, donc le problème est peut-être moins urgent, mais il faut le garder à l'esprit. Lmaltier 18 janvier 2008 à 19:40 (UTC)

J'ai toujours été conscient de ces problèmes qui ne sont pas nouveaux. Il est dommage que MediaWiki ne teste pas mieux ses utilisations de mémoire. Son principal problème est encore actuellement le manque évident d'une évaluation paresseuse pour les modèles, il faut trop de travail pour rien. Mais en plus il décompte mal son besoin réel en mémoire, ou en gaspille. Mais les changements d'une version à l'autre ne sont pas mesurés (le cas du switch est un bogue nouveau).

Concernant le modèle trad, il est évident qu'il est utilisé à très grande échelle, et dans l'article repousser il génère à lui seul plus de 2000 appels de modèles de langue (j'en ai réduit la moitié des utilisations, avant il en fallait plus de 5000 pour le même contenu d'article !!) Verdy p 18 janvier 2008 à 19:48 (UTC)

Dernier point: on pourrait encore diviser par 2 le nombre d'utilisation des modèles de langue si on n'utilisait plus le nom de la langue pour catégoriser les traductions, mais seulement le code langue tel qu'il est passé en paramètre. Vu que ces catégories sont un peu fourre-tout, l'utilité de les titrer en clair est peu évidente. Il me semble même qu'on pourrait se passer de ces catégories qui remplissent inutilement les fins d'articles, en utilisant autre chose pour trouver des listes de traductions. Verdy p 18 janvier 2008 à 19:51 (UTC)

Ceci dit, le succès du wiktionnaire français est du en grande partie à ses modèles qui ont permi de l'enrichir facilement et rapidement sans trop de travail pour les éditeurs et rédacteurs, et permis l'utilisation de robots pour affiner correctement la classification. Il est significatif d'ailleurs que c'est le wikitionnaire français qui sert de référence pour les autres (le wikitionnaire anglais a grandement rattrapé son retard en "rempompant" pas mal du français; mais il semble inévitable qu'il reprendra la tête, sauf si on trouve des sources de données de dictionnaires bilingues français-autre).

Et il faudra aussi songer à revoir notre page d'accueil très fouillie et amateur, on ne sait pas par où aller (la version anglophone est franchment bien meilleure et invite mieux les visiteurs à à consulter le contenu). Verdy p 18 janvier 2008 à 19:57 (UTC)

Concernant {{trad}}, {{trad-}} et {{ucf}} (mais, curieusement, pas {{lien}}), l’intention est louable mais...Aucune décision n’avait été prise jusqu’ici (voir la Wikidémie et la Gestion des modèles), et je ne crois pas que le bot nécessaire (pour insérer les défauts omis sur les diverses pages utilisant ces modèles) ait été exécuté. Sans compter que l’aide des modèles n’avait pas été mise à jour. D’où ré-insertion des défauts. Urhixidur 18 janvier 2008 à 20:04 (UTC)

L'intention était avant tout de réduire la complexité, pour rétablir les pages qui ne s'affichaient plus du tout correctement; j'ai exploré différentes pistes, dont la suppression des valeurs par défaut qui semblent inutiles pour l'immense majorité des pages où ces modèles sont correctement utilisés et paramétrés (quitte à ce qu'une minorité de page soit à corriger). Mais avoir des articles complètement inaffichable était plus urgent à régler. J'ai trouvé depuis une autre solution qui a résolu l'esentiel des problèmes. Le fait de réintroduire les valeurs par défaut a un effet mineur puisque l'essentiel a en fait été gagné ailleurs (j'ai même essayé de voir si l'inclusion des pages d'aide par noinclude posait problème, mais apparemment cela n'avait pas d'effet sensible, j'ai déjà annulé cette tentative car MediaWiki ne semble pas avoir de problème à ce niveau et gère correctement les noinclude (mais il a toujours une utilisation trop importante de m"moire pour les passages de paramètres, où tous les paramètres sont systématiquement doublés en taille, selon une progression exponentielle selon le niveau d'imbrication).

Nos problèmes ici devraient être évoqués sur le BugZilla de MediaWiki. L'évaluation paresseuse des modèles (et surtout des ParserFunctions, notamment #if et surtout pour #switch, mais c'est en fait applicable à n'importe quel modèle) devient une modification à faire urgente, pour la stabilité de tous les wikis (pas seulement le wiktionnaire). Verdy p 18 janvier 2008 à 20:17 (UTC)

Note bien quand même: le rétablissement des valeurs par défaut pour trad et trad- a doublé le besoin en mémoire dans la page repousser, notamment pour le preinclude qui est repassé de 300Ko à plus de 600Ko (note que le HTML généré fait près de 140Ko, dont environ 80Ko provenant des modèles utilisés, presque tout le reste étant l'expansion de syntaxe Wiki vers HTML) mais aussi le postinclude qui repasse de 120Ko à plus de 300Ko : on est dans cet article pratiquement à la limite de ce qu'on peut mettre dans un article, le plus gros provenant des seules traductions (pour lesquelles on génère trop de liens de catégorie redondants et sur lesquels on peut encore gagner si on tient à les conserver, mais franchement il vaudrait mieux se passer de ces catégories et trouver autre chose pour gérer ces métadonnées, par exemple une recherche par page spéciale).

Si je n'avais pas touché au modèle lien, c'est parce que ce n'était pas nécessaire. Sachant la très forte utilisation des modèles trad dans les articles, le modèle lien n'y est plus utilisé mais est substitué directement (sinon multiplication par 4 de la taille mémoire nécessaire). Verdy p 18 janvier 2008 à 20:32 (UTC).

En tout cas, on ne pourra plus prendre la page repousser comme test : le gros tableau de traductions était répété, alors qu'elles étaient en fait à classer entre les sens. J'ai supprimé le premier tableau. Lmaltier 18 janvier 2008 à 21:31 (UTC)

Y a-t-il d'autres exemples de pages contenant une centaine de traductions? En fait je me demande s'il est même utile de lister tous les synonymes d'une langue donnée, alors qu'on fournit un lien vers une page spécifique pour un des mots traduits dans lequel on aura d'autres synonymes dans cette langue. Le cas traité me parait assez pathologique d'un abus de synonymes (en anglais, allemand et néerlandais), surtout quand ils ne sont mêmes pas différenciés (autrement dit, implicitement synonymes jusqu'à preuve du contraire).

J'ai essayé de chercher une telle page avec de très nombreuses traduction, sur des mots à priori bien plus usuels comme "chanter", "aimer", "dire", "faire", "avoir", "être", "pouvoir"... pas moyen de trouver un tel cas!

Bref ce problème me semble être spécifique à cet article, raison pour laquelle on n'a pas peut-être pas détecté le problème avant. Je vais essayer de voir qui a contribué à tous ces ajouts de traduction, pour voir si la même personne a fait la même chose ailleurs. Si c'est un robot qui ajoute tous ces synonymes de traduction, il faut peut-être le régler pour qu'il soit moins agressif, et ne le fasse que quand c'est plus pertinent (par exemple, absence d'autres traductions dans la langue donnée).

C'est bien un robot qui ajoute toutes ces nombreuses traductions non classées, PiedBot est à pacifier donc. Verdy p 19 janvier 2008 à 00:19 (UTC)

Format

Deux détails :

• on ne pas de majuscules dans les clés de tri. Au contraire, ça sert entre autres à ne pas tenir compte des majuscules.
• les catégories sont en fin de page. Je serais personnellement partisan de changer, et de les mettre en fin de section de langue, mais il faut en discuter.

Lmaltier 26 janvier 2008 à 21:00 (UTC)

Tu as tord... elles sont utilisées depuis longtemps et sans problème. Le tri français est un tri à trois niveau et le modèle clé de tri génère depuis longtemps des clé correctes, à condition de laisser la casse. Sinon on se retrouve à faire un tri sur deux niveaux seulement. Si on doit encore fournir un paramètre à {{clé de tri}} c'est uniquement car il n'y a pas de fonction Wiki qui sache transformer une chaine sans accent ni ponctuation. En revanche, les finctions parseur savent très bien extraire une chaine convertie en minuscules pour les clés primaires et secondaires. La clé tertiaire sert à la fin pour le tri final.

Je t'invite donc à essayer et vérifier par toi-même que la clé de tri indiquée en paramètre en conservant la casse ne pose d'une part aucun problème des problèmes que tu crains (car ils sont pris en charge) et permet de résoudre le tri au niveau le plus fin. Il n'est nécessaire d'indiquer la valeur que de la clé de tri secondaire (avec sa casse inchangée), que MediaWiki ne sait pas générer lui-même.

Verdy p 27 janvier 2008 à 11:30 (UTC)

Je ne comprends pas. Ce que je sais, c'est que, quand on met un paramètre, c'est censé être la clé de tri désirée. Même si ça marche quand on met des majuscules, c'est tout à fait trompeur d'en mettre. Lmaltier 27 janvier 2008 à 21:34 (UTC)

Je viens juste de voir tes modifications. Avant ces modifications, on donnait bien comme exemple : pour César, la clé de tri à spécifier devait être cesar. Et c'est ce qui est appliqué à grande échelle. Il faut en discuter avant de faire ce genre de changement... Lmaltier 27 janvier 2008 à 21:42 (UTC)

Ce que tu ne comprends pas c'est que le français ne trie pas sur une seule clé mais en fait sur au moins trois. Et la casse des caractères, même si elle n'influe pas sur les clés des deux premiers niveaux, influe sur le troisième.

Cela ne trompe pas du tout de laisser la casse originale. On doit utiliser le modèle clé de tri s'il y a des majuscules, mais on ne doit fournir un paramètre que lorsqu'il y a des accents et séparateurs à ignorer dans les deux premiers niveaux de tri (qui de toute façon ignorent la casse, contrairement au troisième).

De toute façon pas d'inquiétude ici : la différence est très minime, sauf en de très rares cas particuliers. Il ne s'agit pas de reparcourir les centaines de milliers d'articles (pas nécessaire du tout) pour remettre la casse originale dans les clés qui ont été fournies, seuls quelques articles trouvés ça et là en parcourant les catégories pouvant nécessiter de mettre une distinction plus précise. Si la casse a été supprimée des clés indiquées, ça continuera de bien marcher dans 99,99% des cas.

A ce sujet, j'ai du modifier hier la méthode de génération de clé composée en me rendant compte d'un nouveau bogue de MediaWiki (ou d'une modification de la façon dont il gère la directive nowiki) car cela a alourdi les clés générées avec du code ui aurait du rester invisible dans les clés (en efet cela posait des problèmes avec des clés trop longues et un tri incorrect dans certaines catégories, notamment les catégories contenant des phrases et locutions longues, ou bien des problèmes de débordement). Ce ne se voyait pas dans la feuille de teste quand on affichait les clés calculées, mais uniquement dans la clé de tri réellement utilisée et visible indirectement dans les liens "200 suivants" et "200 précédents", ainsi que dans l'explosion brutale du volume des index (et donc dans les performances de recherche et d'affichage des catégories) alors que cela n'influait pas du tout sur la taille du HTML généré.

Verdy p 27 janvier 2008 à 21:52 (UTC)

Ce que je veux dire c'est qu'on peut mettre la casse qu'on veut, et ça marche quand même, sauf pour les rares cas où il faut corriger localement dans une catégorie. Cela ne touche que les cas où MediaWiki ne sait pas traiter certains caractères et effectue un changement incorrect de la casse par méconnaissance de certains caractères ou de cas particuliers pour le changement de casse où celui-ci est contextuel. Verdy p 27 janvier 2008 à 21:56 (UTC)

D'ailleurs c'est moi qui ait créé et mis en place le tri multiniveau sur ce wiki il y a plusieurs mois, et corrigé pas mal de clés incorrectes, les catégories se sont magiquement retrouvées néttement mieux organisées et plus conformes à nos dictionnaires. Verdy p 27 janvier 2008 à 22:00 (UTC)

Ce sur quoi j'insiste, c'est qu'il faut toujours en discuter avant de faire quelque chose qui a un impact global, même si on est convaincu que c'est utile. Cela est vrai pour tous les wikis, ça ne peut pas marcher autrement. La preuve, c'est que je n'étais pas conscient des changements apportés, et il me semble évident que je n'étais pas le seul dans ce cas. Si tu n'es pas d'accord avec cette règle, tu peux le dire sur Wiktionnaire:Gestion des modèles. Si tu es d'accord, merci de respecter cette règle. Lmaltier 28 janvier 2008 à 20:35 (UTC)

A ce sujet, j'en avais discuté justement aux endroits appropriés (notamment dans la page d'aide du modèle {{clé de tri}}). Je sais, ça date ! Mais c'est pourtant ce modèle qui est généralisé partout dans presque tous les articles et même de nombreuses catégories. La page mentionne bien (depuis longtemps) que la casse originale devrait être conservée dans la clé donnée, puisque le modèle prend en charge correctement cette différence de casse, et en tient compte pour la clé effective calculée. verdy_p 8 novembre 2008 à 06:49 (UTC)

lopadotemakhoselakhogaleok...

Je ne sais pas si j'ai bien fait, mais comme je venais de dire à Hégésippe Cormier que je n'attendrais plus d'être sûr pour agir [1], j'ai appelé à l'aide sur w:Wikipédia:Le_Bistro/9_octobre_2008#lopadotemakhoselakhogaleok...

C'est quoi ce truc ? Je ne recopie aucun lien sur ce machin : allez juste voir les RC du Wiktionnaire, et vous comprendrez : nous avons besoin d'aide. --Szyx (d) 9 octobre 2008 à 22:08 (CEST)

Voir sur wp pour les détails et la suite des évènements. --Szyx 9 octobre 2008 à 20:55 (UTC)

Je crois que tu devrais attendre un peu. D'avoir de l'aide. --Szyx 9 octobre 2008 à 20:58 (UTC)

Je ne vois pas du tout quel est le rapport de cet article avec les discussions concernant les usurpations d'idéntité d’Hégésippe sur Wikipédia (à moins que l'usurpateur a utilisé il y a un certain temps une adresse IP que j'utilise en ce moment même; note: j'ai changé récemment de FAI).

Je n'ai pas créé l'article je le découvre, et en voyant que des références existent et qu'il est repris sur plein de Wikipédias, ou ailleurs, je ne vois pas pourquoi il faut adopter la méthode de "suppression d'urgence" (je ne vois pas de vandalisme ici dans cet article).

Ou alors il faudrait aussi agir sur tous les wikis où le terme est présenté.

je me suis contenté d'améliorer un peu la présentation, je n'ai rien inventé. Verdy p 9 octobre 2008 à 21:06 (UTC)

Mea culpa. --Szyx 9 octobre 2008 à 21:26 (UTC)

Tant qu'à faire j'ai renommé l'article en écriture grecque (abrégée car en grec cela dépasse les limites de longueur de MediaWiki). C'est aussi bien abrégé pour nettoyer les catégories... Verdy p 9 octobre 2008 à 21:28 (UTC)

Mea culpa. Il n'y a aucun lien avec Hégésippe Cormier, sauf la coïncidence de temporelle. Et, à ma connaissance, je ne t'ai accusé de rien, au contraire je t'ai cité comme étant l'un de ceux qui tentaient de résoudre le problème. --Szyx 9 octobre 2008 à 21:26 (UTC)

Sois plus prudent dans ce que tu écris au bistro de Wikipédia, car franchement ce que tu y as écris et les réactions obtenues suggérait le contraire. Merci donc de ne pas reblanchir à nouveau en express avec {{supp}}, car l'usage de ce modèle ne le permet pas de cette façon. Personnellement je n'utilise {{supp}} que pour nettoyer des redirections créées par renommage suite à une erreur dans un nom, ou pour de réelles créations d'articles polluants, ou au contenu contraire aux règles. Verdy p 9 octobre 2008 à 21:37 (UTC)

J'ai été stupide, à de nombreux niveaux, dans mon intervention ce soir là. Stupide au point que toi (mais si cela avait été l'un ou l'autre contributeur d'ici, cela aurait été pareil) a pu penser que je devenais un vandale. Je te renouvelle donc mes excuses.

À aucun moment je n'ai imaginé que tu puisses être une cause de trouble.

Par contre, c'est évident, je n'ai pas bien interprété ce qu'il s'est passé. J'espère qu'on me pardonnera.

Amitiés. --Szyx 12 octobre 2008 à 17:38 (UTC)

Conflit

Désolé, j'avais attendu un peu en pensant l'éviter, mais pas assez de toute évidence. Amitiés. --Szyx 29 octobre 2008 à 17:50 (UTC)

yiddish

Bonjour. Pourquoi vouloir utiliser yidiche à la place de yiddish. L'orthographe yiddish était tout à fait volontaire, car c'est l'orthographe courante. On en avait déjà discuté. Pour moi, privilégier une orthographe extrêmement rare plutôt que l'orthographe courante est un problème de neutralité très sérieux : nous sommes là pour aider les lecteurs, pas pour promouvoir une orthographe.

C'est mentionné dans les sources officielles françaises, canadiennes et internationales (organismes de normalisation et comités de terminologie, ainsi que dictionnaires) qui recommandent l'orthographe que s'écrit et s'accorde normalement en français. Les deux orthographes sont liées dans le wiktionnaire. verdy_p 30 octobre 2008 à 06:39 (UTC)

(je n'avais pas vu cette réponse) C'est l'orthographe 1990, je sais. Et alors ? Cela ne change rien à ce que j'ai dit. La neutralité ne consiste évidemment pas à adopter la position officielle (Wikipédia le sait bien dans ses articles sur les pays), seulement à la rapporter. On doit utiliser les mêmes orthographes que tout le monde, en utiliser d'autres consisterait à les promouvoir, ce qui n'est pas neutre du tout. Lmaltier 31 octobre 2008 à 06:11 (UTC)

Par ailleurs, je ne comprends pas la raison des changements sur les modèles de langues, mais j'ai l'impression qu'ils compliquent les modèles, ce qui peut aussi être un problème sérieux, en raison des limitations du logiciel. Pourrais-tu expliquer les raisons des changements, et lancer une discussion ? (pour des changements d'ordre aussi général, une discussion collective s'impose) Lmaltier 30 octobre 2008 à 06:35 (UTC)

Cela ne complique pas du tout c'est en place depuis plus d'un an pour certaines langues (toutes les plus courantes y compris le français, il ne faut pas dire que ça complique les chose ni que ça alourdit), j'ai laissé de côté le projet pendant quelques temps, mais c'est en cours de généralisation sur le reste. Ces modèles sont extrèmement courts, et pas compliqués du tout à utiliser dans leur forme avancée, et ils évitent aussi la multiplication d'autres modèles en centralisant l'effort en un seul endroit sans casser le reste (ces modèles donnent aussi les accords corrects dans l'emploi en tant qu'adjectifs, simplifient la manipulation des catégories, etc.). verdy_p 30 octobre 2008 à 06:39 (UTC)

Si ça évite la multiplication des modèles, c'est en compliquant les modèles existants. Au départ, le modèle ne comprenait qu'un mot (le nom de la langue), il est donc clair qu'il se complique. Je parle de complication non pas du point de vue utilisation, mais du point de vue traitement technique, c'est là qu'il y a un risque : on a déjà eu des pages qui s'affichaient mal alors que les modèles étaient corrects, mais trop compliqués, et avec beaucoup d'appels dans la page. Il y a des limitations dans le logiciel (et elles ont leurs raisons, valables). S'il y a eu une discussion à ce sujet, je l'ai ratée. Pourrais-tu me l'indiquer ? S'il n'y en a pas eu, il faut la lancer.

Pourrais-tu aussi revenir aux versions précédentes pour yiddish ? Lmaltier 30 octobre 2008 à 06:47 (UTC)

Pourquoi continuer avant discussion ? Si tout ce travail est supprimé, c'est du temps perdu, purement et simplement. Lmaltier 31 octobre 2008 à 07:12 (UTC)

Parce que j'ai fait des tests et me suis aperçu que je pouvais gagner encore en mémoire. Je ne vois pas où ça se discute (hormi toi sur ma page ici) alors que c'est déjà en place depuis longtemps. honnètement ton inquiétude n'est pas fondée et les statistiques serveur le prouvent (j'ai une page de test où tous ces modèles sont inclus des milliers de fois, avec leurs sources et leurs rendus... ça passe comme un charme).

La dernière optimisation que j'ai trouvée est de réduire d'un niveau un appel de modèle, c'est ce que j'ai testé et que j'applique manitenant, ça marche sans modification de tout le reste. Je suis l'auteur de tous ces modèles, et j'en ai vérifié plein d'autres qui étaient erronés (au passage il y a une bonne vingtaine de codes faux ou en conflit dans ce que j'ai parcouru, j'en ai dressé une liste... verdy_p 31 octobre 2008 à 07:17 (UTC)

Tout ça ne me dit aps où ça a été discuté. On ne change pas tous les modèles de base, utilisés absolument partout, sans discussion et sans en parler à personne. Il faut lancer cette discussion. Lmaltier 31 octobre 2008 à 07:19 (UTC)

C'est en passant cette liste en revue que le cas du yidiche m'est apparu, mais comme les références données sont bonnes, je me suis appuyé pas seulemetn sur l'orthographe de 1990, mais surtout sur les références ISO, et diverses sources académiques françaises ou non qui sont toutes d'accord (à ce sujet avant cette décision, il n'y avait AUCUNE orthographe recommandée mais "yidiche" existait déjà parmi celles-ci. Rien ne dit que "yiddish" soit plus courant en français, sauf pour ceux qui retiennent l'orthographe anglophone (mais l'orthographe allemande serait en fait aussi juste et certainement plus appropriée, et on pourrait aussi retenir l'orthographe en ladino, en judéo-espagnol, etc... Avant 1990 il n'y a jamais eu consensus pour l'orthographe française, d'où les nombreuses variantes, depuis 1990 c'est clair (et les dicos français actuels retiennent aussi yidiche, simplement car ça respecte l'orthographe classique française et autorise les accords normaux sans créer d'exception. "yiddish" est donc bien perçu maintenant comme un anglicisme).

Cependant puisque tu parles des modèles de langues ça a été discuté vers le printemps 2007 (quand la nouvelle mouture a été testée et finalement a commencé à être déployée pour les principales langues (ici je ne fait que terminer le travail en prévision de modèles de classification qui les utiliseront plus facilement (au lieu de devoir tout gérer à la main, y compris les problèmes liés aux renommages et recatégorisations). Les discussions portaient alors sur les problèmes posés sur des pages où figuraient de nombreuses traductions, et c'est moi qui l'ai finalement résolu avec des modifications de modèle en prenant en compte leur complexité effective. Mais ne me demande pas de retrouvé où, ça fait trop longtemps. A toi de chercher, j'ai autre chose à faire... verdy_p 31 octobre 2008 à 07:27 (UTC)

Sous Google (pages en français uniquement) : yiddish : 1 210 000, yidiche : 413. Il ne faut pas dire n'importe quoi et prétendre que yidiche est l'orthographe habituelle, ce n'est quasiment pas utilisé. Mais ce n'est pas le lieu pour discuter de ça. Si tu veux lancer une discussion (et un vote), vas-y, sinon, reviens en arrière.

Désolé de te dire que Google ne sait pas identifier le français la plupart du temps, et dans le doûte, il inclut les résultats pour des pages en anglais s'il apparait qu'un terme a nue orthographe alternative acceptable en français. De plsu il va retrouver des tas de pages à l'orthographe très approximative, et ce ne peut pas être une référence pour le wiktionnaire. Note bien qu'il ne s'agit pas de nommer un article (les deux articles sont présents et inter-liés), mais un nom affiché automatiquement dans les titres et qui devraient privilégier l'orthographe officielle depuis longtemp. "yidiche" est cité en premier dans la liste ISO 639-1 depuis plus de 20 ans, et ça n'a pas changé malgré les réformes dans ISO 639-2 et ISO 639-3, et "yidiche" est toujours retenu aussi pour la locale française CLDR (où la politique est asusi d'utiliser en priorité les ressources des organismes de normalisation, surtout si elles sont approuvées par les auteurs de dictionnaires. Le wiktionnaire francophone devrait utiliser le choix déjà fait depuis longtemps dans les dictionnaires francophones, et ne pas cnotinuer à afficher les anglicismes datant du temps où de multiples orthographes existaients. Aujourd'hui le choix est très clair!

Par curiosité (même si ça ne doit pas d'influence, à mon avis, sur la décision), quels sont ces dictionnaires francophones dont tu parles, qui ont fait le choix de privilégier yidiche ? Les 8 dictionnaires et encyclopédies papier que j'ai consultés et qui mentionnent le mot utilisent tous yiddish, sauf un qui donne yiddisch (un dictionnaire franco-allemand...). Aucun ne mentionne yidiche, sauf le Robert historique, qui le mentionne parmi une liste d'orthographes vieillies. Lmaltier 7 novembre 2008 à 19:26 (UTC) Je viens de chercher aussi sur Internet (TILF, Mediadico, Orthonet, Reverso, Encarta). Tous donnent yiddish, seul Reverso connait aussi yidiche. Lmaltier 7 novembre 2008 à 20:21 (UTC)

Je ne vois pas pourquoi tu insistes: tu m'as donné un ordre, et en plus je m'y suis plié en dépit de la discussion que j'ai laissé continuer sans la perturber contrairement à ce que tu crois. Tout est déjà rétabli, depuis que tu as changé le modèleyi/type, les pages sont déjà en court de traitement et ça sera fini quand la job queue aura fait un tour, je suis intervenu pour seulement réinverser les redirections de la douzaine de catégories, sans toucher aux articles). verdy_p 7 novembre 2008 à 20:29 (UTC)

Je ne parle plus de ça. Je l'ai dit, c'est par curiosité que je pose la question. Je te demande simplement à quels dictionnaires tu faisais allusion. Lmaltier 7 novembre 2008 à 20:34 (UTC)

Ceci dit, je n'ai pas touché aux articles ou catégories, hormi le fait d'inclure {{yi}} à la place d'une référence directe au mot "yiddish". C'est donc très facile à renverser (d'ailleurs cela reste dans les historiques des catégories blanchies: un seul revert de ces catégories blanchies les fait se réafficher, et un seul changement dans le modèle {{yi}} permet de tout basculer d'un coup, puisqu'il n'y a plus de référence directe au mot "yiddish" ni même "yidiche" en dehors des termes définis et du titre des deux articles... verdy_p 31 octobre 2008 à 08:31 (UTC)

Si tu ne retrouves pas la discussion, alors il faut la refaire. Personnellement, les changements sur les modèles de langue me semblent complètement injustifiés, étant donné l'objectif qu'avaient ces modèles. Lmaltier 31 octobre 2008 à 07:44 (UTC)

L'objectif existait depuis longtemps. Il y a eu un problème au printemps 2007, mais c'est bien ma solution qui l'a réglé complètement (ce ne serait plus un problème aujourd'hui car le logiciel a évolué entre temps). Je le répète le coût de ces modèles est négligeable, cela ne génère pas d'octets en plus en mémoire sur le serveur. Et je viens de trouver ce matin le moyen de réduire encore un appel de modèle (et encore réduire une poignée d'octets par inclusion), au moment où tu m'as écrit ce matin. Je ne fais pas ce genre de modif à la légère, et justement je suis parfaitement conscient des limites du serveur: ces modifs anticipent d'autres problèmes tant de charge (mémoire, fichiers, caches, complexité) que de gestion du contenu du wiktionnaire et de facilitation de sa maintenance. Ces modèles nouvelle version sont même moins couteux (je l'ai vérifié!) que ceux qui incluent un seul mot et ensuite mettent une trop longue section noinclude pour la catégorisation et les liens. Et je le répète je les ai testé sur une page qui les inclut en masse, ce que le serveur traite pourtant facilement en un temps très court et sans atteindre les limites définies en terme de récursion, mémoire, tailles de paramètres, etc... (j'en suis TRES loin, même sur cette longue page). verdy_p 31 octobre 2008 à 08:31 (UTC)

Nonobstant la question yiddish/yidiche, faut-il supprimer Catégorie:yiddish (et ses descendants) ou les remplacer systématiquement par #redirect [[:Catégorie:yidiche]] (et équivalents pour les descendants) ? Dans un cas comme l’autre, je suis prêt à aider. Urhixidur 4 novembre 2008 à 19:44 (UTC)

Pour l'instant elles ne sont pas supprimées mais seulement blanchies pour ne pas être visibles dans les autres catégories. Mais elles sont vides de toute façon donc inaccessibles (les autres sont renseignées directement via les modèles qui les référencent).

Cela ne concerne en fait que 5-6 catégories environ. Il n'y a rien à toucher aux articles (du moins quand j'avais vérifié, ça a peut-être bougé de puis) même si l'orthographe est modifiée à nouveau dans le seul modèle où l'orthographe est indiquée. Donc cela ne fait pas beaucoup de travail! (Si le revert est fait, la seule chose à faire à de faire un revert du blanchiement des catégories avec l'orthographe anglaise, car elles étaient déjà prête avant le blanchiement). On aura vite fait le tour... verdy_p 4 novembre 2008 à 19:51 (UTC)

Je signale une discussion un cours sur la Wikidémie. Merci de participer. Je pense qu'il est bon de mettre en place, de toutes façons, des redirections appropriées (par exemple catégorie:yidiche vers catégorie:yiddish). Lmaltier 5 novembre 2008 à 07:24 (UTC)

Les redirections ne marchent pas pour les catégories (qui ne supportent donc pas non plus le renommage). Tout ce qu'on peut y faire c'est insérer un modèle d'alerte signalant l'adresse de l'autre catégorie, et auto-catégorisant la catégorie "pseudo-redirigée" dans une catégorie spéciale "Wiktionnaire:Catégorie redirigée" (comme cela se fait sur Commons), afin de trouver facilement les pages qui utilisent la mauvaise catégorie et permettre leur fusion facilement. Dans l'immédiat, je ne pense pas que ce soit nécessaire car les articles utilisent les modèles pour générer les bons noms de catégorie. Avant de blanchir ces catégories (pour qu'elles ne polluent pas les super-catégories dans lesquelles elles étaient avant la fusion), j'ai évidemment vérifié que tous les articles, modèles et discussions référençaient un seul nom de catégorie (et j'ai aussi pris le soin de ne pas mettre le nom de la langue en dur mais en utilisant le modèle de langue, ainsi si ça change, on n'a pas des centaines de pages à passer en revue). Je ne sais pas s'il y a un tel modèle en place ici sur le Wiktionnaire.

Euh, en fait les redirections fonctionnent pour les catégories, il suffit de mettre un deux-points supplémentaire en préfixe. Par exemple, #redirect[[:Catégorie:yidiche]]. Urhixidur 6 novembre 2008 à 14:25 (UTC)

Pas du tout, cela ne fait que rediriger le visiteur vers une autre page, mais c'est sans effet sur les pages qui y restent référencées (ou qui peuvent continuer à s'y ajouter). C'est pour ça qu'on ne devrait PAS faire de redirection sur une catégorie, mais y poser une bannière mentionnant la nouvelle adresse (et autodétectant et catalogant les catégories "redirigées" non vides dans une catégorie spéciale de maintenance) comme sur Commons. Voir Commons:Template:Category redirect un exemple de bannière (il me semble qu'il y en a une similaire dans la Wikipédia francophone). verdy_p 6 novembre 2008 à 14:30 (UTC)

Pour ma part, je pense sincèrement que certains noms de langues rares (pour lesquelles il n'y a pas d'usage significatif en français), le nom issu d'une recommandation officielle ou à défaut le nom français publié dans les listes officielles de l'ISO 639-2 devrait être utilisé (c'est la règle de moindre surprise, ce qui permet d'aligner les codes et noms du Wiktionnaire avec les recommandations officielles et faire de Wiktionnaire une implémentation conforme de la norme ISO 639, sachant que bien d'autres sites ou logiciels vont s'appuyer sur les solutions adoptées dans les grands projets de Wikimedia pour leur propre localisation). Ces codes ISO 639 correspondent aussi aux codes à utiliser dans les pages web ou XML pour le marquage de langue, et sont ceux permettant d'activer corerctement la prise en compte de polices de caractères adaptées à la langue. Ces codes servent aussi à une meilleure indexation pour les moteurs de recherche, raison de plus pour respecter le plus possible la norme ISO 639 (d'autant que pour nombre de ces langues rares, les Wiktionnaires de Wikimedia seront les principales références disponibles sur le web, et serviront aussi comme base de test pour leur support dans les navigateurs, et la création de "locales" pour l'internationalisation de logiciels et de sites.)

Note: pour l'instant l'ISO 639-3 ne publie pas de recommandations pour les noms français pour les langues ou macrolangues rares qui n'ont pas de code ISO 639-2, ce qui fait que de tels noms ne sont pas forcément définitifs (cela demandera de la recherche pour pouvoir les changer si une recommandation terminologique ou orthographique apparaît plus tard).

verdy_p 5 novembre 2008 à 08:32 (UTC)

Pause ?

Je pense qu'il serait sage que tu ne continues pas à modifier les modèles et catégories dont il est question avant qu'on n'ait atteint un consensus. Même si ce n'est certainement pas ton intention, ça donne l'impression que tu veux imposer ton point de vue... Quand bien même tu aurais raison (je n'ai moi-même pas encore d'avis tranché sur la question), ça permettrait d'éviter que les choses ne s'enveniment. À bon entendeur ;) - Dakdada (discuter) 6 novembre 2008 à 15:46 (UTC)

Je ne modifie plus aucun nom; quant au travail déjà fait, il concerne la quasi totalité des langues usuelles de l'ISO 639-2 et ISO 639-1 (je n'ai pas encore tellement touché aux langues de l'ISO 639-3). Cette base de travail fournit pas mal d'infos qui devrait aider à résoudre des conflits de noms, et évitera d'autres erreurs de nommage, tout en facilitant l'automatisation des créations de catégories (sans faire d'erreur si possible)

Le but du jeu est bien de regrouper les différentes listes et pouvoir les gérer de façon centralisée et cohérente.

A ce sujet, j'ai créé le bandeau {{catégorie redirigée}}, alias {{Category redirect}} comme sur Commons (c'est pour répondre au fait qu'on m'a dit que les redirections marchaient sur les catégories alors qu'elles sont inefficaces). Il serait à placer dans les catégories non catégorisées qui sont restées après des redirections "sauvages", et qui peuvent encore lister pas mal de pages qui seront à recatégoriser. verdy_p 6 novembre 2008 à 15:52 (UTC)

Merci de revenir à yiddish. Vouloir imposer son point de vue personnel contre l'avis de tous les autres, j'appelle ça du vandalisme. Faut-il un blocage pour que tu comprennes ? Lmaltier 7 novembre 2008 à 17:59 (UTC)

Je n'ai rien changé ! J'ai annoté la redirection au lieu de laisser la page vide, c'est tout ! verdy_p 7 novembre 2008 à 18:00 (UTC)

Je répète : merci de revenir à yiddish, et d'arrêter de te moquer des autres. Lmaltier 7 novembre 2008 à 18:08 (UTC)

Je tiens à noter aussi que concernant les articles en yiddish/yidiche, il n'y a pas de modification véritable, seul le nom en dur des catégories citées utilise le modèle. Car on peut s'attendre à des changements encore et il vaut mieux qu'il suivent tout changement de nom pour qu'ils se retrouvent dans la bonne catégorie. Ce n'est que du nettoyage qui ne préjuge pas du résultat des discussions sur le nom à choisir.

Du calme donc ! Je n'ai agressé ni me me suis moqué de personne. Je ne vois pas ce que tu me demandes si ce que tu écrits est un ordre. Pour revenir à yiddish il n'y a QU'UN modèle à éditer, et inverser les catégories (c'est déjà gardé dans les historiques où tout est prêt aussi). Mais il est étrange que quelqu'un vienne ordonner à quelqu'un de faire quelquechose alors que justement c'était en discussion. verdy_p 7 novembre 2008 à 18:15 (UTC)

Ce que je veux dire, c'est que si tu me demandes de faire une modif, fais le calmement et clairement (ton message ici ou ton ordre n'est pas clair d tout sur ce que tu veux vraiment). verdy_p 7 novembre 2008 à 18:16 (UTC)

masaï

Masaï n'est pas une faute d'orthographe ! Stop ! Lmaltier 6 novembre 2008 à 06:48 (UTC)

Le nom usuel (et très connu) est massaï, et c'est aussi le nom enregistré à l'ISO (639-1 et 639-2, listes françaises de noms), et le mot présent dans mes dicos, ainsi que partout sur le web.

Le mot "masai" (sans tréma) est l'orthographe anglaise.

Le mot en français prend deux s surtout si on l'écrit avec un tréma pour montrer que c'est l'orthographe française! Même le Wiktionnaire mentionne "massaï" avec deux s et pas un seul. De même pour Wikipédia.

verdy_p 6 novembre 2008 à 07:31 (UTC)

Wikipédia mentionne massaï, mais privilégie masaï. Mes dictionnaires, eux, mentionnent aussi massaï, mais privilégient masai (sans tréma). C'est normal de mentionner massaï dans le Wiktionnaire : on mentionne tous les mots, avec toutes leurs orthographes possibles quand il y en a plusieurs. En fait, les trois orthographes sont fréquemment utilisées, mais la moins courante est massaï. Lmaltier 6 novembre 2008 à 07:46 (UTC)

C'est le contraire: massaï avec deux s est de loin la plus courante, suivi de masai (sans tréma). Je ne sais pas où tu as été inventer masaï avec un seul s et un tréma. verdy_p 6 novembre 2008 à 07:47 (UTC)

Je ne l'ai pas inventé. Et vouloir changer une orthographe de langue maintenant, alors qu'il y a une discussion en cours dans la Wikidémie, c'est de la provocation. Lmaltier 6 novembre 2008 à 07:54 (UTC)

Mon Encyclopedia universalis (édition papier 1992) utilise Masaï pour le nom du peuple. Le Larousse du XXe siècle (du début) indique les deux orthographes Masaï et Massaï. Cette orthographe à 1 s n'est donc pas nouvelle. Ce serait bien de citer des sources pour ce genre de débat... et surtout d'en discuter avant d'entrer dans des conflits inutiles. - Dakdada (discuter) 6 novembre 2008 à 08:33 (UTC)

L'Enc.Un. est bien la seule à encore utiliser cette orthographe. Il y a de nombreux livres en rançais et de nombreuses associations humanitaires françaises qui utilisent depuis très longtemps l'orthographe avec deux s. L'orthographe avec un s est une incongruité, un import maladroit de l'anglais (d'ailleurs ce n'est pas du tout le nom utilisé en massaï et ses dialectes. Ca fait longtemps qu'on écrit avec deux s, et c'est entériné dans ISO 639-1 et ISO 639-2 depuis longtemps (également dans les listes de grandes universités de langues en France, au Canada et dans les unités de recherche francophones, qui ne citent même pas "masaï" mais seulement "massaï" et "masai" en tant qu'orthographe anglaise effective). Ceci dit je ne voulais pas nuire, je pensais sincèrement qu'il y avait une faute d'orthographe au vu des sources que j'avais regardées. OK on peut laisser masaï, mais il n'est pas inutile de mentionner l'autre orthographe retenue dans nombre de sources officielles, universitaires et scientifiques. verdy_p 6 novembre 2008 à 08:39 (UTC)

Si j'utilise Google Livres (ouvrages de littérature donc source sérieuse), en le considérant comme l'échantillon représentatif d'un sondage, les usages d'un mot étant équitablement établis dans le temps avec des fréquences liées aux périodes, et si je cherche avec le radical "les" pour distinguer les mots français

et si j'applique cette méthodologie béotienne au litige Masai/Massai, je trouve quoi ? Eh, bien

avec la recherche "les masai" 434 pages

avec la recherche "les masais" 30 pages

avec la recherche "les massai" 587 pages

avec la recherche "les massais" 238 pages

soit, avec l"écriture masai/masais 464 pages et avec l'écriture massai/massais 825 pages.

Conclusion béotienne, Massai l'emporte par KO au premier round ;-)

-Béotien lambda 6 novembre 2008 à 11:54 (UTC)

Justement c'est bien pour ça que j'avais voulu mettre deux 's', toutefois en mettant le tréma (tu n'as pas fait ce test). verdy_p 6 novembre 2008 à 11:56 (UTC)

Par contre avec le tréma (je croyais que Google ne reconnaissait pas !? ) on trouve

avec la recherche "les Masaï" 583 pages

avec la recherche "les Masaïs" 128 pages Note : Google Livres dit « Essayez avec cette orthographe : "les Massaïs" »; Est-ce que ce serait une indication qualitative, Massaïs valant mieux que Masaïs ?

avec la recherche "les Massaï" 196 pages

avec la recherche "les Massaïs" 101pages

À toutes fins utiles -Béotien lambda 6 novembre 2008 à 12:22 (UTC)

Résumons (laissons de côté l'accord du pluriel et la capitale pour l'instant):

• "les masai" + "les masais" = 474 pages pour "masai"
• "les Massaï" + "les Massaïs" = 297 pages pour "massaï"
• "les massai" + "les massais" = 825 pages pour "massai"
• "les Masaï" + "les Masaïs" = 711 pages pour "masaï"

S'agissant de savoir s'il y a un ou deux s:

• "les massai" + "les massais" + "les Massaï" + "les Massaïs" = 1122 pages pour deux s
• "les masai" + "les masais" + "les Masaï" + "les Masaïs" = 1185 pages pour un seul s
• On ne peut pas conclure, la différence est trop faible... Ce qui me fait pencher donc vers la préférence donnée par l'ISO 639 (donc deux s).

S'agissant de savoir s'il faut ou non un tréma:

• "les masai" + "les masais" + "les massai" + "les massais" = 1289 pages sans le tréma
• "les Masaï" + "les Masaïs" + "les Massaï" + "les Massaïs" = 1008 pages avec le tréma
• On ne peut pas conclure non plus, la différence est trop faible, cependant le score est biaisé car les noms sans tréma sont sans capitale, alors qu'à l'évidence il en faudrait une après "les"... Si j'en viens aux correcteurs orthographiques (et la suggestion faite par Google...), et les règles orthographiques françaises sur l'usage requis du tréma pour marquer la diérèse (et éviter la prononciation fautive du digramme ai), ils mettent un tréma, et l'ISO 639 aussi, donc je penche pour le tréma là encore...

Résultat du match, j'avais bien raison pour "massaï"... S'agissant de savoir s'il faut marquer le pluriel, la francisation "massaï" avec le tréma l'impose pour marquer l'accord des adjectifs en "-aï" (comme dans "thaï" -> "thaïe", "thaïs", "thaïes"). Google aussi aurait raison dans sa suggestion.

Méfiance quand même : de nombreux livres sont issus de traductions de publications en anglais, et les traducteurs anglais-français ne sont pas toujours champions de l'orthographe ou tiennent à conserver assez arbitrairement l'orthographe d'origine donnée en anglais (surtout si le livre contient un index terminologique que les traducteurs ont de la peine à traduire corerctement sans outil pour les références, ou si le traducteur est lui-même natif anglophone). D'autant qu'il n'est pas exclus que ces livres contiennent des citations en anglais (dans le corps du texte ou en note de bas de page, ou dans la citation d'autres noms d’œuvres publiées en anglais). Il faudrait donc vérifier si le livre est un original en français ou une traduction, et exclure les citations et notes bibliographiques sans indication de leur langue...

verdy_p 6 novembre 2008 à 12:36 (UTC)

Bonjour, Pour info : "je les massais" (17 occurences dans Google livres). Je replace ici le fruit de mes courtes recherches de ce matin (depuis la PdD de Lmaltier) :

Google francophone : "langue maa" > "langue masaï" = "langue massaï"

Google livres : "langue maa" > "langue masaï" > "langue massaï"

Google francophone : masaï > massaï (maa impossible à déterminer)

Google livres : masaï > massaï (maa impossible à déterminer)

Wikipédia : masaï > massaï idem avec "le masaï" > "le massaï"

TLFi : ne connait que les Massaï et pas leur langue

Reverso ne connait que le masaï et le maa

Larousse connait la girafe masaï et le barbican masaï mais aussi le lion des Massaï (rien sur la langue ?!?)

Encarta parle du « maa parlé par les Massaï. »

Rien sur GDT, Littré, Académie fr, ... Rien sur le dernier Larousse ni sur le Petit Robert 2009.

La question serait donc davantage « Doit-on parlé du maa ou du masaï ? ».

En fait, compte tenu des chiffres très proches, de la neutralité de point de vue, de la concision de ces noms, le mieux serait d'indiquer dans les modèles : {{=mas=}} et {{mas}} quelque chose comme : « maa, masaï ou massaï ». C'est un développement intéressant au vote lancé par Lmaltier. Stéphane8888 discuter 6 novembre 2008 à 12:58 (UTC)

Condidérez que je n'ai rien dit, ma démonstration n'est pas probante. Autant pour moi. -Béotien lambda 6 novembre 2008 à 13:28 (UTC)

Pour info, les modèles de langues peuvent contenir maintenant des infos au sujet des autres noms et orthographes, ainsi que les noms français et anglais retenus dans la norme ISO 639, et les notes additionnelles regarde par exemple {{mas}} et {{ie}}. (note: cela n'alourdit pas les pages en terme de nombre de modèles inclus et ces infos sont très courtes, les pages d'aide des modèle ne sont pas stockées individuellement mais générées par un même modèle à l'aide des informations contenues dans les sous-modèles xx/type de chaque modèle de code langue.

Toutes les langues de l'ISO 639-1 ainsi que la plupart des langues de l'ISO 639-2 sont déjà codifiées, certaines langues de l'ISO 639-3 sont encore à faire, mais je ne vais pas ajouter toutes ces langues sauf si un modèle existe déjà).

Ces infos ne sont pas terminées, j'ai commencé par l'ISO 639-1 (il faut que je corrige au moins les noms anglais s'ils sont différents du nom français, et ajouter les autres noms de l'ISO).

Peut-être faudra-t-il ajouter d'autres infos comme la correspondance avec un code wiki s'il n'est pas identique au code langue ou si un même wiki gère plusieurs langues et variantes.

Avec ça on devrait être capable de faire tous les modèles qu'on veut, et citer les noms possibles en fonction du contexte, et générer différentes listes de contrôle en fonction de ce qu'on veut afficher, sans avoir à rééditer plein de pages. verdy_p 6 novembre 2008 à 13:31 (UTC)

Je viens de découvrir tout ça. C'est impressionnant, et un peu au dessus de mes capacités : j'avoue ne pas encore me représenter ce qu'on peut en faire. Le féminin, par exemple, ça servirait à quoi? Et comment l'utiliser ? Stéphane8888 discuter 6 novembre 2008 à 14:26 (UTC)

par exemple : "orthographe française" est mieux et moins lourd que "orthographe en français". Dans le premier cas c'est un adjectif qui s'accorde, dans l'autre c'est un groupe nominal utilisé comme complément et lié par une préposition. La forme "(adjectif de langue)", qui doit s'accorder en genre et en nombre est préférable chaque fois que possible à la forme "en (nom de langue)" quand c'est possible. Cependant pour les langues ayant des noms composés de plusieurs mots sans trait d'union il vaut mieux utiliser "en (nom de langue)" pour éviter l'ambigüité...

exemples pour citer la même expression en rapport à diverses langues :

• orthographe {{fr|type=fs}} donne "orthographe français" ; comparer à {{fr}} qui donne "français"
• orthographe {{it|type=fs}} donne "orthographe italien" ; comparer à {{it}} qui donne "italien"
• orthographe {{ga|type=fs}} donne "orthographe gaélique irlandais" ; comparer à {{ga}} qui donne "gaélique irlandais"
• orthographe {{enm|type=fs}} donne "orthographe moyen anglais" ; comparer à {{enm}} qui donne "moyen anglais"
• orthographe {{cs|type=fs}} donne "orthographe tchèque" ; comparer à {{cs}} qui donne "tchèque"
• orthographe {{el|type=fs}} donne "orthographe grec" ; comparer à {{el}} qui donne "grec"
• orthographe {{ug|type=fs}} donne "orthographe ouïghour" ; comparer à {{ug}} qui donne "ouïghour"
• expressions {{es|type=fp}} donne "expressions espagnol" ; comparer à {{es}} qui donne "espagnol"

Ceci dit, pour l'instant c'est très peu utilisé. En revanche pouvoir mettre des articles correctement, et correctement mettre la capitale d'un titre directement à partir du modèle, c'est possible. Ça demande assez peu de paramétrage... verdy_p 6 novembre 2008 à 14:53 (UTC)

Merci pour tes explications ! J'ai tout compris. Stéphane8888 discuter 6 novembre 2008 à 20:52 (UTC)

Attention, tous les modèles ne snot pas encore prêts à accepter le paramètre optionnel. Ce qui est complet c'est la liste des langues ISO 639-1 (voir à ce sujet Wiktionnaire:ISO 639-1 qui est renseignée entièrement avec les modèles de langue, je ferai la page sur ISO 639-2 une fois cette liste complète, puis je ferai l'ISO 639-3, sans toutefois mettre tous les codes langues, il y en a trop, mais ceux utilisés dans le Wiktionnaire), et la plus grande partie des langues ISO 639-2 (regarde Wiktionnaire:Vérification des modèles pour les langues qui est ma page de travail encore incomplète). Seules quelques langues de la liste ISO 639-3 sont faites (en fonction des découvertes), et je ne suis pas sûr que toutes sont référencées (il faudra que je regarde une autre catégorie pour savoir s'il en reste). Environ 350 langues sont déjà paramétrées, il y en a environ 640, donc ça demande encore du travail... verdy_p 6 novembre 2008 à 21:19 (UTC)

Mes vieux dictionnaires encyclopédiques des années 50 à 70 ne mentionnent que massaï. Il est très clair que la forme sans tréma est une erreur. Quant à la forme masaï, sa prononciation serait normalement /ma.zaj/ (suffit de regarder anasarque, baser/caser/jaser/raser, casanier, casaque, hasard, lasagne, nasal, vase, etc. —en fait, le seul exemple en /s/ que je puisse trouver est scramasaxe) donc je crois bien que ce devrait être considéré une erreur. Urhixidur 6 novembre 2008 à 14:43 (UTC)

(Parenthèse : en fait il y en a un bon nombre : asexuel, intersection, etc. la plupart des cas sont du type préfixe- + mot commençant par s. Par contre, s'il s'agit de mots empruntés à d'autres langues, ça dépend (cf miso). - Dakdada (discuter) 6 novembre 2008 à 15:03 (UTC))

Parenthèse : intersection s'écrit et se lit sans difficulté: un 's' ne se prononce normalement /z/ qu'entre deux voyelles (a-a: rasage, a-e: raseur, a-i: Asie, a-o: rasons, a-u: masure, e-a: résa, e-e: diérèse, e-i: désir, e-o: trésor, e-u: présure, i-a: visage, i-e: viseur, i-i: loisir, vision, i-o: vison, i-u: brisure, o-a: osage, o-e: osez, o-i: rosir, o-o: osons, o-u: Josué, u-a: usage, u-e: rusé, u-i: musique, u-o: rusons, u-u: cousu, ...), ce qui n'est pas le cas ici car il y a une consonne r avant le s. Ceci dit je suis d'accord avec toi sur le cas d'un s entre deux voyelles qui peut parfois se prononcer 's' mais c'est uniquement entre deux racines ou entre une racine et un préfixe. Pour les mots empruntés à d'autres langues, c'est vrai aussi à condition d'en conserver l'orthographe. Dès qu'on commence à franciser en modifiant certaines lettres (mettre un tréma ici pour marquer la prononciation correcte), l'orthographe française s'applique et donc le s doit être doublé (égalment ici pour marquer la prononciation): "masaï" est batard, mal francisé de l'anglais, alors que "masai" (non retouché) serait correct. verdy_p 6 novembre 2008 à 22:20 (UTC)

Comme quoi c'est l'usage moderne et l'abus d'Internet en reprenant des sources anglaises qui a déformé l'orthographe usuelle. On ne peut pas se fier à une recherche Google pour établir une norme, surtout quand les erreurs proviennent essentiellement de la méconnaissance du sujet par leurs auteurs, ou quand simplement les langues utilisées dans les pages ne sont pas clairement identifiées pour savoir quelle est la forme d'un mot utilisé. La seule méthode reste alors les sources officielles, et les bons vieux dicos (bien sûr si cet usage se prolonge, cela modifiera l'usage en français, mais c'est dommage d'oublier un terme française qui s'écrit, se lit et s'accorde normalement contre une aberration orthographique venue d'on ne sait où et qui introduit des difficultés grammaticales et de lecture). Comme le Wiktionnaire se veut pédagogique et didactique pour la langue française, il faudrait montrer d'abord la forme première (quitte à citer les orthographes alternatives souvent rencontrées). Sinon on va remplir le wiktionnaire d'anglicismes peu justifiés. verdy_p 6 novembre 2008 à 14:53 (UTC)

On a le droit d'avoir des opinions personnelles, mais elles ne doivent pas influencer le contenu (neutralité). De toutes façons, d'après ce que je comprends, on va probablement remplacer masaï par maa. Comme quoi il ne faut pas modifier ce genre de modèle important unilatéralement, sans en parler. C'est de la discussion que jaillit la lumière. Lmaltier 6 novembre 2008 à 22:34 (UTC)

s prononcé /s/ ou /z/ en français

Ce que tu as raté dans « en fait il y en a un bon nombre : asexuel, intersection, etc. », c’est qu’en français la prononciation des consonnes à deux sons (c, g, s) dépend de la voyelle qui suit. Je persiste : en français, la forme « *sa » se prononce /*za/ sauf rarissime exception.

rares exceptions? non, "persan": /s/ et pas /z/. Voir ci-dessous... verdy_p 7 novembre 2008 à 19:41 (UTC)

Comme je l’ai déjà mentionné, les sources « avec séniorité » s’accordent pour donner la graphie française comme massaï, la forme masaï étant de toute évidence un emprunt à l’anglais. Adopter le nom maa à la place a le double avantage d’escamoter le problème et de correspondre au nom que les Massaï donnent eux-mêmes à leur langue. Quand passe-t-on au vote ? Urhixidur 7 novembre 2008 à 18:55 (UTC)

Visiblement je ne te comprend pas ou tu t'exprimes mal. Pour moi cela ne dépend pas du tout de la voyelle qui suit. N'importe quelle voyelle sui suit peut provoquer un son /s/ ou /z/. Ce qui compte c'est si le s est précédé ou non d'une voyelle (n'importe laquelle, relis mes exemples), et précédé ou non d'une voyelle (n'importe laquelle aussi, même un y ou avec un accent ou partie d'un digramme/trigramme vocalique comme 'au', 'an', 'ai', 'ain'...). L'exception est la voyelle 'o' quand elle a a valeur de semi-voyelle/semi-consonne /w/ dans les digramme/trigrammes 'oi' et 'oin' (/wa/ et /wɛ̃/), pourtant on a "rasoir" opposé à "rasseoire" (ou "rassoire" en orthographe réformée).

Les exceptions viennent des préfixes terminés par une voyelle (a-, re-, ré-, dé-, anti-, supra-, infra-, etc.) accolés à un radical commençant par un 's' et n'importe quelle voyelle (donc commençant par sa-, sai-, san-, sau-, se-, sei-, sen-, seu-, si-, sin-, so-, soi-, soin-, son-, su-, sun-, etc.) ce radical ne change (normalement) pas sa prononciation ni (la plupart du temps) son orthographe (le s est rarement doublé dans ce cas, mais ça arrive pour des termes d'usage courant comme asseoire de "a-" et "seoire"). Par exemple, déservir (dé- et servir) : parfois le s est doublé et le préfixe est alors transformé et assimilé pour former un nouveau mot (desservir), en revanche "reservir" (le s n'est pas doublé):

Quand le s est doublé, le préfixe disparait presque graphiquement et parfois aussi phonétiquement mais subsiste étymologiquement; ce cas ne se présente que pour des mots attestés par l'usage depuis longtemps et qui ont acquis un sens propre différent de la seule juxtaposition des sens séparés du préfixe et du radical.

Ainsi pour les préfixes de répétition re-, ré-, ou les préfixes longs comme anti-, infra- ou supra-, ou les préfixes de multiples ou sous-multiples comme bi-, tri-, semi-, déci-, centi-, milli-, micro-, etc., il est rare que cela crée un sens distinct de la seule juxtaposition : on les écrivait avant avec un trait d'union, sans doubler le s pour conserver la prononciation du radical, ce trait d'union a seulement disparu, mais le s non redoublé du radical se prononce toujours /s/ et non /z/ (ça restera le cas jusqu'à un prochain changement d'orthographe suite à un usage qui accentuera le doublement du s puisque le trait d'union a disparu).

L'exception du préfixe a- pose un problème orthographique: il tend naturellement à doubler la consonne initiale s, c ou g du radical qui suit. Les évolutions orthographiques tendent à doubler le s et "assexuel" n'est plus considéré fautif (nouvelle orthographe) car plus naturel avec la règle des deux voyelles. Le cas de "miso" est une exception conservé car c'est un radical importé tel quel et non francisé.

En revanche, dans un même radical français, TOUTES les suites voyelle+s+voyelle se prononcent /z/ et non /s/. Les exceptions sont toutes des imports de radicaux d'une langue étrangère, dans leur graphie d'origine, mais toute francisation (ne serait-ce qu'un tréma ou un accent) impose de doubler les s des radicaux francisés qui doivent se prononcer /s/ et non /z/. verdy_p 7 novembre 2008 à 19:18 (UTC)

Pour te donner partiellement raison, il faut noter "tsar" où le s se prononce /z/, c'est en fait un faux 's' car il y a en fait un digramme consonnantique 'ts' formant un seul phonème affriqué au sein d'un même radical; mais pour te contredire, penser, pansement, absoudre, absolu : il y a une consonne avant le s, car 'ns' ou 'bs' ne forment pas un digramme d'un seul phonème affriqué et donc ce s se prononce /s/ dans tous ces cas... Mais ta remarque ne concerne pas du tout le cas du 's' entre deux voyelles, tu ne parles pas de la même chose avec '*sa'... ton étoile signifie "une consonnne afriquable" (et donc pas un p : psi, psy, psa). A vrai dire ce cas doit se limiter à ts+voyelle... comme dans "tsar" ou "tsigane" (/tz/), mais encore: "tsé-tsé" (/ts/). Cela ne concerne de toute façon pas le doublement ou non du s ou la prononciation du s entre deux voyelles comme ici. verdy_p 7 novembre 2008 à 19:25 (UTC)

Non, par "*sa" je voulais dire "une voyelle (ou groupe voyelle) quelconque puis s, puis a". J’aurais dû préciser, désolé de la confusion. De toutes façons, tu es d’accord (je cite : « En revanche, dans un même radical français, TOUTES les suites voyelle+s+voyelle se prononcent /z/ et non /s/. ».  :-) Urhixidur 12 novembre 2008 à 15:18 (UTC)

Précisions : « assexuel » et « rassoire » ne font pas partie de la réforme de 1990 (mais on a « rassoir » pour rasseoir → voir Annexe:Rectifications orthographiques françaises_de_1990. Urhixidur 12 novembre 2008 à 15:31 (UTC)

Berbère

Au contraire, rien de plus sujet au vandalisme que le berbère (guerre d'Algérie et Pieds noirs obligent) sur un wiki francophone. Ceci dit, tu as raison, bloquer le modèle {ber} était sans doute un peu rapide (je donne mon opinion, je ne me substitue pas à Stephane8888‎). --Szyx 6 novembre 2008 à 21:43 (UTC)

Alors que dire de l'allemand, de l'hébreu, de l'arabe, du chinois, du tibétain, et même du français pour certains dans le monde (sans compter que le français n'est pas protégé alors qu'il est utilisé presque partout ici sur des dizaines de milliers de références, peut-être même plus si on compte aussi les pages projets et discussions). Si une langue doit être protégée ici c'est bien le français. verdy_p 6 novembre 2008 à 21:53 (UTC)

Ceci dit ce n'est pas la guerre d'Algérie ou les Pieds Noirs qui posent problème. Il y a très peu de conflit aujourd'hui entre Pieds Noirs et Algériens qui se respectent. C'est plutôt le conflit entre Berbères et Arabes au sujet de leur culture en Algérie et l'imposition de la langue arabe au détriment des langues tamasheqs... Ceci dit, ici on ne les a pas encore vus, et ce n'est pas le sujet de nos articles ici qui va les faire se déchirer sur des définitions de termes (du moins tant qu'on ne rentre pas dans la définitions des toponymes de pays, villes, régions, gentilés et noms de peuples, cultures, et mots à usage politique ou religieux, ou à caractère plus ou moins érotique ou pornographique, ou encore relatifs aux minorités de genre...) verdy_p 6 novembre 2008 à 21:57 (UTC)

Je m'appuie seulement sur les faits (je parle des wikis, pas de politique), w:France et w:Algérie sont sans doute les deux pages articles les plus vandalisées de Wikipédia, et w:Berbères doit tenir sont rang (11 révocations dans les 50 dernières modifications en ce moment [2]). --Szyx 6 novembre 2008 à 22:01 (UTC)

Oui mais ces disputes sont souvent des questions liées à la façon d'exposer l'histoire (qui est un sujet toujours délicat dans toutes les langues et cultures; ici dans le Wiktionnaire on évite de relater des faits historiques on se contente de mettre en rapport des termes les uns avec les autres pour leur donner un sens un peu cohérent, sans limiter le nombre des usages; ici je n'ai pas encore vu de dispute sérieuse dans un article, hormi sur des questions de présentation ou de catégorisation, ou de conception de modèles non liés au contenu). verdy_p 6 novembre 2008 à 22:25 (UTC)

Heureusement. Mais je ne serais pas outre mesure surpris de voir un contributeur débarquer pour remplacer toutes les occurrences de berbère par tamazight, sous prétexte que c'est le « vrai » mot... --Szyx 6 novembre 2008 à 22:36 (UTC)

Je viens seulement de découvrir ton message... Grondin a déjà modifié les niveaux de protection qu'il avait mis. A+ Stéphane8888 discuter 7 novembre 2008 à 08:42 (UTC)

Noms ISO

Je vois que tu continues à modifier ce qui concerne les codes langues, sans qu'il ait eu de décision collective. Il va falloir lancer la discussion générale. Je veux juste dire que l'ISO ne normalise pas les noms des langues, seulement les codes, et que la notion de nom ISO n'a donc pas beaucoup de sens. Lmaltier 7 novembre 2008 à 07:17 (UTC)

Je ne modifie AUCUN nom, j'apporte des infos (hors du nom utilisé sur le Wiktionnaire) permettant de comparer les sources, c'est TRES différent. Je travaille donc hors du champ de discussions car cela ne change strictement rien à l'usage actuel des codes. verdy_p 7 novembre 2008 à 07:21 (UTC)

Oui je crois comprendre que tu ajoutes des informations aux modèles de langues (Modèle:xxx/type). Ces informations peuvent être appelées par la suite. La référence aux codes ISO permettra de référencer (justement) les langues du Wiktionnaire, car l'intitulé que la communauté du Wiktionnaire aura choisi peut être différent de celui de l'ISO. Il importe en effet de bien savoir de quelle langue on parle, indépendamment du nom qu'on lui donne. Il est certain que des discussions auront lieu afin de choisir l'intitulé (ou les intitulés juxtaposés) de ces langues. Ce qui nous effraie avec toi, Verdy_p, c'est que tu as un niveau technique très poussé et qu'on est vite largué alors qu'on se devrait au contraire de tout maitriser. J'ai constaté qu'hier tu as fais preuve (patiemment) de pédagogie. Le mieux serait sans doute la prochaine fois d'expliquer avant plutôt qu'après. Stéphane8888 discuter 7 novembre 2008 à 08:39 (UTC)

Cependant dans le cadre de ladiscussion en cours, j'ai expliqué jsutement ce que je faisais, et j'ai donné des exemples et motnré l'intérêt: celui d'identifier d'abord avec précision les langues (pour lever les ambiguïtés), puis savoir les reconnaitre par leur noms (l'ISO en normalise plusieurs mais justement ne les normalise pas tous car certains noms prétendus "synonymes" sont en fait ambigus et désignent plusieurs langues parfois même pas dans le même groupe). La source ISO est donc d'importance pour reconnaître les noms importants et non ambigus, même si ensuite on décide d'en choisir un.

On m'a dit que l'ISO ne normalisait pas les noms de langue, c'est entièrement faux! Il normalise les noms français et anglais destinés à l'identification précise des langues et les associer sans ambiguïté à un seul code, puis à regrouper ces codes de langues par macrolangues (dans ISO 639-3 uniquement) puis en familles collectives (pour l'instant uniquement dans ISO 639-2 mais de façon très partielle). Hors justement ici, on a besion dans le wiktionnaire d'identifiants de langues précis (non ambigus). Cette source d'information ISO est donc pertinente !

ISO 639-4 est en préparation pour normaliser la classification (partielle et mal définie dans ISO 639-2) et attribuer de nouveaux codes collectifs à ces familles, et codifier leur structure hiérarchique comme le fait pour l'instant SIL (déjà en charge de l'ISO 639-3), qui publie cette classification (non codifiée) mais qui fait déjà l'objet d'un suivi des demandes de corrections, ajouts, reclassements, etc. en collaboration avec les grandes bibliothèques publiques et les bibliophiles et experts linguistes du monde entier.

verdy_p 7 novembre 2008 à 09:03 (UTC)

Toutes les sources indiquent qu'ISO-639 normalise des codes pour les langues. Le nom officiel de la norme est : Codes pour la représentation des noms de langue... Evidemment, elle doit bien citer des noms en clair pour dire à quelles langues correspondent les codes. Mais ce ne sont pas ces noms qui sont normalisés. Et de façon générale, les langues non artificielles ne peuvent pas être normalisées. C'est ce qui fait l'intérêt de la norme : avoir une représentation standard, qui permet de repérer une langue sans dépendre de la langue utilisée et sans être perturbés par les nombreux noms (synonymes) souvent donnés aux langues. Lmaltier 7 novembre 2008 à 09:28 (UTC)

Tu ne comprends pas ce que je veux dire. Je n'ai pas dit qu'ils normalisent les désignations de ces langues que ce soit en français ou en anglais ou une autre langue (c'est ce que fait en revanche le projet CLDR en cerchant à localiser ces noms dans un référenciel unique; cependant CLDR a d'abord choisi d'utiliser les noms identifiant les langues avant de les corriger en fonction de l'usage, sans toutefois introduire d'ambiguïté: dans chaque locale, les noms doivent rester uniques). Ce que l'ISO 639 normalise ce ce les noms servant à l’identification non ambigüe d'une langue. Ce qui est nécessaire pour pouvoir être certain d'utiliser le bon code. Hors dans nos modèles le nom par défaut ne sert pas à traduire un usage, mais bien à identifier une langue (faute de quoi ils ne seraient plus uniques, et plus utilisables pour nommer de façon non ambigüe des catégories). Aussi les noms par défaut devraient suivre d'abord ce que préconise l'ISO 639 pour le français ou l'anglais, quitte ensuite à les localiser suivant la logique CLDR. Le but ultime étant d'utiliser une localisation unique dans CLDR (malheureusement CLDR est loin d'être achevé, même pour le français, même s'il est à peu prêt fini pour l'anglais, moyennant certaines corrections à faire concernant les mises à jour intervenues dans ISO 639 où certains codes ont été dédoublonnés, fusionnés ou scindés, ou alors renommés avec une précision supplémentaire quand il est apparu une ambiguïté et notamment une homonymie avec d'autres langues ou groupes de langues).

Si l'ISO 639 ne normalisait pas les noms d’identification (je n'ai pas dit qu'il cherchait à les localiser), il n'y aurait pas de correction dans l'ISO 639 justement sur ces noms (même quand le code n'a pas changé). Ces noms publiés par l'ISO 639 servent d'identifiants tout comme les codes normalisés, et servent ensuite de guides pour la localisation dans toutes les langues (qui doivent cependant s'appuyer sur les codets et non sur les noms identifiants car ils peuvent changer tant que cela ne nuit pas à la compatibilité des codes et à l'identification des langues; ces changements de noms identifiants surviennent lorsque de nouvelles langues sont codifiées et font apparaître des homonymies, et sont même historisés. La même chose se passe pour l'ISO 3166-1; avant il se produisait aussi la même chose pour l'ISO 10646 (alias Unicode) jusqu'à ce qu'une politique de stabilité des noms soit adoptée rendant les noms de caractères définitifs comme identifiants, même si ce ne sont pas des noms localisés et même s'ils sont mal nommés. Le but ultime est bien de stabiliser les noms identifiants, pas leur localisation qui évolue au gré des usages constatés ou préférés localement. Mais le but de l'ISO 639 n'est pas de recenser tous les synonymes possibles (c'est du domaine de la localisation) non plus car seule suffit l'identification en français ou en anglais.

Comme les usages en français continuent d'évoluer, il n'y a pas de règle dite de neutralité à observer au sujet des noms "identifiants". Pourtant on a besoin de stabiliser des noms pour les catégories dans le Wiktionnaire, et c'est pourça qu'il nous faut des noms identifiants, et non localisés en français, la question de l'usage est secondaire et ne doit être prise en compte QUE si le changement est justifié par une incompréhension et QUE si ce changement n'introduit AUCUNE ambigüité ou homonymie.

On en revient donc à utiliser l'ISO 639 comme référence indispensable (puisque la norme est développée et maintenue avec les conseils avisés et votes d'experts et de grandes bibliothèques et universités du monde entier qui les utilise directement dans leur propres normes (notamment la norme INMARC), moyennant certaines corrections de l'ISO 639 quand celle-ci définit plusieurs graphies dont certaines simplement inversées avec une virgule, ou annotées avec une mention entre parenthèses telle qu'une indication de date (qui peut être importante à prendre en compte car elle révèle la possibilité d'une ambigüité si on n'en tient pas compte, cependant cette annotation se veut surtout documentaire et n'entre pas en compte dans le champ du nom identifiant, au contraire d'une indication de pays). quand plusieurs noms sont définis dans l'ISO 639, ils restent cependant uniques parmi tous les autres noms de langues: l'ISO 639 ne préconise pas lequel des noms utiliser par défaut, et autorise les localisateurs à en utiliser d'autres (à leurs risques et périls s'ils le font pour des besoin d'identification). L'usage de noms de langues hors du contexte de l'identification parmi une liste de langues possible (par exemple dans le corps du texte) autorise des noms plus courts ou ambigus, si le contexte d'utilisation évite l'ambiguité (par exemple "français" peut être utilisé au lieu de "français canadien" si le contexte précise déjà qu'on parle de la variante canadienne de la langue), mais on devrait éviter d'utiliser ces noms directement issus d'un modèle dont on ne connait pas le contexte d'utilisation.

Je maintiens donc : l’ISO 639 normalise les noms français et anglais utilisés comme identifiants uniques de langues et permettant de sélectionner sans ambigüité le bon code applicable à une langue cherchée. verdy_p 7 novembre 2008 à 11:53 (UTC)

Concernant les accords des adjectifs, ils sont réalisés encore de façon assez sommaire, en utilisant les règles usuelles du français à défaut d'information contraire. Ça peut être retouché sans tout casser car ça n'influe pas le nommage des catégories qui utilisent systématiquement la forme "en (nom de langue)" où le groupe nominal est placé en complément épithète de nom, par une préposition "en" fixe en français (pour l'instant je n'ai pas encore trouvé de nom où cela posait problème nécessitant une exception à ce style, cependant j'ai trouvé quelques langues dont le nom commun est au féminin et n'a aucun moyen d'être remplacé facilement par un nom masculin, et des cas de langues dont le nom commun est toujours au pluriel). D'une façon générale j'essaye d'éviter les accords sur les noms de langues composés sans trait-d'union car souvent l'adjectif inclus dans l'expression nominale ne se rattache plus de façon claire en épithète de l'autre mot de l'expression "adjectivée", mais tous les mots deviennent alors des adjectifs placés séparément en épithète ou attribut d'autres mots inconnus avec lesquels l'expression entière s'accorde. Au lieu de cela la forme adjectivale du nom de langue devient systématiquement "en (nom de langue)" et reste invariable.

En attendant je continue mes vérifications et recherches d'informations. Ces infos ajoutées permettront de changer sereinement les noms tout en permettant d'afficher les infos pertinentes nécessaires pour ceux qui s'attendent à trouver d'autres noms.

La nouvelle page d'aide (incluse dans tous les codes langue, nouvelle version) est utile également pour repérer les liens vers les catégories, et les articles: les liens rouges signalent souvent des articles manquants à créer, les liens de catégories permettent de repérer les principales catégories existantes où à créer. J'ai fait plusieurs tableaux synthétiques à partir des modèles, destinés à comparer avec l'ISO 639, et rechercher une langue connaissant un de ses noms.

Il manque encore certainement plein de synonymes (ou variantes orthographiques) français usuels pour les noms de langue. On peut les mettre dans la valeur "autres nom=" dans les modèles "xx/type", sous la forme d'une liste de noms avec liens séparés par un point-virgule précédé d'une espace. Ma priorité est d'abord de renseigner les noms ISO (et les annoter).

On peut utiliser la valeur "note=" dans les modèles "xx/type" pour annoter les cas où il n'y a pas d'erreur dans la source (je ne sais pas si c'est une faute par exemple quand l'ISO nomme le "tatare de Crimée" sans mettre le e final, je ne juge pas, je cite le nom tel qu'il est mais je met une courte note). On l'utiliser aussi pour mettre une note d'attention à l'utilisation d'un code où la confusion est possible (par exemple interligua/interlingue). Je pense que je vais utiliser le champ note pour annoter aussi les erreurs manifestes des codes actuels : conflits avec d'autres noms, erreur de codification par exemple pour l'algonquin alq (confondu avec les langues algonquiennes alg, par Urhuixidur qui a fait un changement erronné de ce code y compris dans les discussions, et qui a introduit une erreur qui s'est propagée depuis là où il n'y en avait pas à l'origine).

verdy_p 7 novembre 2008 à 09:26 (UTC)

Point d'exclamation

Salut, juste pour te dire que j'ai retiré les points d'exclamation à l'impératif suite à cette discussion (cela peut être rediscuté au besoin ) Je crois que ça a été l'une des premières interventions de notre excellent Zorglub. Stéphane8888 discuter 7 novembre 2008 à 17:35 (UTC)

Ces points d'exclamations étaient déjà (partiellement) présents. Ils rendent le tableau des conjugaisons ainsi que les flexions plus faciles à interpréter (de même qu'on y met les sujets et les "que" du subjonctif). verdy_p 7 novembre 2008 à 17:39 (UTC)

Ah ok. Je ne me souviens plus qui les avais mal retiré (moi très probablement...). J'ai aussi trouvé ce fragment de discussion :

Wiktionnaire:Questions sur les mots/Archive 08 2008#Conjugaison : point d'exclamation au subjonctif -- Réglé

Stéphane8888 discuter

Oui mais dans ton revert, tu n'as pas vu qu'il y en avait déjà 3 (pour les verbes réfléchis, à l'impératif présent uniquement, comme "presse-toi !", " pressons-nous !", "pressez-vous !"). C'est pour ça que j'avais corrigé les oublis pour les autres formes... Je n'étais pas au courant de cette discussion, mais je cherche encore à savoir commet on emploie un impératif sans le point d'exclamation, que ce soit une exclamation ou une injonction... Peut-être pour une liste d'ordres ou une recette de cuisine « Égouttez et pressez le jus d’un citron. Garnissez vos assiettes. » ? verdy_p 7 novembre 2008 à 17:46 (UTC)

Désolé pour ma technique approximative. Sur le fond je ne suis pas un grand spécialiste. Zorglub m'a l'air plus qualifié que moi sur ce sujet. Bescherelle n'en met pas (c'est pas terrible comme argument, je sais). Encore un sujet à débattre. Stéphane8888 discuter 7 novembre 2008 à 18:04 (UTC)

Je vous rappelle à tous deux que chaque modification de {{fr-conj}} met entre 5000 et 10000 pages dans la file d'attente (on peut faire pire : {{fr}}), alors pitié pour les serveurs. --Szyx 7 novembre 2008 à 19:47 (UTC)

C'est pas déjà terminé ? Ça fait plus d'une heure (peut-être deux) que c'est fait et qu'on n'y a pas retouché ! Tu arrives après la bataille ! En ce moment la job queue est tout à fait normale pour un début de soirée (à 2000 pages alors que souvent c'est plutôt 3000 pages).

Note bien que j'ai un oeil constant sur la job queue, et certaines modifs sont laissées en attente quand la job queue dépasse les 5000 pages... verdy_p 7 novembre 2008 à 19:51 (UTC)

yidiche

Bon. Je pense que tu as "juste" appelé le Modèle:yi/type qui, lui, a propagé yidiche. J'ai interverti donc dans Modèle:yi/type les 2 intitulés (dont on discutera tout à loisir ;-) Voir mon message : Discussion Modèle:yi/type. Les modèles Modèle:xxx/type sont très prometteurs, ils permettront de propager d'un coup le résultat de nos discussions. Mais il est aussi important, lors de la création de ces modèles, de laisser l'intitulé actuel de la langue dans Modèle:xxx/type (car cet intitulé a probablement déjà été discuté, ou bien c'est le choix d'un contributeur qui devait avoir ses raisons => en discuter avec lui, ou d'autres). Question : Combien peut-on mettre d'orthographes alternatives dans ce modèle ? Stéphane8888 discuter 7 novembre 2008 à 18:32 (UTC)

OK pour l'inversion, mais il faut prendre garder à changer les accords (même si ce n'est pas grave pour le moment). J'ai fait depuis ton message l'inversion des catégories (une douzaine de paires, pas de quoi surcharger le serveur, en tout cas 1000 fois moins que de changer le modèle principal, en effet le code des catégories n'influe pas sur la job queue car elles ne sont pas utilisées comme modèles). verdy_p 7 novembre 2008 à 20:32 (UTC)

Cela te dirait de respirer un grand coup, et de voir comment tu pourrais faire tout cela sans donner envie à tous les autres de tout plaquer

parce qu'il est tout simplement plus simple de tout abandonner que de se lancer dans des arguties sans espoir ? --Szyx 7 novembre 2008 à 23:17 (UTC)

Qu'est-ce que tu veux dire ? j'ai fait une modif qui a déclenché une tempête que je ne pensais pas si vive, et j'ai déjà abandonné et annulé puisqu'on m'a donné l'ordre de le faire. J'ai annulé ce que j'ai fait (depuis des heures) et on continue à me faire des reproches ? Je ne comprends pas, je croyais le débat clos depuis 17 heures environ. Qui mène donc encore ici « l'argutie » alors qu'on vient encore me relancer à ce sujet. verdy_p 7 novembre 2008 à 23:19 (UTC)

en tout cas le titre de ton message ne respire pas l'envie de clamer les choses. Je te suggère aussi de respirer un grand coup et faire preuve de retenue, car il me semble que tu as raté quelques épisodes. Ce que e vois encore, c'est que dès que vous tombez sur une chose mineure qui ne vous plait pas, vous ne pouvez pas vous empêcher de taper sur un coupable, même quand il s'est arrêté. On n'a pas arrêté de me relancer sur le sujet alors que rien d'autre n'avait bougé, jusqu'à ce que quelqu'un assume sa propre responsabilité pour faire le fameux revert simple à faire car j'avais déjà préparé les choses pour permettre ce revert, dans une grande phase de nettoyage. Pendant que vous discutiez je faisais tout autre chose, mais on n'a même pas regardé ce que je faisais vraiment.

Si on me reproche de ne pas discuter, c'est surtout car je sais que ça n'en finit plus. Franchement si quelquechose ne vous plait pas, assumez vos responsabilités après en avoir discuté (mais ceux qui révertent à tout bout de champ sans chercher à comprendre ce qui a pu justifier une modif (même si vous avez d'autres arguments que vous n'avez pas encore exposés) devraient se retenir: ils donnent tout autant envie de tout plaquer et déclenchent les tempêtes. D'une façon générale j'évite les discussions car ça empire les choses, et ça ne résoud rien. Je préfère trouver d'autres solutions.

Moi qui croyait le Wiktionnaire plus clame que Wikipédia, je vois qu'on y retrouve les mêmes "énervés" qui perdent leur calme et pensent tout de suite aux menaces et parlent déjà de vandalisme sans montrer ce que j'ai bien pu vandaliser ou casser (OK une erreur est possible, ça se corrige, pas de quoi en faire une montagne). Tout ce qui a pu arriver c'est un désaccord, sur un seul terme à un seul endroit. J'ai largement laissé le temps à la discussion, et ne l'ai pas perturbée, jusqu'à ce qu'on vienne me donner un ordre vociférant ici (je n'avais encore jamais vu quelqu'un ordonner à un autre de faire une modif: s'il le voulait vraiement il n'avait qu'à le faire lui-même, et ne pas ensuite venir me reprocher que j'ai fait ce qu'on m'a ordonné). Maintenant vous englobez dans une discussions des actions sur des pages et données qui n'ont rien à voir avec l'objet initial du litige (un seul terme). Il faut peut-être éviter de tout confondre.

Donc je répète, du calme s'il te plait, je ne mords pas moi, et je ne menace personne. verdy_p 7 novembre 2008 à 23:49 (UTC)

Le problème à mon avis est que la forme "yiddish" faisait consensus, qu'il t'a été demandé d'annuler (implicitement, puis explicitement) tes modifs qui avaient imposé "yidiche", et qu'à chaque fois tu as répondu par de très long messages invoquant des trucs ISO difficilement compréhensibles pour le commun des mortels, sans jamais faire les modifs voulues. Il a fallu que Stephane8888 mette les mains dans le cambouis pour tout arranger... Ici, on ne fonctionne pas comme ça en général ; mais j'ai bon espoir qu'à l'avenir ce genre de problème n'arrivera plus, que tu pourras nous faire profiter sereinement de tes compétences techniques. Markadet∇∆∇∆ 8 novembre 2008 à 01:01 (UTC)

On ne m'a pas demandé d'annuler, désolé, ou en tout cas pas clairement du tout ! Puisque une discussion avait été engagée, j'ai vu des avis de plusieurs, mais rien n'indiquait qu'il fallait que j'annule le changement, mais je n'ai pas vu de décision claire. Un seul me l'a demandé mais sous une forme d'ordre (pas clair non plus), en fait j'ai répondu assez clairement que je n'avais rien cassé et qu'il suffisait de toucher à un seul modèle où le nom été référencé pour basculer les articles, et je pensais sincèrement qu'une décision serait venue. Hors Les seuls messages qu'on m'a adressés ici, c'est d'attendre car il y avait une discussion, je n'ai pas vu la décision de cette discussion, je suis donc passé à autre chose et pendant ce temps j'ai vu des messages mentionnant l'intéret de mes modifications ou ajouts en cours...

Bref un seul mot dans un seul modèle qui pose problème, pas de décision claire et des encouragements reçus et de l'intérêt montré dans les discussions de la Wikidémie (ou même ici) pour ce que je faisais, alors qu'il était très simple si une décision claire était prise, de faire ce changement par n'importe qui prenant ses responsabilités au vu du résultat. Mais je n'ai encore jamais vu une décision ou un consensus résulter en un ordre donné à quelqu'un d'effectuer un changement, sans même donner le résultat du "consensus" prétendu ou un lien vers cette décision. Normalement une décision est suivie d'effet directement par les intéressés au changement, sans intervention nécessaire de la personne qui avait fait une autre proposition. On peut lui demander de le faire, on peut lui demander de l'aide ou des explications pour faire le changement : j'ai répondu à chaque demande d'explication sur les aspects techniques. Franchement je ne vois pas où j'ai failli et de qui je me suis moqué comme certain l'a affirmé !

En revanche quand Stephane8888 a décidé de s'y mettre (sans me donner d'ordre) vers 18 heures 30, je lui ai apporté mon aide pour finir le changement. Il a assumé cette décision vers 18 heures 30 et on est venu me relancer ici pendant plus de 6 heures alors que les modifs "demandées" étaient déja faites et que j'avais apporté mon concours à ce changement, en aidant Stephane8888 à finir: c'est vers 20 heures que j'ai apporté cette aide, désolé si je n'étais pas connecté entre temps pour fignoler les derniers détails, mais tout était fait vers 20 heures, et j'ai répondu vers 20 heures 30 quand tout était fait (voir ci-dessus).

Regarde les heures des messages ci-dessus et dans la Wikidémie, tu comprendras que je n'ai pas failli. Regarde les heures des messages de Lmaltier (le principal opposant). Regarde l'heure du premier message de cette section par Szyx (que je n'avais pas encore vu en discuter!), elle vient trois heures après que tout est déjà fait (j'avais arrêté d'argumenter vers 11 heures 30).

verdy_p 8 novembre 2008 à 06:01 (UTC)

Note : concernant masaï ou massaï, je n'ai encore pas vu de consensus, ni de réelle opposition, en fait les arguments sont atténués par ceux-là même qui se posent des questions (les sources sont largement partagées sur la question, la recherche continue). Je n'ai encore pas touché (puisque je sais qu'on m'a demandé d'attendre pour tout changement, ou de signaler les problèmes), et j'ai déjà répondu que je ne toucherai plus les noms actuels dans mes modifs et vérifications de modèles de langue ou ajouts d'informations (que personne ne m'a demandé d'arrêter, bien au contraire) : je signale maintenant les problèmes sur la page de vérification des modèles, plutôt que de faire les changements directement. verdy_p 8 novembre 2008 à 06:40 (UTC)

Encore une fois, tu réponds à côté, par un message extrèmement long. C'est désespérant. Je n'ai pas le temps ni l'envie de reprendre point par point ce que tu as dit... Je retiens qu'il aura fallu attendre une semaine après qu'il t'ait été signalé que "L'orthographe yiddish était tout à fait volontaire, car c'est l'orthographe courante." (message de Lmaltier le 31 octobre 2008 à 06:11) - et encore, attendre n'a pas été suffisant, il a fallu que quelqu'un aille modifier lui-même ce que tu avais fait - une semaine et des dizaines de messages, sans que tu aies l'élégance d'aller faire la modif toi-même (c-à-d revenir à l'état antérieur à ta modification...) Et oui, je sais que tout ceci était déjà terminé quand cette section a été créée, mais ça n'empêche pas qu'on puisse en parler, car tout ceci était assez inquiétant (quand un spécialiste de la technique profite de son avantage pour imposer son avis en restant sourd à ce qui lui est dit, on a le droit d'être inquiet). Markadet∇∆∇∆ 8 novembre 2008 à 15:34 (UTC)

Effet positif d'un week-end prolongé

Verdy_p, mon message était stupide et mal venu, j'ai eu tort de l'écrire. Mes états d'âmes (qui étaient un peu sombres ce soir là, je l'avoue), car il s'agissait essentiellement de mes états d'âme et non de tes contributions, ne devraient pas déborder ici, j'en suis conscient. Mon désir n'est jamais de mettre de l'huile sur le feu, et là je n'ai pas bien pesé les implications : c'est mal .

Après trois jours sans internet, je reviens de meilleur poil, prêt à écouter (lire) tout le monde, toi compris , avec bienveillance j'espère.

Amitiés, sincèrement, tu sais. --Szyx 11 novembre 2008 à 17:48 (UTC)

Merci. Amicalement, verdy_p 11 novembre 2008 à 17:50 (UTC)

Merci pour les précisions apportées

Merci pour les précisions apportées sur les langues. Dans la grande masse de contributions que tu as faites, il y a peut-être des choses que tu amélioreras encore, mais s'il y a éventuellement des imperfections, il ne faut pas que l'arbre cache la forêt du travail que tu as abattu. -Béotien lambda 8 novembre 2008 à 06:45 (UTC)

Salut Verdy p, Même si c'est moi qui t'es reverté sache que j'essaie simplement de trouver l'équilibre entre ta formidable capacité à changer les choses et la perception (forcément limitée) qu'en a chacun des autres contributeurs (pas très nombreux de surcroit...). Ta puissance technique nous fait peur (nous n'avons pas comme sur Wikipédia pléthore de contributeurs très techniques comme toi pour contrebalancer), alors on se braque, ça s'envenime et ça t'oblige à te justifier longuement. Mieux vaudrait donc, pour la prochaine fois, expliquer une fois pour toute, obtenir un accord de principe et contribuer tranquillement. Particulièrement quand ça touche à des modèles de base. J'espère que tu continueras d'apporter ton œil expert (et tes mains expertes) sur ce projet. A+ Stéphane8888 discuter 8 novembre 2008 à 11:29 (UTC)

Arrêt

Salut Verdy p,

tes modifications sur les noms de langues, en particulier le yiddish et le masaï, ainsi que les modèles de langues (très utilisés donc sensibles), ont soulevé de grosses discussions, souvent houleuses, parce que tu effectues des modifications jugées lourdes sans prendre en compte l'avis des autres contributeurs. Ta force de travail est appréciable, mais tu ne dois pas perdre de vue que le Wiktionnaire est un projet collaboratif ou tout le monde ne partage pas forcément tes avis.

Tu as dit plus haut que personne ne t'avais demandé explicitement de suspendre ces activités (ce qui est d'ailleurs faux) : c'est pourquoi je te demande de suspendre dès maintenant les activités en question (autant sur les noms de langues, les catégories reliées et les modèles de langues).

Ceci est un avertissement : si tu persistais à modifier les pages sans qu'un consensus n'ait été atteint auparavant, je me verrais dans l'obligation de sévir (un blocage temporaire n'est pas à exclure). - Dakdada (discuter) 8 novembre 2008 à 18:11 (UTC)

Je te signales que c'était déjà le cas depuis "l'affaire " discutant du nom "yiddish", qui a été réglée. Encore une fois on vient me relancer alors qu'il n'y a plus rien dans ce que je faisais qui contrevenait à ça: je n'ai PAS modifié d'autres noms que yiddish->yidiche, ni masaï->massaï. Quant aux catégories elles n'ont pas bougé hors de celles du yidiche que j'ai restaurées déjà hier quand on m'a ordonné de faire le changement (et après en fait que quelqu'un d'autre a inversé le nom). Je n'ai donc pas du tout touché aux noms de langues hormi ce cas du yidiche qui a tout déclenché, alors que la grosse majorité des autres langues étaient déjà traitées et sans aucun problème.

C'est d'ailleurs ce que j'ai dit moi-même, et dans les noms que je renseigne, je n'ai pas modifié le nom par défaut même si l'ISO publie une autre orthographe ou qs'il y a des synonymes plus courants présentés déjà dans le Wiktionnaire avec leur page de définition et inter-reliées. Je vous ai donc laissé entièrement libre de discuter de ces noms, ce qui est déjà le cas depuis un moment maintenant que j'ai vu que ce n'est pas nouveau en retrouvant des discussions plus anciennes

D'ailleurs dans la Wikidémie, je note que de toute façon vous recherchiez déjà depuis un moment un moyen de pouvoir présenter plusieurs noms, ce que j'ai mis en place permet techniquement de le faire sans toucher aux noms par défaut actuels (que je ne touche plus du tout depuis "yidiche", quand j'ai vu que ça posait des problèmes métaphysiques insurmontables pour certains de le changer, et surtout de l'énervement)

Note quand même ces types de modèles sont en place depuis plus d'un an et demi sur TOUTES les langues les plus courantes. Ils ont remplacé d'autres modèles encore plus complexes et plus nombreux qui alourdissait les pages. Ce sont ces modèles optimisés qui ont aidé à redresser la situation concernant les pages contenant de nombreuses traductions (comme abeille qui sert de test). Ils ont démontré depuis longtemps qu'ils n'étaient pas la cause de la surcharge des pages et du serveur, grace aux statistiques mises dans les commentaires du code HTML des pages générées.

En particulier ces modèles ont déjà permis d'éviter la multiplication explosive et encore plus difficile à maintenir de façon uniforme de ces modèles (comme "fr", "français", "fr2", "nom-fr", etc.) pour créer des variantes de mise en forme ou de catégorisation des noms (même s'il reste encore des modèles spécialisés comme "=fr=" qui reste un simple raccourci pour "=lang=|{{{fr}}}", ou les modèles utilisateurs Babel).

Maintenant ce que je faisais ces jours-ci c'était terminer cette mise en place pour le reste, afin de pouvoir utiliser ces renseignements de façon plus systématique dans la gestion du contenu et la maintenance des pages. Personne n'a critiqué ce travail assez long à faire, au contraire on m'a écrit ici ou dans la Wikidémie pour y montrer de l'intérêt (sauf quand un nom par défaut a été changé, alors même que j'avais pris des précautions avant de faire le changement pour que ce changement soit facilement réversible).

En principe sur un projet Wiki, la règle est qu'on peut tout modifier sans en cas d'avis contraires et de conflits. Mais on ne demande pas aux contributeurs d'arrêter, surtout quand ils ne touchent pas ou ne cassent pas ce qu'ont fait les autres et ajoutent du contenu indépendant sur lequel personne ne vient faire de contestation (il peut y avoir des erreurs, souvent involontaires, tout le monde en fait, mais ça se corrige et on progresse comme ça sur tous les wikis, de Wikimedia ou d'ailleurs, ou dans tous les projets partagés). Je n'ai pas introduit de changement architectural majeur ces jours-ci (rien de nouveau depuis un an et demi!), la compatibilité est restée totale, je n'ai obligé par ces changements personne à changer ses méthodes d'écriture des articles ou du reste. Et j'ai fourni toutes les explications qu'on m'a demandées.

D'ailleurs je note que tu viens encore me donner un ordre d'arrêt ici (en l'étendant de façon abusive et jamais discutée avant), sans avoir fait même la moindre concertation (tes historiques le prouvent!). C'est complètement contraire à la charte Wikimedia, et un tel ordre est un abus de pouvoir. Dans le même temps on est venu me remercier pour le travail abattu. verdy_p 9 novembre 2008 à 06:58 (UTC)

Crois-moi, ça n'est pas dans mes habitudes de demander ça, et ça ne me fais pas plaisir. Si je devais « sévir », je ne le ferais qu'après concertation avec les autres membres du projet : et pour être franc je ne pense pas que je devrais en arriver à cette extrêmité. Si je suis administrateur, ce n'est pas pour abuser de mes « pouvoirs » selon mon bon vouloir, mais pour aider l'ensemble des contributeurs (toi y-compris).

Concernant les problèmes soulevés :

1. Les cas des choix des langues yiddish et masaï ne sont pas réglés (je sais que tu ne modifies plus les modèles, puisqu'il n'y a plus rien à modifier) ;
2. Ce qu'on te reproche pour les modèles, c'est de les avoir modifiés sans discussion préalable, alors qu'il s'agit de modèles importants (et pas seulement sur le plan technique, là je sais que tu fais attention), même d'avoir continué à les modifier quand bien même tu auras eu des demandes de suspension. Car si maintenant on voulait rechanger encore ces modèles, après réflexions, il nous faudra tout refaire (plus ou moins), ce qui réduirait ton travail à néant ;

NB : tout cela mis à part, je me permettrais une remarque sur la forme, en espérant ne pas passer pour un donneur de leçon (même si c'est peut-être déjà trop tard). Pour être franc, la plupart de tes interventions sont très longues : il est difficile et ennuyeux de lire d'aussi longs textes (peu importe leur qualité) et je pense qu'il serait bon que tu synthétises tes messages afin de mieux faire ressortir ta pensée sans les noyer dans la quantité de mots.

Cordialement, Dakdada (discuter) 9 novembre 2008 à 12:15 (UTC)

Ceci dit, des modèles beaucoup plus compliqués ont été créés et utilisés au départ sans concertation, puisqu'il s'agissait de modèles d'utilisation limitée. Mais aujourd'hui ils sont employés à grande échelle sur le Wiktionnaire et font l'objet de msies à jour nombreuses. Tant que ça ne casse pas tout et que ça ne change pas le principe déjà en place, personne ne râle.

Je n'ai rien fait ces derniers jours qui ne soit pas en place depuis plus d'un an et demi sur les principales langues, ça a été discuté à ce moment là, et en ce moment je finis simplement le travail sur les langues plus rares pour obtenir quelquechose d'homogène.

Désolé pour le changement de nom yidiche, mais j'ai déjà promis bien avant qu'on vienne me relancer pendant des heures que je ne toucherai pas aux noms par défaut, au vu des vagues insoupçonnées que cela a soulevé: c'est facile à voir et contrôler, les catégories ne bougent pas (même si quelques infos séparées sont insérées dans les modèles types), et pas besoin de "renommer" ou rediriger une catégorie tant que ce nom par défaut ne bouge pas.

Même ces modèles permettent de vérifier que les catégories sont bien là où il faut (il n'y a qu'à regarder la couleur rouge ou bleu du lien principal de la page d'aide, un lien qui est même passé en gras et et devenu plus explicite).

Danemark

Pourquoi avoir supprimé la traduction en bengali ? Koxinga 10 novembre 2008 à 02:06 (UTC)

J'ai fait ça ? Sans doûte une ligne mal formatée qui apparaissait toute blanche au milieu de la liste... verdy_p 10 novembre 2008 à 02:08 (UTC). Note, j'ai rectifié à la minute de ton signalement suite à ma réponse précédente. verdy_p 10 novembre 2008 à 08:19 (UTC)

Prénoms wallons (Cayin, Adan)

La catégorisation des prénoms est automatique, grâce au modèle -prénom- (c'est un cas suffisamment spécial pour mériter son type de mot, tout comme les noms de famille, type -nom-fam-). Par ailleurs, Adan est effectivement un prénom en wallon, mais pour Cayin, j'ai de très très gros doutes. Je pense que ce n'est pas plus un prénom que Caïn en français. Peux-tu citer des exemples d'utilisation de Cayin en tant que prénom ? Lmaltier 10 novembre 2008 à 07:59 (UTC)

Visiblement cela ne se faisait pas, c'est pour ça que j'ai rajouté la catégorie... En tout cas Cayin était déjà cité en prénom : aux temps bibliques il n'y avait pas encore de noms de famille, uniquement des prénoms (dits « noms de baptême »). Tous les prénoms de la Bible ont été utilisés, comme prénoms au cours des siècles, dans toutes les langues utilisées par les chrétiens et juifs. verdy_p 10 novembre 2008 à 08:03 (UTC)

Référence: http://prenoms.doctissimo.fr/CAIN-13487.html (pour Caïn) le site s'appuie sur les fichiers de l’INSEE. Ca montre que la référence biblique (négative) n'est plus un problème pour porter le prénom, même s'il reste encore rare (mais d'emploi stable parmi les prénoms donnés aux nouveaux-nés en France en 2004). Évidemment, on trouvera peu de références aux prénoms wallons en France. -- verdy_p 10 novembre 2008 à 08:09 (UTC)

Caïn est donc un prénom en français (très rare). Je suis surpris. Mais je demandais des exemples pour Cayin en tant que prénom wallon, pas pour Caïn en tant que prénom français. Peu importe d'où viennent ces références ou ces exemples, ça peut être dans des textes wallons, ou des sites en wallon, ou même dans l'annuaire téléphonique belge. Bien entendu, le nom de Caïn dans la Bible ne peut pas être considéré comme un prénom, c'est un nom, tout simplement. Pour qu'il y ait prénom, il faut quelque chose qui suive dans le nom. C'est pour ça que j'ai rajouté une section prénom dans Adan, en plus de la section nom propre, ce qui réalise la catégorisation automatique. Lmaltier 10 novembre 2008 à 08:34 (UTC)

OK j'ai juste fait pour Cayin la même chose que pour Adan, en voyant qu'ils n'utilisaient pas {{clé de tri}} : en l'ajoutant j'ai vu qu'il n'y avait pas de catégorie. Mais tu peux la supprimer de Cayin si tu veux... je n'ai pas trouvé non plus d'usage de Cayin en tant que prénom précédant un nom de famille (au contraire d'Adan et Caïn). verdy_p 10 novembre 2008 à 08:38 (UTC)

En recherchant Cayin dans les pages blanches de l'annuaire téléphonique belge « Pages d’Or » (pagesdor.be), je n'ai rien trouvé. En revanche cet annuaire me propose Catin à la place... et il y en a ! ;-o -- verdy_p 10 novembre 2008 à 08:43 (UTC)

Salut à vous deux. J'ai trouvé un truc concernant Cayin. C'est dans un Dictionnaire français-liégeois. (mais Caïn est écrit Caín, alors je ne sais pas ce que ça vaut) -Béotien lambda 10 novembre 2008 à 08:49 (UTC)

Tu as vu que ce dictionnaire belge cite aussi cayin-caya = cahin-caha ? En attendant la référence à Caín semble plutôt d'origine hispano-américaine, comme aussi Cayín avec le même accent aigu sur le i de la dernière syllabe tonique, dans l’Enciclopedia Universal Ilustrada Europeo-americana (malheureusement on ne peut pas voir d'extraits pour voir à quoi ça correspond). verdy_p 10 novembre 2008 à 08:52 (UTC)

Alémanique

J'ai vu que tu avais changé als en gsw. C'est vrai que gsw est le code ISO, mais als est le code utilisé par les projets de la fondation. Cela fait que tu as cassé les liens inter-wiktionnaires générés par le modèle trad (par exemple dans Suisse). Cela n'a peut-être pas beaucoup d'importance dans ce cas précis, parce qu'il se trouve que le wiktionnaire alémanique a fermé au mois d'avril (il existe encore, mais affiche un message). Mais cela montre qu'il ne faut pas modifier les codes trop vite : si on remarque une anomalie avec les codes, il faut la signaler et en discuter. Il y a peut-être d'autres cas analogues plus gênants. Lmaltier 10 novembre 2008 à 09:33 (UTC)

Note bien que ce wiki est fermé définitivement (le problème du code a aussi été évoqué dans les discussions relatives à cette fermeture du Wiktionnaire alémanique). Mais si on veut on peut toujours ajouter un code dans {{gsw}} mentionnant le code wiki encore utilisé bien qu'il soit en conflit avec un code normalisé pour l'albanais tosk, sachant que l'albanais {{sq}} est une macro-langues contenant plusieurs langues distingables dont le tosk est semble-t-il la variante par défaut car officielle en Albanie (j'avais déjà discuté de cette possibilité), afin de générer les liens interwikis corrects plus adapté, par exemple le code {{de}} ou l'absence de code (il y a un seul modèle à toucher, cependant je ne l'ai pas fait à cause du nombre d'emplois de celui-ci, cela ne peut se faire que dans les heures creuses, en fin de nuit en Europe et durant la semaine).

Note qu'il est impossible de rajouter de nouveaux articles sur ces wikis fermés.

Note aussi que le code gsw était déjà utilisé et il y avait donc des catégories en doublons, avec une utilisation incohérente des deux codes (alors que pour indiquer spécifiquement l'alsacien, il y avait aussi le code gsw-FR déjà créé qui classait déjà les articles dans la catégorie alémanique).

D'autre part, le code interwiki gsw est toujours en attente de création comme synonyme (la demande a déjà été faite, mais butte encore sur certains points techniques à régler avant, concernant les mises à jour des différents projets Wikimedia), mais rien ne justifie encore la création d'un code interwiki gsw-FR pour l'alsacien.

Bref je n'ai pas créé de nouveau code, ni créé de nouvelle catégorie, ni modifié les noms associés à chaque code, elles étaient déjà là, et je n'ai fait que les fusionner puisqu'ils affichaient déjà tous les deux le même nom "alémanique" ! Ces codes gsw et als étaient bien déjà en doublon avant mon passage (et il ne reste plus d'utilisation du code als, puisque je l'ai remplacé partout par gsw qui existait déjà). verdy_p 10 novembre 2008 à 10:22 (UTC)

Note aussi le message qui l'annonce (http://als.wiktionary.org) : "This project sub domain is going to be deleted or replaced by a redirect.". verdy_p 10 novembre 2008 à 10:31 (UTC)

Voir aussi http://als.wikipedia.org/w/index.php?title=Wikipedia:Stammtisch&oldid=155160 qui mentionne aussi la fermeture du Wikibooks, Wikinews, Wikiquotes (et les votes)... Il serait bon de trouver aussi les discussions sur Meta (concernant l'avenir du Wikipédia alémanique qu'on ne référence pas de toute façon). verdy_p 10 novembre 2008 à 10:35 (UTC)

Tu peux chercher si tu veux, mais je n'ai changé aucun nom depuis l'"affaire" du yidiche et les vagues que ça a soulevé, ni créé aucune nouvelle catégorie de langue par renommage (je n'a créé que les catégories relatives à des langues mentionnées déjà dans le wiktionnaire pour lesquelles il manquait un modèle associé ou une sous-catégorie thématique affichant un lien rouge en bas d'articles). verdy_p 10 novembre 2008 à 10:43 (UTC)

Note enfin que j'en ai discuté à l'endroit approprié, dans la page de la Wikidémie de juillet mentionnant l'anomalie déjà discutée et la création des codes gsw et gsw-FR..., ainsi que dans la liste des tâches à faire pour l'alémanique (une tâche de fusion maintenant terminée). verdy_p 10 novembre 2008 à 10:46 (UTC)

Modèle voir

L'appel du modèle voir est totalement indépendant des langues et de ce que peuvent bien signifier les mots ou caractères référencés. Voir l'aide. Lmaltier 10 novembre 2008 à 16:36 (UTC)

Justement, je le sais. Mais il n'est en revanche pas nécessaire de citer les caractères sans articles. On a un modèle plus pratique pour citer les caractères... Dans un modèle voir, on énumére les mots de toutes les langues, pas les caractères isolés, sinon ça ne tient pas dans la liste. verdy_p 10 novembre 2008 à 16:38 (UTC)

Tu as introduit une note faisant intervenir le sens. Si tu proposes de changer l'utilisation du modèle voir, lance une discussion ! Lmaltier 10 novembre 2008 à 16:48 (UTC) J'ai très bien compris. Et je répète ce que j'ai dit. Lmaltier 10 novembre 2008 à 16:50 (UTC)

Le modèle voir est utilisé pour les mots. Pour les caractères isolé, il y en a trop, et le résultat est très moche. On a un modèle depuis un moment pour les caractères latins, à mettre dans la section caractères juste en dessous. Du coup lister les caractères dans "voir" c'est redondant et en fait inutile: on y cherche d'abord des mots, expressions, sigles... pas des caractères isolés.

ça ne change pas le sens du modèle voir, mais inutile de citer des liens redondants listés aussi dans la boite des caractères juste en dessous. 'est comme ça depuis des mois pour les lettres latines de base. verdy_p 10 novembre 2008 à 16:51 (UTC)

C'est ton avis, mais d'autres peuvent avoir un autre avis (moi par exemple). Faire intervenir le sens pour savoir ce qu'il faut mettre après voir n'est pas possible, il y a déjà beaucoup trop de confusion à ce sujet. Lance une discussion ! Il faut aussi discuter du paramètre aussi=plutôt, qui est aberrant à mon avis, pour la même raison. Mais je ne l'ai pas supprimé, tant qu'il n'y a pas eu discussion. Lmaltier 10 novembre 2008 à 16:57 (UTC) Je précise : la discussion sur ce sujet ne doit pas avoir lieu sur cette page, qui n'est pas appropriée pour les discussions d'ordre général. Lmaltier 10 novembre 2008 à 16:58 (UTC)

Note: quand tu rajoutes les liens rouges pour Ć, ć, Č, č, est-ce que ça désigne des mots, des symboles, une définition d'autre chose qu'nu caractère isolé? Pour les caractères on aura de toute façon une boîte en dessous. Du coup ces liens sernot toujours redondants, à moins qu'un article donne une définition spécifique dans une ou plusieurs langues. après tout on ne site pas non plus "Avoir" (variation de capitale: c'est un changemetn de caractère, pas de mot). Sinon on n'a pas fini de rajouter des liens inutiles dans les sous-pages ":.../voir".

Peux-tu justifier la présence de ces caractères sans aucune définition associée (pas même une convention niternationale comme le caractère Å pour l'angström, et qui a donc droit d'être cité) ? Ce qui est aberrant c'est de laisser à cet endroit des liens rouges. Il est bien plus profitable de ne mentionner que les caractères (ou mots proches ou abbréviations par exemple avec un point ou une apostrophe) à cet endroit, le reste est redondant et pollue plutôt la lecture, surtout quand on sait que le modèle voir ne peut afficher au mieux que neuf mots (et devoir en mettre plusieurs l'un sous l'autre est assez affreux). Je le répète, ces lettres seules, sans mot ni convention, sont redondants. Ca a été discuté justement pour la lettre A. verdy_p 10 novembre 2008 à 17:02 (UTC)

Je ne répondrai plus ici, ce n'est pas le lieu. Lance une discussion générale. Lmaltier 10 novembre 2008 à 17:04 (UTC)

Ça suffit, je ne peux pas repasser systématiquement derrière toi. Lance une discussion ! Lmaltier 10 novembre 2008 à 17:41 (UTC)

Tu veux dire, "relancer" une discussion. Je ne me rappelle plus quand ça a été discuté, mais c'est le nombre de "voir" concernant les caractères qui a suscité la création de boîtes à mettre dans les sections "Caractère". Ces sections ne sont pas propres à une langue, elles sont générales, et des caractères peuvent être utilisés dans une langue sans qu'il y ait de mot utilisant la lettre seule

Et naturellement ces boîtes regroupent beaucoup de caractères similaires ou apparentés (en essayant de sélectionner ceux qui sont pertinents en fonction de la lettre qu'on présente dans un article.

Si on tient compte de toutes les langues qui les emploie, et aussi des différentes capitales, minuscules, formes contextuelles de minuscules, cela fait déborder la boîte "Voir". C'est ridicule, alors que dans les mêmes articles il est bon de savoir si cela renvoie à un mot ou une abréviation dans une langue particulière.

Quand un article traite alors de la contraction française c’ ou ç’, est-ce utile de référencer toutes les formes de la lettre c elle-même ? Si on cherche une lettre on a juste à la taper, et on a un beau tableau qui mentionne ses variantes (mais pas forcément les mots qui sont situés juste au dessus dans la boîte voir). Tu veux faire un contre-usage du modèle voir en l’étentant à autre chose que la recherche de mots à graphie similaire, et où la confusion est possible. Cela n'apporte aucune aide à la navigation non plus (au contraire). verdy_p 11 novembre 2008 à 17:59 (UTC)

Non, personne n'a jamais discuté de ton idée, certainement pas (à part moi ici). J'ai réfléchi, et il y aurait plusieurs solutions possibles et cohérentes. Je peux les proposer, mais pas ici, ça concerne tout le monde. Tu veux changer la méthode actuelle, alors lance une discussion ! Lmaltier 11 novembre 2008 à 21:28 (UTC)

erreur clé de tri

Merci de m'avoir signalé l'erreur. Elle était corrigée dans le robot depuis longtemps (je m'en était aperçu à anchéenne), et j'avais corrigé les premiers par un autre robot, et ça marchait (voir anchéenne, le dernier faux). Je ne comprends donc pas, mais je suis bon pour relancer ce robot. -- J'ai compris. Je m'en occupe. Mais cela ne concerne que certains adjectifs au féminin singulier. Si tu as détecté d'autres cas faux, pourrais-tu me donner un lien vers un article où la clé de tri est fausse ? Lmaltier 12 novembre 2008 à 08:36 (UTC)

Pour le tri autour d'Abbeville, je ne comprends pas ce que tu veux dire : chez moi, le tri est parfaitement correct. Lmaltier 11 novembre 2008 à 21:13 (UTC)

Non ce n'est pas bon, la casse n'est pas respectée dans les clés indiquées tout en minuscules.

La différence se voit sur les catégories où sont listées à la fois les termes avec des majuscules et sans majuscule: le tri est alors instable à cause du bogue MediaWiki actuel.

Ceci dit je note que notre serveur vient de refaire toute son indexation des catégories, en réanalysant le code Wiki de chacune des pages (c'est ce qu'il a du faire depuis hier au moins (et ce qu'il faisait depuis plusieurs jours visiblement avec un niveau permanent et sans cesse réalimenté, alors que le compteur des modifications de page restait à zéro ou quasiment, sans modification notable dans l'historique) car le compteur des pages en file d'attente de traitement est resté bloqué autour des 3000 pages, avec une pointe à plus de 5000 depuis ce midi), et il ne rajoute visiblement plus de code de type "%7FUNIQ-numéro-numéro...-nowiki-...%7F" à nos clés en les tronquant (car les clés font au maximum 70 octets, en UTF-8, y compris le code que MediaWiki y mettait dans certains cas en cas de collision). Je ne sais pas quand est intervenu le changement de version. verdy_p 11 novembre 2008 à 21:35 (UTC)

Réflexion faite, le serveur travaille encore. Le tri est toujours mauvais autour de Abeilhan. Et si on cherche dans des catégories ou sont insérés des mots à capitalisation mixte, c'est encore plus évident: il faut garder la casse dans la clé précisée (comme ce qui est fait quand on ne passe pas le paramètre à {{clé de tri}}, ce qui est le cas quand il n'y a pas d'accent ou d'autres caractères à ignorer: c'estle modèle qui s'occupe lui-même de calculer la clé composite nécessaire) pour que le tri fonctionne de la façon attendue.

Donc en bref :

• ne pas s'occuper de changer la casse, ne s'occuper que de supprimer les diacritiques et caractères génants (comme l'apostrophe, le tiret et la ponctuation), mais utiliser quand même le modèle {{clé de tri}} sans paramètre s'il y a une/des majuscule(s), ne pas utiliser du tout le modèle s'il n'y a que des lettres minuscules de base (sauf les formes alternatives grecques par exemple le sigma final minuscule qu'il faut changer en sigma), des lettres brahmiques, des ideogrammes canoniques et chiffres.
• Pour l'arabe, convertir tous les caractères sous leur forme contextuelle automatique (remplacer les variantes de forme non contextuelles). Même chose pour l'arménien.
• Pour le chinois, remplacer les caractères de compatibilité (ou variantes de forme traditionelles) par les caractères canoniques (communes au japonais, chinois, coréen, et vietnamien). Etc.

S'il faut être exhaustif, on peut s'aider des tables fournies par Unicode, et en particulier la table DUCET pour ne garder que le caractère de tête de chaque sous-classe de caractère au niveau 2 de collation, c'est à dire prenant en compte les différences de lettres de base et de casse, mais pas celles d'accents qui sont au niveau 3).

Une exception peut être faite pour l'hébreu, pour les lettres avec Geresh/Mappiq/Shuruk (pour les lettres semi-voyelles Alef, Het, Waw et Yod) ou surtout pour le point Sin ou Shin (ils n'existent qu'avec une lettre Shin), ces diacritiques peuvent être gardés si on les code sous forme combinée avec la lettre de base, car cela donne un caractère malgré tout correctement classé en hébreu mais conservant certaines distinctions importantes de consonnes (dans la table DUCET, il y a une différence de niveau 3). verdy_p 11 novembre 2008 à 22:03 (UTC)

Encore d'autres tri erronés en exemple : autour de Ableige, Ablis et Ablon et autour de abondance, je m'arrête là, des exemples il y en a sur presque toutes les pages de la catégorie français. (Note que pour le tri correct autour de "Paris", je l'ai corrigé moi-même, il suffit de regarder les commentaires des modifs sur les gentilés présents sur la page de catégorie:français commençant à "pari"). verdy_p 11 novembre 2008 à 22:10 (UTC)

Chez moi, les tris autour d'Abeilhan, d'Ableige, d'Ablis, d'Ablon, d'Abondance sont tous corrects (à noter que c'est normal que Ablon-sur-Seine soit juste après Ablon, selon nos critères, qui ne sont pas identiques aux dictionnaires classiques : il y a eu des discussions là-dessus et il y a de bonnes raisons de faire différemment des dictionnaires classiques). Comment se fait-il qu'on ait tant de mal à te comprendre ? Lmaltier 12 novembre 2008 à 08:43 (UTC)

Ce dépend de quel dictionnaire tu parles (même en se limitant au seul français ou même au seul éditeur Larousse). Le Petit Larousse (avec pages roses séparées pour les noms propres) est plutôt l'exception que la règle, et Larousse emploie une règle plus classique dans ses autres dicos (traduction, rimes, etc.) et encyclopédies. Le tri actuel ici est compatible avec un traitement multilingue et autorise de classer toujours ensemble les articles qui ne diffèrent strictement QUE par la casse, en reportant les autres différences (accents et signes) plus loin, mais en gardant toujours ensembles (et dans l'ordre minuscules puis majuscules) les paires de lettres accentuées (note: l'apostrophe est traitée comme un accent et non comme un autre signe de ponctuation qui lui serait traité comme une espace. verdy_p 30 novembre 2008 à 21:55 (UTC)

Clés de tri pour langues différentes

Je vais lancer une discussion sur le cas de clés de tri censées être différentes selon la langue. Si tu pouvais proposer des solutions, ça me plairait. Lmaltier 12 novembre 2008 à 09:29 (UTC)

C'est délicat, vu qu'on met dans le même articles les définitions pour la même graphie utilisée dans plusieurs langues. On ne peut pas respecter le tri de l'une sans casser celles de l'autre.

C'est pour ça que les règles actuelles du français sont utilisées (basées sur le tri normalisé UCA et la table par défaut DUCET d'Unicode, sans aplpiquer toutefois l'inversion des accents comme le demanderait normalement le français).

Et dès qu'on a des catégories mutlilingues il est impossible d'appliquer plusieurs tris simultanément.

Ceci dit, cela ne concerne que la clé de tri par défaut, on peut toujours mentionner une clé spécifique pour une catégorie donnée (mais il va falloir revoir un certain nombre de modèles pour qu'ils précisent la langue à utiliser pour la clé de tri : c'est possible, mais ça va compliquer le travail d'édition dans des modèles auto-catégorisants très utilisés au milieu de la page comme {{-nom-}} ou même {{acron}} !)

Pour les catégories insérées manuellement dans la page (non automatiquement via un modèle) ce n'est pas un problème, on peut mettre une clé adaptée à une catégorie concernant une langue précise. Mais il faudra alors s'assurer que tous les articles pointant vers cette catégorie utilisent bien l'autre "norme" de clé.

Est-ce que le jeu en vaut la chandelle en terme de complication ?

Pensais-tu à l'espéranto ? Pour l'espéranto on ne va pas mettre les graphies utilisant un x au lieu d'un accent circonflexe, une seule suffit (c'est la graphie avec accent circonflexe qui est recommandée et même utilisée et automatiquement lors de l'édition sur les projets wikimédia en espéranto, la graphie en x étant juste là pour faciliter l'édition). En aucun cas l'espéranto ne trie avec des x ! verdy_p 12 novembre 2008 à 15:49 (UTC)

Non, ce qui est plutôt retenu c'est un modèle de génération de clé le plus proche possible du tri UCA d'Unicode avec la table DUCET, qui EST bel et bien internationale, et tant pis si on ne peut pas faire d'exception (pour renverser le tri, par exemple à l'espagnole, ou la suédoise): ce tri normalisé se défend est reste très lisible dans toutes les langues avec une logique facile à comprendre car déterministe et basée sur les caractères standards que ces langues utilisent (même si elles considèrent certaines paires ou triplets de caractères comme un graphème unique, qui se trie comme une seule entité, comme en breton, en espagnol, ou en allemand traditionnel d'Allemagne par exemple... mais pas en allemand de Suisse ni en alémanique de Suisse ou d'Alsace.).

On est sur le wikipédia français, on utilise les règles de tri françaises qui sont pratiquement celles de DUCET, les seules exceptions françaises étant:

• œ/Œ changés en oe/OE
• æ/Æ changés en ae/AE
• on n'applique pas l'inversion des accents, diacritiques et autres signes (lecture de droite à gauche), normalement utilisée pour le français (faute de support dans les fonctions de MediaWiki), ceci dit cela facilite la cohabitation avec les autres langues et la différence pour le français est extrèmement mineure et très localisée, et peu de gens connaissent cette règle hormis les techniciens les plus expérimentés travaillant dans l'édition des dictionnaires ou annuaires.

Tant qu'on n'aura pas un support intégré de la collation UCA dans MediaWiki, et de la grande table DUCET, et des petites tables d'adaptation de la collation à une langue (collation tailoring en anglais), il me semble illusoire de pouvoir personnaliser le tri par langue dans les catégories (et ce support intégré, s'il existait, devrait se faire alors par un paramètre indiqué dans la page de catégorie elle-même, et non dans les articles, qui devront continuer à utiliser des clés par défaut...

Ceci dit, certains voudront aussi plusieurs tris pour la même catégorie (les chinois, qui trient suivant plusieurs méthodes, ou les espagnols par exemple selon qu'ils utilisent une méthode traditionnelle ou celle de l'annuaire).

verdy_p 12 novembre 2008 à 16:00 (UTC)

Note bien : pour les caractères non utilisés en français, on utilise les règles de la langue majeure utilisant l'écriture, et dan ce cas ce sont les règles de l'anglais pour l'écriture latine (ces règles sont exactement celles de DUCET pour l'écriture latine), du russe pour l'écriture cyrillique (ces règles sont dans DUCET), du chinois codé pour l'écriture sinographique (la table DUCET contient un tri de ces caractères qui est mis au point spécifiquement pour le chinois, c'est un tri par clé, et non par nombre de traits), du lao pour l'écriture lao. Cependant actuellement on ne sait pas générer des clés pour les sinogrammes : on les trie de façon binaire (en fait dans l'ordre des points de code numériques Unicode transcrits en séquences UTF-8), et on ne peut pas faire mieux sans support de l'UCA dans une extension MediaWiki (écrite en PHP) peut-être même dans une extension (écrite en C et précompilée) du moteur de script PHP lui-même.

Je ne veux pas chercher à inventer (la norme UCA existe et est largement approuvée, elle est même très implantée dans les moteurs SQL comme Oracle, Sybase, Informix,Ingres, PostGres, MSSQL, et est en passe de l'être aussi bientôt dans MySQL : il faut seulement charger l'extension UCA et le support complet d'Unicode dans ces moteurs SQL, car elle n'est pas installée par défaut, mais il faut aussi modifier le schéma de la base de données pour indiquer les colonnes internationalisables en utilisant d'autres types comme NVARCHAR au lieu de VARCHAR, et le code des requêtes SQL pour préciser la règle de tri pour 'ORDER BY nom.de.colonnes').

Je connais les limites actuelles, et on a jusqu'à présent suivi un chemin utilisant ce qu'on pouvait faire de mieux dans les limites techniques actuelles.

Je pense que si une extension doit venir en premier, ce sera par l'intégration du support UCA dans le moteur MySQL utilisé par MediaWiki pour obtenir la liste des pages et la trier, et non dans PHP ni dans une extension MediaWiki, mais on ne pourra pas personnaliser comme on veut.

verdy_p 12 novembre 2008 à 16:21 (UTC)

C'est dans le Wikidémie qu'il faudrait répondre (de façon beaucoup plus courte et plus simple, tout le monde n'est pas spécialiste de tout ça). En tout cas je ne suis pas d'accord avec quelque chose : non, on n'est pas sur Wikipédia (où ta position serait bien sûr cohérente). Mais c'est un problème difficile. On pourrait imaginer définir un modèle clé de tri où on préciserait les cas particuliers de certaines langues, mais il faudrait voir comment faire le lien avec les catégories concernées. Lmaltier 12 novembre 2008 à 16:41 (UTC)

D'accord mais la solution actuelle demande de préciser les clés au niveau de la page source, là où les catégroies par langue voudraient que ce soit ellse qui impose la méthode de tri, et non les articles qui y sont référencés.

Comme les articles sont multilingues, et que nos modèles ne savent pas (la plupart du temps) pour quelle langue ils font une description utilisant ces modèles, on se retrouve avec des clés automatiques contenant juste la clé par défaut pour toute la page (celle qu'on met en base d'article).

Si maintenant cela ne suffit pas, il va falloir préciser la clé de tri pour chacun des appels de sous-modèles ! Je n'ose pas imaginer la complication pour les contributeurs comme pour les robots s'il doivent émailler partout l'article avec des clés pour chaque langue, autant de fois qu'il y a de modèles autocatégorisants !

Tant qu'on ne pourra pas générer des clés correctes pour chaque langue en tenant compte des contriantes imposées par une catégorie cible, je ne vois aucune solution.

→ Un support idéal serait de pouvoir préciser plusieurs clés dans un article, au moyen de variables globales pour la page, des variables qu'on pourraient affecter dans une page, des variables que les modèles utilisés pourraient ensuite lire et utiliser. Mais il faudrait que ces variables soient initialisées au début de la page (sinon il faudra réinterpréter la page depuis le début en ignorant le formatage déjà fait: le moteur MediaWiki devrait faire nécessairement deux passes.)

Alors les modèles auraient une information de contexte disponible, par exemple ils sauraient dans quelle langue est la section où le modèle est appelé. Et dans ce cas ils auraient assez d'information pour sélectionner la bonne clé parmi les clés disponibles dans le contexte de page.

verdy_p 12 novembre 2008 à 16:59 (UTC)

*bhr-eH2-

Tu serais gentil de passer par la PàS pour faire valoir ton point de vue. S'il est justifié, cela peut être traité rapidement, mais il faut respecter les procédures. --Szyx 17 novembre 2008 à 18:30 (UTC)

Si c'est la forme du nom qui te choque (ou qui a choqué celui qui a mis le modèle sup, car l'article était seulement insuffisamment formaté), c'est pourtant l'orthographe utilisé pour le proto-européen qui utilise des symboles et chiffres en plus des lettres.

Il y a une catégorie pour le proto-indo-européen (appelée ici indo-européen commun), et des références sur cette langue reconstruite par des scientifiques. verdy_p 17 novembre 2008 à 18:33 (UTC)

Note bien que je n'ai pas trouvé la discussion à ce sujet, la demande semblait incomplète (c'est pour ça que j'ai corrigé le modèle supprimer après ton message). verdy_p 17 novembre 2008 à 19:57 (UTC)

OK, je te laisse faire pour le modèle. --Szyx 17 novembre 2008 à 18:55 (UTC)

Parfait, tu as compris ce que je voulais faire, et cela fonctionne sur *bhr-eH2-.

Sur le fond, je suis incompétent, désolé. --Szyx 17 novembre 2008 à 19:17 (UTC)

Tu noteras qu'on peut maintenant indiquer la cible du modèle avec les caractères normaux. Et j'ai testé le résultat sur les noms en hindi et arabe.

Il fallait bien un {{anchorencode:}} pour éviter le bogue quand le titre de la page marquée avec ce modèle commence par une astérisque (ça ne marchait pas à l'affichage du modèle et la cible était de toute façon fausse). Cela blinde aussi le cas où il y aurait d'autres caractères invisibles, ou spéciaux dans le titre, et on aboutit directement à la bonne section dans la page "Pages à supprimer". verdy_p 17 novembre 2008 à 19:38 (UTC)

Ceci dit c'est encore une modif liée à la vérification des codes langues incohérents (à ce sujet je prépare une classification complète, d'après les données Ethnologue. Cela ne changera rien aux articles ou aux noms affichés, mais ça facilitera la recherche parmi les langues "apparentées". t pour cela il faut revenir aux codes ISO 639 standard dont on va avoir besoin pour coder les familles (qui en revanche n'ont pas vocation à contenir directement des mots dans le Wiktionnaire.

Je suis en train de finir l'ISO 639-2 (tu noteras que je ne change plus aucun nom affiché, donc pas non plus les noms des catégories actuelles associées), mais quelques codes peu utilisés peuvent être remplacés facilement.

J'ai annoté aussi des langues incorrectement considérées comme langues alors que ce sont des familles: l'iroquois, l'apache, le sorabe... alors qu'on a aussi des entrées directes vers les véritables langues individuelles.

Toutes les langues individuelles et macro-langues de l’ISO 639-2 sont maintenant à jour, il reste quelques familles (étendue=C) à finir.

Ensuite je pourrai m'attaquer aux autres langues codées uniquement en ISO 639-3 (il n'y a pas de familles dedans, ce qui simplifie les choses, juste des macro-langues contenant éventuellement des langues individuelles, mais pour lequel il semble acceptable de laisser la catégorisation de termes vers la macro-langue. Mais il faudra trouver une solution pour catégoriser ensembles les langues individuelles dans leur macro-langues.

Ensuite seulement on pourra s'attaquer à la vérification des familles de langues de l’ISO 639-1 et -2 (que je laisse de côté pour l'instant quand elles sont "trop peuplées" alors qu'elles sont pourtant TRES ambigüess et TOUTES à revérifier (apache, iroquois, albanais...)

Pour l'albanais {{sq}}, on pourrais se contenter d'abord de le reclasser vers l'albanais tosk par défaut (en mettant une note si on ne change pas le nom de langue par défaut, cependant que l'ISO considère bien le code "sq" comme "langues albanaises" au pluriel), quitte à sortir les exceptions concernant les autres formes de l'albanais. Note: les variantes de l'albanais ne sont PAS des dialectes, mais des langues séparées (le code sq de l'ISO 639-1 était utilisé pour toutes, et par compatibilité pointe toujours sur la famille "alb", bien qu'en fait il est très probablement utilisé uniquement pour le tosk dans la majorité des cas. Pour ce cas, je ne sais pas ce qu'on devrait faire (l'ISO 639 ne considère PAS l'albanais comme une macro-langue, mais on pourrait lui poser la question si sa classification actuelle en tant que famille dans l'ISO 639-3 ne pose pas des problèmes de compatibilité). On ne peut à l'heuer atuelle pas dismabiguer les cas sans avoir une référence albanaise sérieuse.

Aussi je laisse le cas de l'albanais de côté pour l'instant, il y a bien d’autres choses à vérifier. La question se reposera plus tard (mais je ne sais pas quand).

verdy_p 17 novembre 2008 à 19:55 (UTC)

Moi, je n'ai besoin que d'une ligne pour dire : bien. --Szyx 17 novembre 2008 à 20:26 (UTC)

Modèle pron

Salut,

juste pour te prévenir que j'ai en projet de réparer le modèle {{pron}} que tu avais apparemment cassé (?). Merci de voir le message sur la Wikidémie pour les détails. - Dakdada (discuter) 20 novembre 2008 à 11:20 (UTC)

Je ne vois pas ce que j'ai fait qui ait cassé quelque chose. J'ai regardé l'historique les dernières modifs effectives sont de Urhuixidur, mais ne semblent pas poser de problème non plus, puis la pose par lui de la protection). Mes dernières modifs sont un compactage, mais invisible.

Il faudrait que je vois ce qu'en dit la Wikidémie... verdy_p 20 novembre 2008 à 11:26 (UTC)

Ça date de longtemps (on s'était un peu frité à cette époque, cf ma réversion). Tes remarques sur la Wikidémie m'on bien fait réfléchir, merci. - Dakdada (discuter) 21 novembre 2008 à 11:06 (UTC)

Resalut,

j'aimerais savoir ce que tu penses du changement du modèle {{pron}} que je propose sur la Wikidémie, sachant que la conversion est désormais possible via les gadgets des préférences : vois-tu un problème à ce que j'effectue le changement mentionné ? - Dakdada (discuter) 26 novembre 2008 à 12:51 (UTC)

créole martiniquais et créole guadeloupéen

J'ai vu que tu as redirigé la Catégorie:créole martiniquais vers Catégorie:créole guadeloupéen. N'y a-t-il pas des différences entre ces deux créoles ? Si j'en crois Google Livres avec la recherche "créole martiniquais" "créole guadeloupéen", il semblerait que les deux existent. Avec la recherche "créole martiniquais", on trouve de nombreux écrits traitant de ce parler en particulier. -Béotien lambda 21 novembre 2008 à 10:35 (UTC)

C'est selon l'ISO et the Ethnologue la même langue. C'est comme parler de la différence entre le parler parisien et le parler marseillais pour le français. Au mieux il aura quelques régionalismes, mais les deux sont totalement mutuellement intelligibles : il y a des médias (radios locales notamment) et journaux communs, livres communs...

Les articles qui traitent de l'une traiente aussi de l'autre. Il n'y a rien de particulier entre les deux, les deux expressions sont synonymes (mais évidemment en Martinique on l'appelle "créole martiniquais", mais en fait seulement "kreyiol" (comme en Guadeloupe, ainsi qu'à Haiti dont le créole est cependant assez différent).

De plus la catégorie martinicaise était totalement vide. verdy_p 21 novembre 2008 à 10:40 (UTC)

Note: le modèle mcf qui avait été inventé par on ne sait qui entrait aussi en conflit avec une autre langue qui n'a rien à voir. Il n'y a pas de code ISO 639 pour la martiniquais. Voir référence sur le site de réf. de l'ISO 639-3 (www.sil.org) et de l'Ethnologue. verdy_p 21 novembre 2008 à 10:45 (UTC)

{{Locuteur}} et modèles de langues

Un petit travail pour toi, si tu t'ennuies : supprimer le paramètre ascii= de {{Locuteur}}, qui est inutile si tous les modèles de langues comportent une option type=cat (et surtout le supprimer de tous les appels au modèle). Voir le contenu de Catégorie:Utilisateurs ko, où l'on voit la redondance.

Bon travail (passé et futur). --Szyx 22 novembre 2008 à 16:33 (UTC)

J'ai fini tous les codes ISO 639-1 et -2 et presque tous ceux de l'ISO 639-3 (il y en a encore d'autres que j'ai trouvés dans diverses pages, une vingtaine environ).

Je fais aussi le tri des autres modèles et dialectes dans la catégorie:Modèles de code langue.

Notes :

• J'ai maintenant totalement intégré le support de la conversion des codes langues en codes interwiki (voir {{lang/interwiki}}), ce qui permettra de lier correctement les langues dans les traductions pour lesquelles il existe une édition du Wiktionnaire, et détecter automatiquement celles qui n'en ont pas (ce qui évitera de mettre une URL vers un sous-domaine de wiktionary.org qui n'existe pas ou pas encore, ou vers ceux qui sont fermés).
• Un code est protégé que je ne peux pas normaliser comme les autres : {{nov}} (novial). Peux-tu le débloquer pour qu'il puisse adopter la même structure que {{fr}} ?

Je m'occuperai du paramètre ascii= plus tard. Merci pour ce signalement.

verdy_p 22 novembre 2008 à 16:42 (UTC)

pour la déprotection (amusant : aucune trace de la protection dans le journal, elle date peut-être de la création du modèle par Utilisateur:MediaWiki default - le compte par défaut de celui qui a créé fr.wiktionary en 2004). --Szyx 22 novembre 2008 à 17:08 (UTC)

À mon avis cela vient d'un des deux admins qui ont déwikifié le lien puis catégorisé le modèle : ils ont modifié le commentaire par défaut pour leurs modifs, en n'indiquant pas qu'ils activaient en même temps la protection. L’Utilisateur:MediaWiki default est un Bot qui ne s'amuse pas (à ma connaissance) à ce genre de chose sur les projets wikis, et n'intervient normalement pas ailleurs que dans l'espace de nom MediaWiki, sauf pour y ajouter des ressources jugées manquantes (mais il ne les protège pas lui-même, et laisse chaque projet gérer ses ajouts ou modifications).

Merci pour la déprotection, le modèle est maintenant corrigé... verdy_p 22 novembre 2008 à 17:17 (UTC)

Note 1: le modèle {{Locuteur}} est grandement simplifié, car 3 paramètres optionnels disparaissent.

Note 2: le modèle {{mod}} est en conflit avec un code langue et redirige pour l'instant sur {{Mod}} (pour compatibilité provisoirement). Un de ces jours il faudra passer un Bot (le suppresseur de redirections) pour changer tous les {{mod}} en "{{Mod}}", y compris dans les pages de discussions, et ne plus utiliser {{mod}} comme tu le fais encore.

verdy_p 22 novembre 2008 à 17:21 (UTC)

• Non, ce que tu dis est impossible, on ne peut pas à la fois modifier et protéger une page, ce sont deux opérations qui ne peuvent être faites que l'une après l'autre, la seconde étant listée dans un journal séparé, Special:Journal, qui était vide pour cette page. La seule solution est que cette protection ait été faite avant que MediaWiki gère ces journaux, ce qui doit dater de 2005 si mes souvenirs sont exacts, d'où mon hypothèse (et non, MediaWiki default n'est pas un bot mais un compte système créé automatiquement à l'installation de MediaWiki)
• J'ai ajouté une petite explication sur Modèle:lang/Aide#Comment utiliser à l’intérieur des modèles, pourrais-tu vérifier que je n'ai pas raconté de bêtise ?
• Pour {{mod}} et {{Mod}}, il faut leur trouver un nom différent, d'au moins 4 lettres, sinon c'est source de confusion. Pour la même raison j'avais changé {mdr} en {rire}.

--Szyx 22 novembre 2008 à 17:58 (UTC)

• Pour {{mod}} renommé {{Mod}}, je n'ai pas voulu trop changer les habitudes. De toute façon, une fois que les redirections seront supprimées, et le code {{mod}} réservé pour les paramètres de langue, il n'y aura plus de confusion, car un mauvais emploi affichera le nom de la langue et non la référence à un modèle. Ce type de renommage est ce qui s'est passé sur les autres Wiktionnaires. Un autre nom possible (utilisé sur la Wikipédia francophone est {{M}} : à voir plus tard dans une discussion pour savoir quel raccourci on va garder (4 lettres ça fait beaucoup je trouve...) verdy_p 22 novembre 2008 à 18:17 (UTC)

Pourquoi pas {{modl}}, une bonne approximation en langage SMS, non ? Et surtout facile à retenir, je pense. Cela me fait penser qu'il faut le catégoriser en Catégorie:Modèles pour page de discussion. --Szyx 22 novembre 2008 à 18:50 (UTC)

On a déjà le synonyme M supporté (car il est utilisé sur Wikipédia). Et ce nom convient très bien pour les discussions: facile à taper, et pas de surprise pour ceux qui viennent de Wikipédia. verdy_p 22 novembre 2008 à 18:52 (UTC)

Moi j'aime pas les schtroumpfs qui diffèrent que par la casse (sur wp, tout le monde l'utilise en minuscule). cf modèle:m --Szyx 22 novembre 2008 à 18:57 (UTC)

Wiktionnaire:Gestion des modèles#Changement de nom de Modèle:mod pour cause de conflit avec l'ISO639. --Szyx 22 novembre 2008 à 22:43 (UTC)

• Note: il y a deux pages d'aide distinctes pour les modèles: une se veut simple et présente les valeurs réelles ou calculées à partir du modèle de base (juste nommé d'après le code seulement), l'autre sert à la conception des modèles xxx/type et catégorise à part ces modèles. J’ai effectué un grand nettoyage de classification, mais ce n'est pas encore totalement terminé, il reste des exceptions à gérer, notamment pour les dialectes et variétés. C'est ce que je fais en ce moment (voir par exemple {{ca-val}} qui a été normalisé, {{bat-smg}} qui adopte aussi la nouvelle forme.
• Concernant les synonymes, ils se paramètrent maintenant dans les modèles xxx/type, mais il y a beaucoup de liens rouges, il va falloir revoir ceux qu'on retient et seront utiles à afficher.
• Concernant les modèles "=xxx=" je compte aussi les normaliser, sans doûte à l'aide d'un Bot si possible (à validation manuelle) après avoir fait quelques essais (pour vérifier les expressions régulières), car ils ne contiennent strictement rien de spécifique qui ne soit pas déjà renseigné dans les modèles "xxx/type". Cette modif devrait sans doûte nécessiter la déprotection temporaire du modèle {{}}, et je voudrais savoir dans ce cas si ceux-ci devrait afficher les synonymes (et le code normalisé en petit entre crochets), et générer alors des ancres pour les liens (je suggère que ces ancres deviennent plus simples: le code devrait être suffisant au lieu du nom complet utilisé dans le titre des sections que ces modèles =xxx= génèrent via =lang=).
• Concernant les traductions, on peut maintenant faire les liens corrects vers les autres Wiktionnaires (pour ne plus afficher les liens rouges ou aller vers un wiktionnaire dont le code est non normalisé ou qui supporte plusieurs variétés ou dialectes de la même langue). Cependant, pour l'instant elles sont centralisées dans le modèle {{lang/interwiki}} au lieu d'être distribué dans chacun des modèles xxx/type (ce qui serait moins dangereux en cas de modification). Je vais donc utiliser le modèle {{lang/interwiki}} comme base pour ajouter le support du switch sur le cas "interwiki=" dans les modèles xxx/type directement. Cela se fera par un Bot très lent, comparable à une édition manuelle, avec une modif par minute (pour éviter la saturation du serveur, car les modèles xxx/type à compléter concernent les langues les plus référencées). Ceci fait le modèle {{lang/interwiki}} utilisera directement la valeur indiquée dans chaque modèle xxx/type.

verdy_p 22 novembre 2008 à 18:17 (UTC)

Le dernier point m'intéresse mais je ne suis pas sûr d'avoir compris. Après on pourra ajouter un test dans le modèle et on n'aura plus à traiter à part les langues n'ayant pas de wiki ? Tu pourras me prévenir quand cela sera mis au point ? De toute façon, j'attend d'avoir des idées plus claires sur les sections traductions avant de faire tourner mon bot mais cela va sûrement influencer son fonctionnement. Koxinga 22 novembre 2008 à 19:50 (UTC)

Cela marche déjà ! Le modèle est en place, même s'il va être simplifié (la liste des codes qu’il contient sera reportée dans chacun des modèles, chacune des langues paramétrées n'ayant alors pas de code interwiki associé, sauf si on l'indique explicitement dans le switch en mettant interwiki=code, ce code pouvant être différent). Pour l'instant, on peut préciser cette valeur dans les modèles xxx/type (j'ai commencé à en mettre un ou deux, mais je le ferai plus tard car il n'y a pas d'urgence), mais le modèle qui l'utilise {{lang/interwiki}} n'en tient pas encore compte et retourne la valeur lui-même (ce qui va changer car cela n'autorise pas un changement unitaire langue par langue). verdy_p 22 novembre 2008 à 19:57 (UTC)

Ceci dit, ne l'utilise pas encore dans les modèles des traductions: en effet, cela risque de faire exploser les pages comportant de nombreuses traductions, car la taille de la liste dans le modèle {{lang/interwiki}} est trop grosse. Ce sera nettement mieux nue fois les codes distribués. C'est encore en ébauche... verdy_p 22 novembre 2008 à 20:09 (UTC)

J'oubliais : si ça t'amuse, tu peux reprendre les exemples de modifs des catégories utilisateurs (j'ai fait le français, le coréen, et les premier et derniers codes de la catégorie associée). Tu verras que c'est bien plus simple, et automatisable de la même façon (utiliser "type=le nom", supprimer "'=oui" inutile en paramètre du modèle affiché dans la catégorie mère de chaque code langue, mais malheureusement pas affiché pour l'instant dans les sous-catégories par niveau de langue). verdy_p 22 novembre 2008 à 19:01 (UTC)

Concrètement, qu'est-ce que je dois faire pour les langues qui n'ont pas de wiki ? On peut leur laisser le modèle trad parce que cela sera bientôt géré automatiquement, c'est bien ça ? Koxinga 29 novembre 2008 à 05:58 (UTC)

Ne t'en occupes pas, la désactivation du lien se fera tout seul. Je finis le paramétrage ce week-end.

Il me reste juste quelques conflits de codes langues à résoudre (en accord avec les nouvelles données de BCP47/RFC4645/RFC4646/RFC4647, et les bons conseils de leurs auteurs à l'IETF, ou contributeurs et participants des listes de discussions et groupes de travail LTRU, CLDR/TC, Unicode/TC, et ISO 649/TC; ainsi qu'en France de chercheurs et normalisateurs à l'INSEE et à l'AFNOR; et des groupes de travail collaboratifs travaillant sur la localisation dans IBM ICU, Google Chromium, Apple WebKit, et MSDN France), car l'identification précise des langues et dialectes et variétés dans le cadre des normes futures en préparation et de la compatibilité est une chose plus que délicate à anticiper pour maintenir aussi la compatibilité et la stabilité de la codification. J'ai maintenant une vue très claire sur ISO 639-5, ISO 639-6, les évolutions prochaines de la base Ethnologue, et du futur de BCP 47 et son intégration dans les futures versions du CLDR et dans les normes du Web comme HTML, XML et MIME qui concernent maintenant toutes les applications : les RFCs constituant la BCP 47 de l'IETF sont maintenant la norme à suivre, et non l'ISO 639 directement, ni aucune autre des normes ISO référencées indirectement par BCP 47 (et même l'ISO en convient: il a commencé à appliquer aussi les règles de stabilité établies dans BCP 47 via le registre IANA des labels de langue).

Tôt ou tard, même Wikimedia y viendra aussi sur tous ses projets et changera ses codes interwikis incompatibles (il a déjà commencé...), mais il restera le fait qu'un même wiki gérera plusieurs codes langues dans un seul code interwiki, et qu'un système d'alias restera nécessaire (ce système d'alias doit aussi à terme être compatible BCP 47). verdy_p 29 novembre 2008 à 06:30 (UTC)

supp

Salut, pourrais-tu préciser pourquoi tu demandes la suppression de cette catégorie et des catégories en rapport avec celle-ci ? Elle est vide, a-t-elle été remplacée ? Plus généralement il serait sympa que tu mettes un commentaire lorsque tu utilises le modèle "supp", ça permet de ne pas avoir à enquêter (ou alors ça faciliterait l'enquête) pour savoir s'il n'y a pas d'erreur... D'avance, merci ! Markadet∇∆∇∆ 23 novembre 2008 à 23:39 (UTC)

C'est une famille de langues (au pluriel). Pas une langue utilisable pour les articles. Je veux éviter qu'on y mettre des mots sans préciser une langue correcte...

Déjà cette catégorie (catégorie:créole ou pidgin de l’anglais) est vierge, et donne de mauvais conseils. verdy_p 23 novembre 2008 à 23:41 (UTC)

Si elle doit être recréée, elle sera au pluriel, comme les autres familles de langues pour lesquelles on pourra sous-catégoriser les langues individuelles (car il y en a beaucoup maintenant et la recherche par nom uniquement n'est pas aisée). verdy_p 23 novembre 2008 à 23:44 (UTC)

OK d'accord (je voulais citer le nom de la categ : Catégorie:créole ou pidgin de l’anglais, malencontreusement effacé de mon message, mais je vois que tu as compris). Je supprime. Bonne continuation. Markadet∇∆∇∆ 23 novembre 2008 à 23:46 (UTC)

kali’na

Sauf erreur de ma part, il n'y a pas les modèles pour cette langue (code car je crois).

Il y a un mot à faire, cf étymologie de tapirer. Merci. --Szyx 25 novembre 2008 à 15:48 (UTC)

En l'absence de modèle, et dans le doûte sur le code à utiliser, il vaut mieux simplement créer un modèle du nom de la langue (avec au moins 5 caractères), et si on ne sait toujours pas comment faire pour tout paramétrer, on peut déjà utiliser le modèle du latin (un des modèles les plus simples) comme base pour créer le sous-modèle "/type". Au pire on met dans le modèle de base uniquement le nom, en n'oubliant pas de le catégoriser pour le retrouver facilement plus tard.

Note : je trouve dans l'ISO 639-3 le nom "kalinga" (nom en anglais), je ne sais pas si cela désigne la même chose; en tout cas il s'agit d'une famille de langues philippines, ce n'est pas assez précis dans ce cas.

Réf. : http://www.sil.org/iso639-3/codes.asp?order=reference_name&letter=k

Le modèle {{car}} (kali’na) existe aussi déjà. Et The Ethnologue mentionne les noms "Caribe, Cariña, Kalihna, Kalinya, Galibi" pour le Venezuela. Faut-il rajouter des synonymes ?

verdy_p 25 novembre 2008 à 20:09 (UTC)

Selon tes précisions, j'ai modifié un peu le modèle kali’na qui était basé sur les infos partielles de l'ISO 639-2 uniquement, en regardant les entrées et descriptions de The Ethnologue. Le terme défini est bien "caribe" (parlé aussi en Guyane française, Guyana, Surninam, et au Brésil). verdy_p 25 novembre 2008 à 20:21 (UTC)

Cependant le mot "caribe" n'est pas assez précis, bien que cité comme "synonyme". Il faudrait voir si le code "car" n'est pas une langue collective, et utiliser des sous-codes pour l’étymologie mais pas pour le classement des articles du Wiktionnaire (si j'en juge par la classification des langues caribes sur Wikipédia. En attendant, sur le Wiktionnaire, seul "kali’na" a une définition, et un article dédié sur Wikipédia... verdy_p 25 novembre 2008 à 20:37 (UTC)

Selon l'ISO, toutes ces langues sont des dialectes d'une même langue individuelle (et les Kali’nas sont éparpillés dans diverses zones). The Ethnologue mentionne :

Their own name for the language is 'Kari'na auran', 'Kari'na' for the people. The name in Dutch is 'Kara'ibs', in French 'Galibi', in Spanish 'Caribe', in English 'Carib'.

Il distingue donc le nom du peuple (les "Kali’nas" du nom de leur langue (il mentionne encore "galibi" pour le français, et "carib/caribe" pour l'anglais et l'espagnol bien que ce dernier terme existe aussi en français sous sa forme ambiguë). Le terme "galibi" serait bien obsolète, mais il figure parmi les synonymes que j'ai mis.

verdy_p 25 novembre 2008 à 20:42 (UTC)

Pour les modèles, je cherchais en fait {{=car=}}. Merci à toi pour tout ce travail. --Szyx 25 novembre 2008 à 20:46 (UTC)

Réflexion faite, "caribe" est bien le terme à utiliser principalement (cf. l'article "langues caribes" de Wikipédia)... Il est bien considéré comme langue individuelle (faute d'autres précisions) applicable à toutes les langues caribes (considérées comme dialectes). Notre référence de base reste quand même l'ISO 639. Si on veut utiliser uen étymologie plus précise, je ne vois pas comment éviter l'utilisation d'un sous-code (de type "car-kal"). À surveiller quand d'autres cas se présenteront. verdy_p 25 novembre 2008 à 20:57 (UTC)

Une question se pose: pourquoi as-tu besoin de =car= si ce n'est pour créer une entrée distincte dans le dictionnaire, alros que la seule chose que tu as c'est une étymologie, pas une définition du terme adapté dans la langue. Il n'est pas impossible d'ailleurs que le terme "tapiré" indiqué dans l'étymologie soit exactement celui en langue caribe, et que ce terme soit en fait applicable à toute une série de langues caribes. dans le doûte je m'abstiendrait de le définir, et dans ce cas on n'a pas encore besoin d'une section =car= sur un terme d'orthographe exacte inconnue (donc dont l'article à créer serait mal nommé et mal classé). Souvent les étymologies sont imprécises et insuffisantes pour définir une langue exactement. Au mieux elle peut seulement préciser une origine ethnique (pas nécessairement pour préciser la langue).

Aussi je pense que je vais revenir au terme "caribe" pour la langue (en laissant "kali’ga" parmi les autres noms possibles qui semblent plutôt désigner une ethnologie plus qu'une véritable étymologie ; cela me conforte aussi dans l'interprétation des références de The Ethnologue qui ne le mentionne que comme une variété dialectale et pas une langue.) verdy_p 25 novembre 2008 à 21:34 (UTC)

modification de {{trad}}

Salut !

J'ai vu tes modifications du modèle trad, et je ne comprend pas très bien ce que tu veux faire avec les paramètres lang-s, lang-t et lang-R. Tu as des exemples où ils sont utiles ? Koxinga 30 novembre 2008 à 19:41 (UTC)

Oui car cela ne concerne pas que le chinois, mais aussi ses différentes langues qui ont des codes différents. De plus la cible de leur lien en interwiki ne correspond pas toujours à un code langue standard du web, ou bien le code interwiki n'est pas celui de la langue indiquée. Cela concerne en fait la majorité des macro-langues qui ont des langues nidividuelles, et tous les codes de dialectes.

Au passage j'ai sorti l'aide de ces modèles, afin de les documenter mieux qu'ils n'étaient.

Une modif que je doit finir est aussi la conversion des codes langues en codes interwikis utilisables et la détection des codes langues qui n'ont pas de code interwiki associé (le support est presque fini pour ça.

Cette modif fait déjà la préparation et corrige aussi l'affichage correcte des langues nécessitant des polices spéciales paramétrées en CSS par une classe de type lang-xxx). J'ai enfin l'affichage correct de toutes les écritures (car une liste unique de police pour toutes les écritures ne marche pas comme il faut à cause de conflits entre polices, dont certaines implémentent seulement partiellement une écriture: pour cela on doit indiquer explicitement les codes BCP 47 de langue standards du Web et non les codes interwikis et pas non plus n'importe quel code ISO 639. verdy_p 30 novembre 2008 à 19:51 (UTC)

J'ai vu que tu as aussi amélioré l'aide, tu as fait plein de bonnes modifications. Avoir des codes tels que zh-wuu-Hans, zh-yue-Hant, c'est sûrement une bonne idée dans l'absolu mais je ne suis pas sûr que cela soit possible de demander à l'utilisateur de taper : {{trad|wuu|吴语|R=...|lang-R=zh-wuu-Latn|lang-s=zh-wuu-Hans}}. Koxinga 30 novembre 2008 à 20:19 (UTC)

Non, les codes BCP 47 recommandés ne sont pas ceux là! De toute façon il ne s'agit pas de demander à l'utilisateur de taper ces codes. C'est et cela restera une cuisine interne.

De plus je compte bien unifier trad/défaut et trad/zh e un seul modèle, le switch présent dans les modèles trad, trad+ et trad- pouvant être évité totalement pour appeler directement un seul modèle. Enfin trad/zh est tel qu'il devrait fonctionner aussi pour supporter les langues japonaises, et aussi le coréen traditionnel ou d'autres langues à orthographe traditionnelle (dont l'arabe, l'hébreu, le copte, etc...) et supportant aussi des romanisations (russe, bulgare, serbe, etc...).

Pour te convaincre de l'utilité, il suffit de voir une page où figure pleins d'écritures différentes: cela affiche maintenant correctement le géorgien Khoutsouri, le chinois traditionnel (qui ne marchait pas complètement), les langues brahmiques, le cherokee, les langues amérindiennes utilisant le syllabaire canadien, l'hébreu traditionnel, etc...

• par exemple dictionnaire, janvier, encyclopédie, etc...

Notes :

• Ma page perso contient une référence à une feuille de style CSS que je maintiens depuis des mois et permettant d'afficher correctement le maximum de langues. Il est possible d'inclure cette feuille de style dans son Monobook (regarde par exemple comment j'inclue ma feuille "police.css" (stockée en fait sur Wikipédia) dans ma feuille personnelle ici.
• Si tu veux tu peux l'incure aussi dans ton propre monobook par référence (regarde comment j'ai fait dans mon monobook.css ici, dont le lien figure sur la page perso ici).
• Je m'arrange pour maintenir cette feuille en état de marche sur mon compte Wikipédia, et je la réutilise par référence dans les autres Wikis où j'en ai besoin, plutôt que de la copier et de devoir la maintenir partout. Une telle feuille de préférences de polices est le fruit de longues recherches et d'essais. L'ordre des polices n'est pas du tout indifférent, et il y a plein de commentaires qui recensent les problèmes rencontrés avec différentes polices.
• Si tu as des suggestions de polices pour d'autres écritures je suis preneur (mais évite de toucher à ma feuille polices.css sur Wikipédia, si tu veux faire des essais, copie la dans ton propre fichier. Attention la syntaxe pour importer une feuille de style sur un wiki de Wikimedia est très pointilleuse, la moindre erreur fait que cetet feuilel ne se chargera pas sur tout !
• Cette feuille de polices fonctionne sous IE 6, IE 7, IE 8/Vista, Firefox, Opéra, Safari, Google Chrome et tous les navigateurs "réemballés" basés sur IE, Gecko ou WebKit (dont AOL). Elle est testée sur Windows XP, Vista, un peu sous Linux et sur Mac. verdy_p 30 novembre 2008 à 20:35 (UTC)

Bon, d'accord, je ne connais pas les bons codes ;o) Je te fais confiance sur le sujet, tu as l'air de t'y connaitre mieux que moi. Si tout est automatisé, pas de souci, je ne savais pas que ce n'était qu'une version intermédiaire d'un travail en cours. Mais quid des gens qui se plaignaient déjà de la complexité du modèle trad ? Et qu'est-ce qu'il y avait comme problème avec le chinois traditionnel ? (simple curiosité, je pensais avoir bien fait en mettant des <font lang="zh-Hant"> et <font lang="zh-Hans">) Koxinga 30 novembre 2008 à 21:21 (UTC)

Oui on peut utiliser font lang, mais la balise font est obsolète et pas faire pour ça (utiliser plutôt span).

Le code zh-Hans ou zh-Hant convient assez bien mais cela reste un code générique pas adapté à toutes les langues chinoises. Selon BCP 47, et ISO 639 le véritable code du chinois mandarin est cmn (lequel devient par défaut un alias de zh dans BCP 47, et par voie de conséquence aussi dans les codes de locales pour CLDR, puisque le mandarin est la langue majoritaire de la macrolangue chinoise). Ceci fait que les codes exacts sont normalement cmn-Hans et cmn-Hant pour le mandarin (lesquels deviennent automatiquement aussi des alias de zh-Hans et zh-Hant. Mais zh-Hans et zh-Hant ne sont plus valides pour désigner autre chose que le mandarin en tant que codes langue BCP 47, même si zh est un code générique dans l'ISO 639.

Par soucis de clarté et conformité avec les normes du web, les codes BCP 47 (enregistrés dans la base de donnée IANA et documentés dans les RFC 3066, 4645-4647 et leur révisions "bis" en cours d'achèvement) sont ceux à utiliser en priorité (en laissant de côté des codes ISO 639 ambigus, obsolètes, redondants voire multiples, mais encore conservés pour des raisons historiques, selon les définitions et règles énoncées dans les RFC citées). On devrait absolument éviter ISO 639 comme source première (il faut passer par le filtre intermédiaire de BCP 47 qui en assure la stabilité et l'exactitude), même si on peut garder des redirections pour certains codes (non préférés) supportés par BCP 47 mais qui sont des alias, et n'ont pas la même étendue que ce que laisse supposer l'ISO 639. verdy_p 30 novembre 2008 à 21:36 (UTC)

Ah, et maintenant mes pinyins sont tout moches, c'est quoi la commande magique pour qu'ils soient dans la même police que le texte normal ? Koxinga 30 novembre 2008 à 21:22 (UTC)

Non ils sont exacts, et supportent GB18030 et pas seulement GB2312 avec les polices par défaut de Windows. L'ordre utilisé est spécifique par langue. Ceci dit, si tu as des préférences pour le chinois spécifiquement regarde les classes ".lang-zh", .lang-zh-Hans et .lang-zh-Hant, dans "polices.css", on n'a peut-être pas les mêmes préférences. Dans ce cas copie ma sous-page "/polices.css" chez toi pour faire la modif selon tes préférences, ou ajoute tes propres règles après avoir importé mon fichier dans ton monobook.css pour les modifier chez toi sans avoir à tout recopier. verdy_p 30 novembre 2008 à 21:36 (UTC)

Note: le chinois nécessite des polices forcément différentes de la soit-disante police "normale". Les polices chinoises sont afreuses en caractères latins, et sont très lacunaires pour le latin, le grec et le cyrillique, et supportent encore moins l'API ! verdy_p 30 novembre 2008 à 21:38 (UTC)

Oui oui, je voulais dire après avoir copié ton polices.css. J'ai l'impression qu'il utilise les polices chinoises pour zh-Latn. Mais je vais bidouiller un peu pour changer ça parce que ce n'est vraiment satisfaisant. Ça doit être qu'il me manque des polices par rapport à ta feuille, je ne peux pas imaginer que tu préfères ça ;o) Koxinga 30 novembre 2008 à 22:03 (UTC)

Note: je n'ai pas personnalisé la classe "lang-zh-Latn", donc il utilise la première liste générale où le latin est listé en premier pour utiliser des polices latines de qualité en priorité sur toutes les autres. De ce fait, il n'est pas nécessaire de faire cette spécialisation, et chez moi sur tous les navigateurs que j'ai testés, je n'ai JAMAIS aucune affreuse police chinoise pour afficher le chinois romanisé (en Pinyin, Yale ou autres) ou le Minnan (qui nécessite des polices latines étendues). verdy_p 1 décembre 2008 à 06:24 (UTC)

Verdy écrit 314 lignes de commentaire quand 0,707 suffisent. Pardonne lui. --Szyx 30 novembre 2008 à 21:27 (UTC)

En plus il fait semblant de ne pas avoir vu mon commentaire... pffffffffff... Voir le bandeau sur ma pu. --Szyx 30 novembre 2008 à 21:41 (UTC)

Je ne faisais pas semblant, ton message a été posté pendant que je composais une autre réponse. (du coup ma réponse est partie après ton message. C'est quoi ton problème de bandeau? verdy_p 30 novembre 2008 à 21:46 (UTC)

Une dernière question et après je vais me coucher ;o) À quoi sert le code zh-Hani ? Une rapide recherche sur Google ne me donne qu'un message de toi sur une mailing-list, donc tu es sûrement un expert maintenant. Est-ce qu'on peut s'en servir pour indiquer qu'un caractère est le même en simplifié et traditionnel (et donc pouvant utiliser la police par défaut de l'utilisateur par exemple). Je vais ajouter des codes de langue sur les modèles que j'ai créé pour le chinois, mais pour un mot qui est à la fois en traditionnel et simplifié, je ne sais pas quel code choisir. Koxinga 30 novembre 2008 à 23:33 (UTC)

zh-Hani ne sert à rien (même s'il reste autorisé dans la norme BCP 47) car ça indiquerait seulement que c'est une écriture idéographique, sans préciser si c'est une graphie traditionnelle ou simplifiée (ou encore Kanji en japonais, Hanja en coréen, ou plus rarement Chunhom en vietnamien...).

Le code d'écriture ISO 15924 Hani pourrait éventuellement servir pour le japonais, le coréen ou le vietnamien qui n'utilisent qu'une seule forme (traditionelle) s'ils sont écrits uniquement en idéogrammes sans aucune une forme moderne (ja-Hrkt pour le japonais simplifié écrit en hiragana et katakana sans aucune forme traditionnelle kanji, ja-Hira pour le japonais simplifié en hiragana uniquement et peu utilisé, ja-Japn pour l'écriture habituelle, ja-Hani pour le japonais traditionnel, ko-Hani pour le coréen traditionnel en Hanja uniquement, vi-Hani pour le vietnamien en Hanzi)

Noter quand même que bien que le chinois mandarin (cmn, alias zh) utilise Hans par défaut, ce n'est pas le cas pour toutes les langues chinoises comme le cantonais (yue alias zh-yue) ou le wu (wuu alias zh-wuu) et d'autres langues chinoises minoritaires du Sud de la Chine qui utilisent plutôt les formes traditionelles (Hant), sauf le Minnan (nan, alias zh-min-nan) dont l'écriture par défaut est latine même si leur code peut être attaché au code zh parent (les formes zh-wuu, zh-yue, zh-min-nan ne sont plus recommandées, ce sont maintenant des alias de codes complets pour lesquelles la forme canonique ne comprend plus de préfixe "zh" ni aucun sous-code, mais seulment le code ISO 639-3).

Le code d'écriture Hani peut être considéré comme un alias de Hant pour toutes les langues autres que les langues chinoises (puisque pour la macrolangue chinoise [zh] et aussi plus spécifiquement pour le mandarin [cmn], la valeur par défaut est Hans, simplifiée). Il est surtout utilisé pour les textes codés pour lesquels on ne sait pas si la forme est simplifié ou traditionnelle, et quand les deux possibilités existent (donc uniquement pour les langues chinoises, donc pas pour le japonais, le coréen ou le vietnamien), ou quand la langue est inconnue (textes codés en idéogrammes sans indication de la langue: ce code Hani sert dans les tables de caractères unifiés d'Unicode).

Note: un caractère sinographique n'est pas un caractère "chinois"; il serait incorrect d'utiliser "zh-Hani" car ce serait appliquer une restriction de ce caractère aux seules langues chinoises, même si sa forme est invariante entre écritures traditionelles et simplifiée. En lui-même le caractère seul est intraduisible, donc il n'y a aucune raison d'utiliser zh-Hani dans les traductions ou pour les textes comme les citations et titres d'œuvres. Pour annoter les caractères, on utilise ici le pseudo-code langue "conv"(local) et l'entête de section {{caractère}} dans lequel on indique les transcriptions possibles (traditionnelle, simplifiée, Kanji, Hanja, Kangxi, décompositions en clés et nombre de traits, transcriptions en syllabaires Bopomofo, Yi ou Hiragana/Katakana, ou transcriptions latines Pinyin, Romaji, etc.). verdy_p 1 décembre 2008 à 06:06 (UTC)

À vrai dire, je m'intéresse pour l'instant plus spécifiquement au chinois mandarin. J'ai créé des modèles, un pour lier les versions traditionnelles et simplifiées d'un même mot, et un pour dire que le mot est le même dans les versions traditionnelles et simplifiées. Je me demandais quel code utiliser dans ce deuxième cas. Le plus simple serait d'utiliser zh-Hans, mais si un utilisateur préfère le chinois traditionnel et a par exemple une police spécifique, il n'y a aucune raison de le forcer à utiliser une police de caractères simplifiés alors que les caractères existent dans sa police préférée.

Tu dis que le japonais n'a aucune forme moderne, ce n'est tout simplement pas vrai.

Tu m'as mal lu, je n'ai jamais dit ça ! Au contraire j'ai bien cité plusieurs écritures possibles pour le japonais, y compris pour les formes modernes (à base alphasyllabaire, voire même maintenant de plus en plus souvent alphabétique sous l'influecne de l'anglais et de l'internationalisation, en commençant par les marques et noms propres, mais aussi dans le vocabulaire technique spécialisé, directement repris de l'anglais et qui est de moins en moins retranscrit en kanas, à cause des nombreuses ambiguités que cela génère). verdy_p 1 décembre 2008 à 10:20 (UTC)

Oui, oui, je connais les hiraganas et katakanas, mais tu dis "le japonais, le coréen ou le vietnamien qui n'utilisent qu'une seule forme (traditionelle)" Même en restant dans les kanjis, il y a eu des réformes. Parfois calquées sur la simplification effectuée en Chine, parfois spécifiques au Japon. Par exemple, si je ne dis pas de bêtise, ce caractère traditionnel en:蠟 a donné en:蝋 en shinjitai et en:蜡 en simplifié. Koxinga 1 décembre 2008 à 10:34 (UTC)

Il n'y a pas eu de simplification à l'échelle de la république Populaire de Chine, mais il y a eu des réformes (les w:shinjitai étant les formes simplifiées des w:kyūjitai). Est-ce que c'est pris en compte ?

J'ai pris en compte la possibilité d'une seule orthographe traditionnelle par langue, mais pas le fait qu'il puisse y en avoir plusieurs.

Ce qui peut être fait pour le japonais c'est de lister séparément les orthographes en kana (deux possibles) et celles en sinogrammes (deux possibles aussi) dans deux lignes de traduction différentes (ja-Hrkt et ja-Hani).

Mais si maintenant même les formes sinographiques ont plusieurs graphies, il faudra les lister séparément côte-à-cote (séparées par une virgule sur la même ligne de traduction et avec le même code, chacune suivie dune note entre parenthèses pour lever l'ambiguïté possible), car on ne va pas multiplier le nombre de variantes idéographiques pour ces quelques cas qui doivent être assez rares où il y a plus de deux formes sinographiques, et qui doivent en plus certainement utiliser des caractères codés différemment (je n'ai rien vu dans Unicode mentionnant une unification de plus de formes que deux pour les sinogrammes, d'une façon nécessitant une interprétation ou une prononciation différente) .

D'ailleurs il faut noter que certaines de ces variantes ne sont pas pour le japonais standard, mais pour certains dialectes ou d'autres langues japonaises minoritaires comme l'aïnou ou le sakhalien, qui ont leur propre code langue, mais je n'ai pas vu de tentative d'unification des sinogrammes spéciques à ces langues et dialectes (malgré tout des polices spécifiques pour ces langues minoritaires peuvent exister si vraiment ces formes sont préférables aux formes sinographiques du japonais standard pour les mêmes caractères unifiés, mais pour l'instant je ne connais pas l'existence de telles polices, donc pas de raison de les spécialiser pour l'instant). verdy_p 1 décembre 2008 à 10:43 (UTC)

Transcriptions et autres métadonnées sur les mots ou caractères à référencer et indexer

Pour l'instant, on ne place pas les transcriptions possibles dans la section {{caractère}} mais dans les différentes sections de langue. Cela me semble plus logique mais si tu as des arguments forts pour que l'on change cela, on peut en discuter, je compte faire passer un bot sur tous les sinogrammes donc c'est le moment de préparer. Dans la section {{caractère}}, il y a pour l'instant des informations sur le classement du caractère (nombre de traits, clef, place dans les dictionnaires, code Unicode) et des informations graphiques (étymologie, tracé).Koxinga 1 décembre 2008 à 10:16 (UTC)

Tu noteras que la place dans les dictionnaires modernes phonologiques (par. ex. classement par romanisation pinyin, Yale et autres...) est très fortement liée à la langue pour laquelle ces dictionnaires ont été écrits, au contraire du placement dans les dictionnaires traditionnels morphologiques (par radical/clé et traits) qui est nettement plus générique. Cela peut justifier de ne pas tout mettre dans la section caractère, et en tout cas pas la transcription en pinyin ou bopomofo (pour les langues chinoises), le romaji ou les kanas (pour le japonais seulement), la transcription hangûle (pour le coréen seulement), ou la transcription latine tonale (pour le vietnamien moderne)... verdy_p 1 décembre 2008 à 10:55 (UTC)

Avant de passer ton robot sur les sinogrammes, peut-on envisager de leur générer aussi des clés de tri utilisables pour pouvoir les rechercher dans les catégories autrement qu'en connaissant leur code exact ?

Ne serait-il pas souhaitable de les trier au minimum dans une romanisation (pinyin?) Quitte à offrir d'autres classements intermédiaires via des sous-catégories d'une catégorie spécifique (par exemple via une catégorie listant uniquement les clés Han, chacune dans leur propre sous-catégorie où les articles peuvent rester triés en pinyin par leur clé de tri par défaut). Dans ce cas, il faudrait donc générer quelquechose comme :

{{clé de tri|<transcription latine en pinyin>}}

[[Catégorie:Sinogramme clé <clé han>]]

voire aussi (en fonction des langues présentes dans l'article):

[[Catégorie:{{zh}} par clé <clé han>]]

[[Catégorie:{{ja}} par clé <clé han>]]

etc. (cependant ces catégorisations supplémentaires devraient mieux être générées par un sous-modèle inséré dans les sections de chaque langue, et générant les infos grammaticales ou propres à chacun de leurs dictionnaires: la clé han dans ce cas devra être passée en paramètre.

L'autre solution (intéressante d'un point de vue formel) serait de stocker la clé dans une sous-page de métadonnées pour l'article, et possédant un nom de sous-page standardisé (par exemple "/Méta" voire "/.méta" pour éviter tout conflit), ce qui permettrait de ne plus se trimbaler les paramètres supplémentaires dans les appels de modèles, car les modèles insérés dans les sections de langues peuvant eux-mêmes consulter une sous-page de métadonnées (laquelle peut fonctionner également comme les sous-modèles "Modèle:xxx/type" des modèles de langue "Modèle:xxx", en faisant un switch sur le type de métadonnée demandée, et fournir une page d'aide générique sur les types supportés et les valeurs à renseigner si différentes des valeurs par défaut, comme je l'ai fait dans les modèles de langue).

Il ne resterait alors plus, dans les articles, qu'à passer QUE le paramètre de code langue dans les sous-modèles, tout le reste pouvant être lu depuis les métadonnées (dont les types pour la sélection peuvent contenir ce code langue). Et les robots seraient les mieux à même de générer les pages de métadonnées.

Parmi les métadonnées que les robots devraient pouvoir utiliser et générer facilement : les conjugaisons et flexions individuelles, les clés de tri pour diverses langues (un moyen de régler le tri spécifiquement pour les catégories en espéranto), des notations de suivi du contenu ou de la qualité.

L'idéal serait que les sous-pages de métadonnées puissent disposer d'un espace de nommage spécifique et qu'on ne soit pas obligé d'écrire soit-même le switch en code Wiki, ensuite ces pages auraient leur propre éditeur, sous forme d'une table, même si en fin de compte cela stocke un switch dans le code Wiki de la page.

Note : ces pages ou sous-pages devraient aussi être renommées en même temps que l'article sur lequel elles portent (actuellement quand on renomme une page, cela renomme aussi que sa page de discussion associée dans un autre espace de nom, mais pas les sous-pages) : c'est un problème général de MediaWiki (qui a pourtant été réglé pour l'espace de nom principal sur Wikipédia).

Si on avait cet espace de nommage spécifique, avec son éditeur dédié (pour ne plus avoir à saisir le code du switch pour le premier paramètre indiquant le type de méta données demandée, on pourrait alors avoir tout simplement un onglet supplémentaire en haut des pages d'articles et menant vers la page de métadonnées ou permettant de la créer (avec en plus une page d'aide générique ou personnalisable indiquant comment les renseigner chacun des types supportés !

En fait, toute page wiki qui commencerait par un switch sur la valeur du seul premier paramètre (et rien d'autre avant ou après que des balises includeonly ou /includeonly, ou une section noinclude.../noinclude) pourrait utiliser cet éditeur générant le code Wiki du switch automatiquement, mais présentant les données sous forme d'une table, dont la dernière ligne contiendrait la valeur par défaut (qui peut être vide, ou peut être un "?" si la valeur vide est signifiante et ne doit pas générer d'autres valeurs par défaut dans un modèle utilisant les métadonnées).

Que penses-tu de tout ça ? verdy_p 1 décembre 2008 à 11:11 (UTC)

Je vais répondre en plusieurs parties :

• Tout d'abord, avec les solutions techniques existantes :
  • Clé de tri est inutilisable en l'état. Pour un mot en sinogrammes donné, qui peut concerner pas mal de langues différentes, ce n'est pas possible de classer par un système de romanisation. Tu imagines la catégorie « Fleurs en japonais » rangée par pinyin ? Une solution par radical et nombre de traits supplémentaire n'est pas très satisfaisante non plus, mais est très facile à implémenter.
  • Pour des catégories spécifiques à une langue, on peut utiliser une romanisation. Par exemple le pinyin pour le mandarin, comme quasiment tous les dictionnaires actuels. Cependant, même si on met les pinyins en clef de tri, ils ne sont pas visibles dans l'affichage de la catégorie (on ne voit que la première lettre), donc si on ne connait que peu de caractères, c'est très pénible de savoir où on en est. J'ai commencé à trier par pinyin dans les catégories spécifiques au mandarin (par exemple Catégorie:Mandarin élémentaire) mais tu peux voir que ce n'est pas la panacée, alors qu'il n'y encore que très peu de caractères. Si je met tous les sinogrammes présents sur le site, dont 90% sont d'obscures variantes que personne ne connait, trouver un caractère parmi cette liste va devenir très sportif, même en sachant qu'ils sont théoriquement rangés par pinyin.
  • En gros j'ai abandonné l'idée d'une clef de tri et je pense que les gens cherchant un caractère sans savoir l'entrer au clavier ( sinon il suffit d'utiliser le champ recherche du wiktionnaire, c'est ce que je fais quasiment tout le temps) devraient plutôt utiliser les pages Wiktionnaire:Sinogrammes - Index des radicaux, Wiktionnaire:Sinogrammes - Index Pinyin, etc., que j'essaie de remettre un peu en forme. Alors oui bien sûr c'est très chiant quand on trouve une erreur de la corriger dans les listes, mais en terme de mise en page, c'est incomparablement plus puissant.

---

• Une page de méta-données. C'est une idée sympa, il faudrait faire des tests. Tu as le courage ? Si j'ai le temps, j'essaierais bien deux ou trois trucs sur mon wiki perso mais j'ai déjà beaucoup trop de projets en ce moment.
• Pour les modifications logicielles, on parle à très long terme, c'est plutôt utopique quand on voit comme il est difficile de faire bouger mediawiki, surtout si le projet anglophone n'est pas intéressé. Cependant, le renommage n'est pas très important pour des pages consacrées à des sinogrammes. Après, des champs pour remplir les différentes données, ça serait vraiment bien. Je me demande si on ne peut pas le faire en javascript ;o) Koxinga 1 décembre 2008 à 14:22 (UTC)

La page de métadonnées peut être implantée même sans modification du logiciel (si je propose une éventuelle modification c'est pour rendre son édition plus facile, mais ce n'est pas une condition nécessaire pour pouvoir utiliser la technique.

Avec cette page de métadonnées, les modèles pourraient effectivement trier les catégories langue par langue au lieu d'utiliser une clé de tri unique pour toutes les langues. Cela remplace l'autre idée que j'avais d'utiliser des variables contextuelles (par section) puisque le contexte de la page courante suffit pour pouvoir mettre des données propres à chaque langue, telles que des clés de tri spécifiques (espéranto, pinyin, radical).

Je peux faire une démonstration dans un ou deux articles pour montrer ce que cela donnerait, mais pour une implantation complète, cela demanderait de retoucher les modèles -nom-, -verb-, etc., pour qu'ils sachent aller chercher la clé de tri dans la page de métadonnées si elle existe.

Cela n'exclue pas que, si ces modèles de sous-section grammaticale (ou les modèles lexicaux) ne trouvent pas de sous-page de métadonnées, ni de clé spécifique pour une langue, alors il n'indiquent aucune clé dans les catégories que ces modèles génèrent, mais laissent alors la clé de tri par défaut, telle que déjà indiquée avec {{clé de tri}} en bas des pages (ce qui limitera le nombre d'articles à retoucher). Bref les métadonnées peuvent être utilisées pour gérer les exceptions uniquement.

Note : l'idée de maintenir des pages d'index pour le chinois ne me plait pas du tout. C'est impossible à maintenir, et ça donnera forcément des pages énormes et une quantité impressionnante de pages plus à jour, alors qu'il semble plus simple de simplement éditer une très courte sous-page contenant le pinyin, le radical et le nombre de traits des caractères chinois, puis pour tous les autres mots et expressions chinoises (ce qui peut se faire par bot qui peuvent concaténer les clés).

Même la génération des toutes petites sous-pages de métadonnées pour les caractères chinois peut se faire par Bot (en utilisant le fichier Unihan fourni par Unicode comme base).

verdy_p 1 décembre 2008 à 17:09 (UTC)

En fait, plus j'y pense et plus c'est compliqué. Par exemple, il peut y avoir plusieurs pinyins pour un seul caractère en mandarin, car il y a plusieurs prononciations. 还 (hái) veut dire « encore » et 还 (huán) veut dire « rendre ». Dans ce cas, on ne peut extraire automatiquement une clef de tri. Il faudrait le trier sous [[:Catégorie:Verbes en mandarin|huan2]] et [[:Catégorie:Adverbes en mandarin|hai2]]. Ce n'est pas la majorité des caractères mais de tels cas ne sont pas rarissimes.

Le nombre de trait et la clef peuvent être décidés de manière unique. Le nombre de trait fait globalement consensus, je ne crois pas qu'il y ait beaucoup de caractères où deux dictionnaires différents ne soient pas d'accord. La clef est un choix arbitraire. Ici on a suivi Unicode pusque leurs données sont disponibles, ce n'est pas mon classement préféré, mais pourquoi pas.

On peut donc se servir de ça pour classer les caractères. Le seul problème, c'est que cela donne l'impression que le wiktionnaire a cinquante ans de retard et que les catégories ne sont pas adaptées du tout à la navigation dans ce genre de liste. Moi non plus sur le principe je n'aime pas les grandes listes faites par un bot et modifiées à la main, mais pour l'instant, je ne vois pas d'alternative viable. Et on n'a pas tant que ça à les modifier, Unihan est quand même plutot fiable, très très complet, et on n'a aucune raison de supprimer des caractèrs.

Mediawiki n'offre pas la souplesse nécessaire pour un traitement de ce genre, je ne vois pas comment générer à la volée une liste comme celles que l'on a ici : Wiktionnaire:Sinogrammes - Index Pinyin, où certains caractères apparaissent plusieurs fois, où il faut répéter le pinyin à chaque fois qu'on en change puisque l'ordre alphabétique est utilisé mais invisible, etc.

(Je suis désolé du vandalisme, Firefox a planté et m'a remis le champs d'édition quand il a redémarré, mais il avait dû passer de la section à la page entière, ou un truc bizarre comme ça). Koxinga 2 décembre 2008 à 17:42 (UTC)

N'oublie pas qu'il n'y a pas que les caractères à indexer: il y a aussi les expressions, et les mots qui s'écrivent sur plusieurs caractères. Et pour eux, la table UniHan, qui n'est pas si stable que tu le crois car elle a de TRES frequentes mises à jour et est TRES loin d'être complète (même pour les seuls caractères isolés) ne proposera rien.

Ta liste sera donc nécessairement énorme. Tellement qu'en fin de compte il faudra l'éclater, et il se reposera la même question de comment catégoriser et indexer ces listes! 'est bien pour ça que je penses qu'une solution à l'aide de métadonnées (qu'on peut, je l'ai déjà dit plus haut, stocker dans une sous-page, éventuellement unique (pour chaque page à renseigner) pour contenir plusieurs types de métadonnées (pour cette sous-page, il suffirait d'un simple switch, à défaut d'avoir un support mieux intégré dans MediaWiki).

Si seulement on pouvait même intégrer les métadonnées dans les articles eux-mêmes (avec une syntaxe permettant de les reconnaitre et les indexer de la même façon que les actuelles multiples catégorisations qui ne sont qu'un type, très faible, de métadonnées)...

Si l'idée des sous-pages de métadonnées ne convient toujours pas, il reste le système des catégories, pour lequel il existe déjà des outils utilisables par les Bots, capalbles de créer des catégories selon une convention de nommage, et de catégoriser des listes de pages dans ces catégories, sans même trop regarder le reste de la syntaxe de la page.

Note: je ne propose PAS de créer des sous-catégories par type de caractère dans les catégories thématiques. C'est contre-productif dans le système hiérarchique actuel. Notre problème reste que même les catégories thématiques ne sont pas utilisables pour les articles de titres écrits en sinogrammes, et c'est pour cela qu'il faudrait pouvoir trier CES catégories thématiques en chinois, sans avoir à les sous-catégoriser (ce qui n'est franchement pas pratique du tout à naviguer...)

C'est un problème qui perdure depuis longtemps dans MediaWiki, où le seul type de métradonnées n'est QUE hiérarchique (les catégories) et ne permet pas non plus les recherches croisées (sauf en pasant par des sites de tiers qui proposent leurs outils de croisement de catégories). J'attends toujours (depuis longtemps) le support de plus d'un seul type de métadonnées, d'une façon qui soit accessibles aussi à nos modèles pour la génération et l'affichage des pages et modèles (qui devraient être capable de lire ces métadonnées associées aux articles).

verdy_p 2 décembre 2008 à 19:46 (UTC)

---

Ce n'est pas du tout mon but d'indexer toutes les expressions et composés sur ces pages. Les listes actuelles ne permettent de trouver que des sinogrammes isolés, et c'est bien là l'intérêt. C'est comme dans les dictionnaires "normaux", il suffit d'arriver sur le premier caractère, les composés seront présentés sur sa page.

C'est normal qu'Unihan n'ait pas beaucoup d'informations sur les composés, ce n'est pas son centre d'intérêt principal. Mais de toute façon, on ne se sert pas de leurs informations sur les mots et expressions. Cela n'aurait pas tellement de sens puisqu'il n'y a aucune définition en français et aucune information intéressante à en tirer.

Il n'y a finalement que très peu de métadonnées utilisables automatiquement. Je ne vois que le code unicode (voire d'autres codes, mais cela n'a pas grand intérêt), le nombre de traits et la clef (et le nombre de traits en plus de la clef). Je pense qu'on ne peut rien faire sur les formes alternatives, sur les formes traditionnelles et simplifiées, sur les romanisations, car il y a trop de cas particuliers.

Sur les catégories, c'est à se demander si tu lis ce que j'écris.

JE pense que je pourrais te dire la même chose, restons calme {{clin}].

Imaginons qu'on puisse faire par bot une catégorie offrant le classement voulu (pour le pinyin par exemple ce n'est pas possible, parce que certains caractères ont plusieurs prononciations dans la même langue et qu'une même page ne peut apparaître qu'une fois dans une catégorie). Qu'est-ce qu'on ferait de cette catégorie ? Tu penses vraiment qu'avec l'apparence actuelle, on peut naviguer dans une catégorie de 10 000 caractères ? La seule possibilité que je vois, c'est de faire des sous-catégories par clef, des sous-catégories par pinyin, etc. Ça serait bien lourd aussi.

NON je ne souhaite pas la création de pleins de sous-catégories. Ma proposition de métadonnées ne doit servir qu'à contenir des "variables" applicables à une page donnée, et permettant bien de stocker des métadonnées spécifiques à certaines sections, par exempel à une langue uniquement !

Finalement, on est plutôt d'accord qu'il faudrait d'autres métadonnées. Cependant, dans le cas des sinogrammes, des métadonnées par page ne serait pas suffisantes, il faudrait pouvoir définir des sections dans les pages et avoir des métadonnées n'agissant que sur une section. Cependant, je n'y crois pas avant très longtemps, et en attendant, une longue liste de caractères et des modèles un peu balourds avec plein de paramètres restent la moins mauvaise des solutions. Koxinga 2 décembre 2008 à 20:48 (UTC)

Métadonnées

Sur Meta j'ai une proposition complète en cours sur la création de variables de contexte. Pour l'instant personne ne semble intéressé.

Quant à la proposition d'un système INTEGRE de mètadonnées dans MediaWiki (avec un schéma de données et diférents types que les utilisateurs peuvent créer à loisir en fonction des besoins et non restreint au modèle hiérarchique des catégories), cela fait des années que je l'ai proposé et recitée à chaque fois comme LA solution qui permettrait de résoudre PLEINS de nouveaux problèmes d'une façon générique et non de façon spécifique avec une syntaxe ou des fonctions parseur particulières pour certains points...

Ma proposition plus complète la plus récente demande l'ajout d'une extension appelée "GlobalContextVariables"; j'en ai parlé notamment pour gérer les problèmes légaux liés à la production d'une distribution CDROM/DVD de Wikipédia ou d'une version téléchargeable, ou pour gérer les difficultés liées au contenu de certaines pages qui peuvent ne pas être désirables voire illégales dans certains pays. J'en ai parlé pour pouvoir attaché des labels de qualité ou de révision de versions stables et permettant de préparer des extraits "certifiés révisés" d'une partie des données, ou pour marquer l'état d'avancement de certaines pages.

Pour moi chaque métadonnée dans un type donnée constitue un élément à part qui devrait être éditable séparément de la page. Si plusieurs métadonnées sont liées et s'éditent ensembles, elles doivent être définies comme autant de variables typées que nécessaire pour gérer un même espace cohérent de données. De fait, ces métadonnées ne devtraient pas être DANS l'article, ni même générées par des modèles insérés dans l'article, masi devraient constituer des pages éditables séparément (et même si la page est bloquée: on peut éventuellement aussi bloquer certaines pages de métadonnées.

D'où l'idée d'utiliser des sous-pages pour stocker les métadonnées. Mais il faudrait que MediaWiki ici soit corrigé pour que le renommage des pages puisse non seulement renommer la page de discussion, mais aussi ses sous-pages (en particulier les métadonnées), ou bien renommer aussi la page homonyme dans un espace de noms préfixé par exemple "data:".

Mon idée ensuite est d'intégrer ces pages de métadonnées en montrant quand elles existent ou bien l'endroit où on peut les ajouter, en mettant un onglet "métadonnées" en haut, comme on a aussi un onglet "discussion"; sur une page de métadonnées, on pourrait ensuite développer un éditeur spécifique permettant d'éditer plus facilement une liste de variables nommées, dans un tableau à deux colonnes, sans avoir nécessairement à présenter à l'utilisateur la syntaxe Wiki utilisant

{{#switch:{{{1|}}}|variable1=valeur1|variable2a|varaible2b=valeur2|...|valeur par défaut}}

puisque cette syntaxe pourtant simple est jugée encore trop difficile à lire pour certains : à la place on aurait un tableau présentant dans une colonne les noms des varaibles de métadonnées, dans l'autre leurs valeurs, et des boutons autour de la liste pour ajouter des variables, les renommer ou changer leurs valeurs.

Cette idée peut toutefois être implémentée dès maintenant sans aucune modification de MediaWiki:

• comme on n'a pas de variables contextuelles modifiables au milieu d'un article (ce que je propose sur Meta dans "GlobalContextVariables"), on peut en revanche avoir autant de variables que nécessaire, une par langue,
• et les noms de variables (utilisés dans le switch) peuvent faire eux aussi l'objet de conventions de nommage (par exemple les clés pour le chinois pourraient être nommées "zh.xxx").
• Et nos modèles grammaticaux ou autres n'auraient pas besoin d'avoir autre chose que le seul code langue en paramètre, ce qui suffira pour générer le nom de variable de métadonnées que ces modèles peuvent aller chercher en appelant la sous-page de la même façon qu'on appelle un modèle.
• Nos modèles grammaticaux peuvent aussi déjà tester l'existence de cette sous-page, ayant un nom imposé mais dont ils connaissent au moins le nom de la page mère, sans générer aucune erreur, et ils en déduiront eux-même les valeurs par défaut si la sous-page de métadonnées n'existe pas ou ne retourne pas de valeur pour la variable indiquée.

verdy_p 3 décembre 2008 à 00:30 (UTC)

Exemple d'utilisation pour stocker les clés pinyin, ou radical/traits d'un article à nom chinois.

• On crée une sous-page nommée "/:data" qui contient simplement:

  {{#switch:{{{1|}}}| zh.radical=caractère clé Han| zh.traits=nombre de traits| zh.pinyin=romanisation pinyin| zh.clé de tri=radical-traits-pinyin| }}

• Le nombre de varaibles qu'on peut stocker dans le modèle n'est pas limité (à nous de convenir la convention de nommage des variables, et on peut aussi avoir autant de variables de clés de tri que de langues dans l'article !
• Dans le modèle appelé tel que {{-nom-|zh}} qui reçoit déjà le code langue, on peut récupérer cette clé pinyin, quand elle existe (et quand la sous-page "/:data" existe aussi) pour catégoriser l'article en chinois dans une catégorie de noms en chinois qui utilisera un autre critère de tri que celui de la clé par défaut de la page:

  {{{{#ifexist:{{PAGENAME}}/:data|{{PAGENAME}}/:data|ns:0}}|{{{1}}}.pinyin}}

  {{{{#ifexist:{{PAGENAME}}/:data|{{PAGENAME}}/:data|ns:0}}|{{{1}}}.clé de tri}}

• Cette syntaxe peut sembler lourde, et si on doit la réutiliser souvent, on peut la masquer dans un modèle utilitaire, cependant cette syntaxe est acceptable dans un modèle très utilisé et à optimiser (comme {{trad}}) si on doit éviter d'inclure un autre sous-modèle qui peut êre répété très souvent sur la même page.

Pour le modèle {{-nom-}} ou les autres comme {{-adj-}}, {{-verb-}}, il semble qu'il vaudrait mieux créer ce modèle utilitaire pour récupérer au moins la clé de tri spécifique à la langue indiquée dans la "[[Catégorie:Nom en {{1}}}]]" ou pour utiliser sinon la clé de tri indiquée par défaut en base des pages (sans indiquer de clé de tri lors de la catégorisation automatique faite par le modèle {{-nom-|code langue}}). Ce modèle utilitaire pourrait s'appeler ainsi :

{{catégorisation|Noms en {{{1}}}|{{PAGENAME}}|{{{1}}}}}

Il contiendrait ceci pour tester la présence de la sous-page de métadonnées, et récupérer l'éventuelle clé de tri préférable (pour la langue référencée) pour classer et trier la page indiquée dans la catégorie "Nom en (langue)" :

{{#ifexist:{{{2}}}/:data|[[Catégorie:{{{1}}}|{{ {{{2}}}/:data|{{{3}}}.clé de tri}}]]|[[Catégorie:{{{1}}}]]}}

verdy_p 3 décembre 2008 à 00:42 (UTC)

Tables de données (espace de nommage "data:")

Une autre proposation que j'ai faite dans le passé (mais toujours pas retenue non plus, alors que cela pouvait gérer pas mal de choses qui manquent actuellement) était aussi l'espace de noms "data:" dans lequel le nom des pages serait en fait celui d'une table de données:

• toutes les pages dans cet espace seraient des tables de données (qu'onpourrait éventuellement éditer en syntaxe wiki sous forme d'un switch ou autre) mais pouvant avoir un nombre quelconque de colonnes: il y aurait un nom ou un identifiant unique pour chaque ligne, et un autre pour la colonne (les deux noms ensemble indiquant une cellule). Pour lire une valeurs dans le tableau, on n'aurait qu'à utiliser la syntaxe des modèles, en mentionnant soit le nom de la table (génére alors une table dans l'article), soit le nom de la table et la clé unique (valeurs dans la première colonne de la table) comme premier paramètre (dans ce cas cela génère une liste à puce contenant les valeurs des différentes colonnes), soit aussi la clé unique en paramètre 1 et le nom de la colonne en paramètre 2 (dans ce cas, cela retourne seulement la valeur dans la cellule indiquée de la table). La première ligne de la table contiendrait les noms de colonnes). La page de discussion associée à la table pourrait contenir (ou rediriger) vers une page d'explication vers les valeurs à renseigner dans la table, mais la table pourrait aussi avoir une sous-page d'aide spécifique.
• Des paramètres spéciaux permettraient de modifier la présentation de la table ou de la liste, ou encore de faire une sous-sélection de lignes ou de colonnes à présenter.
• Cela aurait grandement facilité la création de tableaux de données (et la présentation sous forme navigable ne nécessitant pas de charger tout le tableau) , avec des données réutilisables qui peuvent être utilisées et partagées par différents articles, sans avoir à les gérer comme des modèles.
• Les fonctions seraient alors similaires à celle d'une base de données simple (ou d'une feuille de calcul unique)
• Il ne s'agit pas d'en un premier temps de croiser les tableaux, même si des valeurs dans une cellule pourraient contenir des appels de valeurs présentes dans une autre table en utilisant la même syntaxe évoquée ci-dessus {{data:nom d'une autre table cible|clé de la ligne cible|nom de la colonne cible}}, de la même façon qu'on utilise un appel de sous-modèle.

Cela reste dans le même esprit: cette proposition permet aussi de générer des métadonnées (il suffirait de nommer la table de données dans l'espace "data:" de la même façon que l'article, et utiliser une colonne pour les noms de variables dans la première colonne clé à valeur unique, et une autre colonne pour les valeurs de ces variables).

Là encore c'est possible de réaliser des tables de données sans modifier MediaWiki, mais la syntaxe est plus compliquée, ou elle impose de nommer les variables selon un format bien défini tel que "ligne\colonne" (en réservant un caractère séparateur comme "\" distinct des noms de lignes et de colonnes), il suffit de faire:

{{switch:{{{1|}}}|ligne1\colonne1=valeur|ligne1\colonne2=valeur2|...|}}

Et alors cette proposition est similaire à celle des métadonnées.

Cependant cela ne permet pas de réaliser automatiquement la présentation de la liste de valeurs sous forme de table formatée, que ce soit en important la table nommée comme on appelle un modèle sans paramètres, soit en fournissant uniquement le paramètre de la ou des colonnes clés pour afficher toutes les colonnes sous forme de liste à puce. Cette syntaxe supporte en revanche la récupération d'une seule cellule à la fois (car on n'a pas de fonction d'énumération en boucle dans MediaWiki) verdy_p 3 décembre 2008 à 00:30 (UTC)

Un Modèle pour les liens interprojets est-il possible ?

Suggestion béotienne

Ne serait-il pas possible de créer un Modèle:Liens interprojets pour remplacer le tableau que voici ?

En fait, pour Wikibooks, Wikisource, Wikinews et Wikiquote, les pages de recherche ont la même écriture hormis le mot vedette. Exemples avec les mots « éléphant » et « souris »:

1. Wikibooks

   http://fr.wikibooks.org/wiki/Special:Recherche/éléphant?search=éléphant&fulltext=Rechercher

   http://fr.wikibooks.org/wiki/Special:Recherche/souris?search=souris&fulltext=Rechercher

2. Wikisource

   http://fr.wikisource.org/wiki/Special:Recherche?search=éléphant&fulltext=Rechercher

   http://fr.wikisource.org/wiki/Special:Recherche?search=souris&fulltext=Rechercher

3. Wikinews

   http://fr.wikinews.org/wiki/Special:Recherche?search=éléphant&fulltext=Rechercher

   http://fr.wikinews.org/wiki/Special:Recherche?search=souris&fulltext=Rechercher

4. Wikiquote

   http://fr.wikiquote.org/wiki/Special:Recherche?search=éléphant&fulltext=Rechercher

   http://fr.wikiquote.org/wiki/Special:Recherche?search=souris&fulltext=Rechercher

Il doit y avoir moyen d’automatiser tout ça, non ? Moi je n'y comprend rien -Béotien lambda 1 décembre 2008 à 08:27 (UTC)

En s'inspirant de Modèle:WP peut-être ? -Béotien lambda 1 décembre 2008 à 08:54 (UTC)

Je sais, mais ce tableau était déjà là avant moi ; je l'ai seulement remis un peu en forme dans l'article robot (que j'ai trouvé parmi les articles proposés en articles de qualité) pour de laisser du code HTML/CSS invalide... verdy_p 1 décembre 2008 à 09:00 (UTC)

Modèle:cs-tab-cas

bonjour, je ne comprends pas les raisons qui t'on pousse a modifier le modele. tu peux m'expliquer ? la derniere version ne correspond pas a la declinaison tcheque. --Diligent 1 décembre 2008 à 08:28 (UTC)

Hmm... c'est pourtant bien la déclinaison utilisée et décrite dans l'article (qui mentionne aussi que parmi les 7 cas possibles, 5 sont des cas principaux (cités dans l'ordre slave classique), et 2 sont secondaires (souvent défectifs) et fortement liés à d'autres (ces déclinaisons défectives reprennent alors normalement la déclinaison du cas principal) : le vocatif est lié au nominatif, le locatif est lié au datif.

Note que les linguistes du tchèque utilisent deux ordres différents, l'ancien ordre à 7 cas étant différent, mais l'ordre pan-européen à 5 cas (qui est préféré aujourd'hui) étant dans la tradition slave (et aussi romano-latine et germanique). En France, c'est l'ordre pan-européen qui est utilisé (c'est aussi celui enseigné dans nombre d'écoles tchèques, car il facilite le groupement des déclinaisons similaires).

J'ai aussi supprimé le bogue d'affichage d'une ligne vide, raison principale de ce changement. verdy_p 1 décembre 2008 à 08:30 (UTC)

Note que je viens de cacher l'affichage entre parenthèses des noms de cas de déclinaisons défectives dans le libellé de la déclinaison du cas principal si elles sont absentes, si tu penses que cela peut être trompeur pour un lecteur (au cas où un locatif ou vocatif aurait été oublié ou omis car inconnu). verdy_p 1 décembre 2008 à 09:09 (UTC)

merci - le vocatif peut-etre qualifié de secondaire (par exemple pour toute la déclinaison en -ost, noms féminin d'état) mais très très courant pour les prénoms et les noms communs qui s'utilisent de manière interpelative (« con, veau », etc. tu vois le genre, ou de profession « monsieur le policier » : les deux mots se mettent au vocatif). c'est un cas plus vivant qu'on ne le pense. Pareil pour le locatif (absurde pour des noms de gens ou d'animaux - dans le monsieur ?!?! - mais imposé par certains verbes), il est indispensable. donc j'ai eu très peur en les voyant passer à la trappe ;-) mais je vois que tu as rétabli l'ancienne table. merci.

oui, je suis au courant pour l'ordre (et la désignation !) en créant la page, je me suis dit qu'on bosse pour un public francophone habitué à un ordre latin.

tu as l'air callé en modèles. peux-tu m'aider a creer des nouveaux ? je pense à la déclinaison adjectivale classique en -ný et -ní et en -ský. je sue avec les tables et tableaux. il faut sept cas (j'insiste ;-) et quatre genres : masculin animé et inanimé, féminin, neutre.

merci de ton aide et de l'organisation des modèles. bravo pour les ajouts didactiques sur la page du modèle ! Diligent

Attention le modèle {{cs-décl-adj}} pour les adjectifs n'est pas encore fonctionnel (je teste aussi les exceptions). Il est en cours et pas fini comme indiqué ! (et puis ne t'occupes pas des commentaires dans la page d'aide, j'ai du reprendre depuis le début, le remettrai à jour la page d'aide après). verdy_p 2 décembre 2008 à 03:36 (UTC)

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

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

Á part ça un grand bravo ! Diligent

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

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

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

Modification de page Utilisateur

Indépendamment de notre discussion en cours, très intéressante, je n'ai pas trop apprécié de m'apercevoir par hasard que tu avais modifié ma page utilisateur sans me le dire. Koxinga 1 décembre 2008 à 14:07 (UTC)

Oh. dans nos discussions j'ai cru tomber sur une page de discussion, et je voulais juste te montrer comment faire en syntaxe wiki, et apporter mes commentaires. Je ne voulais pas vandaliser (et il m'arrive de toucher un minimum certaines pages utilisateur pour remplacer des liens invalides ou qui ne marcheraient plus suite à une modif).

En général je fais le moins de modif possible, et je laisse le texte existant (même si je peux corriger certaines fautes d'orthographe au passage si je tombe dessus et si ça tombe sur des paragraphes dont je modifie les liens). Note bien que j'ai laissé tout ton texte existant.

Si je le fais c'est surtout car ne pas le faire alors que le reste a été touché risquerait de ne plus faire fonctionner ces pages, ou bien encore parce que les pages utilisateurs polluent parfois certaines catégories de maintenance, voire des catégories principales (où les pages utilisateurs ne devraient jamais figurer, si possible, sauf temporairement en attendant de trouver le moyen de les classer à part). verdy_p 1 décembre 2008 à 17:16 (UTC)

fr-CA

Bonjour,
Est-ce que tu sais ce qu'est ce code de langue fr-CA ? C'est donné pour français canadien ici [3] « Code ISO-639/ISO-3166 décrivant le travail. Si le travail est publié en français, on peut utiliser « fr-CA » ; sinon, en anglais, ce serait « en-CA » (CA signifie Canada).  »
et là [4] « "fr-CA" : la version canadienne du français ; » . -Béotien lambda 2 décembre 2008 à 16:29 (UTC)

C'est un code normalisé dans BC 47 pour désigner la langue française telle qu'elle est parlée au Canada... Ceci dit, ça n'en fait pas une langue ni un dialecte particulier, c'est un peu comme une collection de dialectes, plus ou moins floue. Si on veut parler des dialectes, il faudra alors des codes pour le québecois, voire le montréalais, l'ontarien, et des dialectes créoles avec des langues amérindiennes (particulièrement pour le Nord du Québec)...

Je ne suis pas sûr de l'utilité, dans le Wiktionnaire de codes spécialisés par pays, il vaut mieux utiliser les codes basés sur ISO 639-3 qui snot plus clairs et pas lié à un pays.

Imagine un peu: quel français désigne seulement fr-FR ? Le français officiel (tel qu'on le trouve dans les textes légaux et programmes scolaires officiels), ou n'importe français parlé en France ? Et désigne-t-il aussi le français en outre-mer ? verdy_p 2 décembre 2008 à 18:49 (UTC)

Catégories de rimes

Salut,

encore une nouvelle sollicitation : j'ai proposé les catégories de rimes à la suppression (voir Wiktionnaire:Gestion des catégories). Comme c'est toi qui a créé toutes ces catégories, je voudrais savoir ce que tu en penses avant de leur faire un sort, de même que pour le modèle {{rime}} qui me semble obsolète. - Dakdada (discuter) 3 décembre 2008 à 12:48 (UTC)

J'aurais bien aimé qu'on les utilise, à la place des lourdes pages de listes, mais faute de Bot pour faire le travail, et d'entousiasme ou d'un meilleur approprié et amélioré dans le traitement des chaines dans MediaWiki, pour automatiser le travail, ça fait un moment que j'ai mis la question de côté. J'espérais que la question reviendrait plus tard.

Ceci dit, le modèle rime était encore employé en divers endroits à la place du modèle pron pour ajouter ces rimes (et rimes inversées pour la recherche phonétique) en même temps que l'affichage de la prononciation, le tout en un seul appel.

Si cela avait été mieux compris, on n'aurait jamais eu à éditer les monstrueuses pages de listes pleines de "trous" avec des tonnes de termes oubliés car personne ne les maintient en même temps que les articles.

Pourtant le travail à faire dans les articles était TOTALEMENT AUTOMATISABLE. Les articles qui utilisaient rime étaient là à titre de démonstration (qui marchaient très bien pour classer les articles qui utilisent ce modèle), avant de créer un bot pour finir le reste.

Je ne sais pas qui a rendu le modèle rime obsolète, et si même il ne reste pas des appels au modèle. JE suppose que quelqu'un a remplacé partout rime par pron, là où il en a trouvé.

Pourtant il était facile de faire un bot pour remplir ces catégories et permettre les doubles recherches par rime et rime inversée. verdy_p 3 décembre 2008 à 12:58 (UTC)

Langues sans code

Salut !

Je fais tourner en ce moment un bot pour réorganiser un peu les sections traductions. Il repère (et parfois se plante misérablement sur) les langues n'ayant pas de code correspondant.

Si ça t'intéresse (ou quelqu'un d'autre), les langues problématiques que j'ai trouvé sont sur Utilisateur:Koxinga/langues inconnues. Tu es sûrement mieux placé que moi pour savoir ce qui est une simple faute de frappe ou un vrai problème, une langue inventée sans intérêt, un dialecte inclu dans une autre langue, pour savoir si l'abénaquis et l'abénaquis de l'ouest sont la même chose, etc. J'essaierai de le mettre à jour quand j'ai assez de nouveautés, si tu veux je te l'envoie.

Sinon, est-ce que tu peux me prévenir quand tu auras un peu stabilisé la liste des langues ? Je m'en sers pour les ordres alphabétiques et pour trouver les codes des langues qui avaient été simplement écrites.

Koxinga 4 décembre 2008 à 11:12 (UTC)

J'ai pratiquement fini, je sais qu'il me reste quelques langues rares non codées mais pourtant référencées (bikol [bcl], gilaki [glk], kajji/kuj [kaj], tyap [kcg], koro [kfo], etc.), mais les autres problèmes restants sont nettement plus compliqués.

Concernant les noms de langue je n'en change plus aucun depuis "l'affaire" massaï et yidiche.... Je me contente de mentionner les synonymes que je trouve, et je vous laisse décider quels noms seraient à changer.

Il y a quelques codes qui vont être fusionnés (des bizarreries du genre du code ku-ku). Mais rien qui remette en cause les noms actuels, à mois qu'une discussion décide d'en corriger certains. verdy_p 4 décembre 2008 à 11:26 (UTC)

Notes:

• le "pijin" est codé! regarde bien les listes... (c'est le pidgin des îles Salomon).
• langue inconnue : abénaquis (serpent) : non codé car ambigu, cela désigne plusieurs langues abénaquis
• langue inconnue : flamand (zéro) : non codé car ambigu, cela désigne plusieurs dialectes de plusieurs langues
• langue inconnue : kongo (zéro) : déjà codé, regarde bien.
• langue inconnue : pijin (où) : déjà codé
• langue inconnue : pijin (zéro) : déjà codé.
• langue inconnue : romanica (petit) : déja codé
• langue inconnue : romanica (France) : idem
• langue inconnue : romanica (adverbe) : idem
• langue inconnue : rundi (accordéon) : déja codé (regarde bien)
• langue inconnue : vénète (serpent) : déja codé (alias vénicien)
• langue inconnue : yucateco (serpent) : déjà codé (alias yucatèque)

verdy_p 4 décembre 2008 à 11:31 (UTC)

Note: la liste des langues est très lourde à modifier (difficile à mettre à jour). Regarde la page Wiktionnaire:ISO 639-3 et les pages liées Wiktionnaire:ISO 639-1 et Wiktionnaire:ISO 639-2, où il y a les synonymes que j'ai pu collecter... avec tous les codes langues pour lesquels on a des modèles stables, ainsi que des notes éventuelles sur leur compatibilité ou les confusions possibles.

Les langues pour lesquelles je dois faire du travail ne sont pas listées là mais dans une autre page de travail de modèles de codes langues à vérifier.

Je suis conscient que la liste alphabétique des langues est très en retard et demande elle aussi à être vérifiée, mais c'est pénible à faire, alors que les tables ISO 639 ont été bien plus faciles à mettre en œuvre depuis que j'ai révisé tous les modèles de langues (presque tous en fait, près de 800).

Pour les autres langues, j'ai importé une liste complète venant de l'IETF et de la base de données de l'IANA, comportant plusieurs milliers de langues (à priori il y a toutes celles de l'ISO 639-3, c'est à dire près de 7000, mais je ne les ai pas comptés!). Seulement les noms sont en anglais (non traduits) et il n'y a pas de modèle. Regarde Wiktionnaire:BCP 47 qui rend cette base IANA nettement plus facile à lire (elles est scindée par type de "sous-labels") !

verdy_p 4 décembre 2008 à 11:34 (UTC)

OK, je n'avais pas vu les synonymes dans les listes ISO 639, j'essaierai de faire un truc semi-automatisé à partir de ça ... Pour BCP 47, j'avais vu, c'est très intéressant mais plus difficile à utiliser automatiquement.

Les tableaux BCP 47 ne sont pas destinés à être réutilisés ni modifiés. C'est seulement une référence utile pour les codes manquants, plus facile à lire que la base de données IANA, et plus rapide que le site de l’ISO 639-3 (qui pose d'autres problèmes aussi car certains codes sont historiques dans l'ISO 639 et ne sont plus recommandés, et certains noms posent problème pour la même raison). De toute façon l'ISO 639-3 ne propose pas non plus de noms en français, et ses noms anglais sont ceux qui sont repris dans la base de données IANA pour BCP 47 qui précise leur emploi (recommandé ou non).

Tu préconises quel traitement pour les traductions ambiguës ? un modèle qui dit de résoudre le problème si possible et qui catégorise la page ? Koxinga 4 décembre 2008 à 14:09 (UTC)

Je n'ai pas encore réfléchi à la question. Pour moi les codes ambigus sont ceux dont l'étendue est égale à 'C' c'est-à-dire les collections de langues ou familles (mais pas nécessairement les macrolangues (dont l’étendue est 'M') ni les langues individuelles (dont l’étendue est 'I'). Pour lire ou tester l’étendue d’un code langue, il suffit d'utiliser {{code langue à tester|type=étendue}], par exemple:

• {{fr|type=étendue}} (français) retourne français : c'est une langue individuelle, jamais ambigu
• {{zh|type=étendue}} (chinois) retourne chinois : c'est une macro-langue, qui peut nécessiter éventuellement une précision, mais n'est pas intrinsèquement ambigu (notamment pas le code zh qui dans BCP 47 n'est pas ambigu mais un alias du seul mandarin (puisque les autres langues chinoises qui utilisaient "zh-" suivi d'un sous-label sont redéfinies maintenant avec leur propre code langue) ; BCP 47 les liste exhaustivement et définit les éventuelles redirections en tant que "labels hérités" (grandfathered en anglais), par exemple zh-yue devient yue, zh-min-nan devient nan ; bref BCP 47 nous facilite le travail. Avec cette définition, zh-Hans et zh-Hant deviennent aussi des alias de cmn-Hant et cmn-Hans (donc du seul mandarin).
• {{apa|type=étendue}} (langues apaches) retourne langues apaches : c'est une collection, donc ambigu.

Si le modèle existe mais n'est pas encore au nouveau format, l'appel retournera le nom complet de la langue et pas un code d'étendue parmi "C,M,I,S,P" ou vide (l'étendue vide concerne les dialectes, sous le niveau des langues individuelles, et non normalisés ou non conformes aux recommandations BCP 47; je songe définir l'étendue D pour les dialectes qui sont normalisés dans BCP 47, si le besoin se fait sentir).

Les étendues S et P sont normalisées : respectivement l'étendue spéciale (nécessairement ambigues) ou l'étendue privée (pas ambiguë mais d'usage strictement local, comme "qqq" qui sert comme code de substitution pour fournir une aide à la traduction des ressources de MediaWiki et des extensions, principalement dans BetaWiki, ou comme code de démonstration pour les pages d'aide de modèles qui veulent un code langue, afin d'éviter qu'ils ne polluent les catégories par langue si on leur donne un code langue réel).

Cependant certains codes sont encore présents sous forme de synonymes (redirections vers le code normalisé), et leur usage n'est pas différencié du code normalisé (j'ai essayé de recenser ces codes synonymes et redirigés dans une sous-catégorie spéciale). En principe ils devraient disparaître des articles (si le robot suppresseur de redirections passe par là).

Note bien que les 3 pages ISO 639 utilisent des tableaux triables : clique pour trier par étendue, tu auras une sous-liste toute prête à copier-coller... des codes langues des collections dans chacune des tables. Dans l'ISO 639-1, le seul code langue de collection est le langues biharies [bh], ambigu. verdy_p 4 décembre 2008 à 14:35 (UTC)

Le problème des traductions ambiguës n'est pas vraiment un problème avec les codes, mais avec des contributeurs qui rentrent des informations qu'on juge incomplètes (abénaquis ou flamand par exemple) et donc à qui on ne peut pas donner de code langue. Dans ce cas, comment on le signale ? Koxinga 4 décembre 2008 à 14:41 (UTC)

On pourrait changer les titres de section de langue pour afficher ce statut, et indiquer une liste d'autres codes possibles à utiliser...

Note aussi : les anciens codes de l'ISO 639 qui ont été retirés de la norme (parce qu'ils ont été fusionnés en tant que dialectes d'une même langue, ou scindés en plusieurs langues individuelles) ont une étendue vide. Cela demande une prise en compte spéciale et des décisions pour les recatégoriser (mais pas forcément automatiquement).

• Pour savoir quelles langues sont contenues dans une collection, il y a une ébauche de mapping en cours, dans le projet CLDR hébergé par Unicode, mais c'est encore loin de suffire.
• Pour savoir quelles langues sont contenues dans une macrolangue, c'est déjà normalisé dans l'ISO 639-3 qui définit un mapping intégral des macrolangues (cette partie annexe de l'ISO 639-3, concerne les codes de macrolangues ISO 639-3, ISO 639-2 et ISO 639-1 ; elle n'est pas intégrée dans BCP 47, du moins pas encore).
• Pour savoir quels anciens codes normalisés sont redéfinis vers des codes recommandés, c'est BCP 47 la référence. verdy_p 4 décembre 2008 à 14:47 (UTC)

Je ne trouve pas du tout le code pour romanica. Tu dis qu'il existe mais c'est quoi ? Koxinga 4 décembre 2008 à 20:37 (UTC)

Tu as raison, je croyais avoir vu ce nom de langue, en fait c'est sur une liste de discussion: il n'y a pas encore de code.

Dans un cas comme ça, mieux vaut ne pas inventer de code, et au besoin créer un modèle {{romanica}} avec au moins 5 lettres (on verra plus tard s'il faut le normaliser), ce qui permet ensuite de catégoriser ces entrées ou rechercher les références au modèle. verdy_p 4 décembre 2008 à 20:45 (UTC)

fr-conj etc.

Salut,

tes ajouts dans les modèles de {{fr-conj}} me semblent douteux : pour être précis, les formes du participe présent n'y ont pas leur place, pour la simple raison que le participe présent est invariable. C'est son adjectif dérivé, quand il existe, qui s'accorde (dis-moi si je me trompe).

C'est en tout cas pour ce genre de chose qu'on t'a demandé de ne pas modifier ce genre de modèles importants sans concertation. Si tu fais des erreurs, on est obligé de repasser derrière.

Vais-je être obligé de protéger complètement tous les modèles importants avant que tu ne cherches d'abord à discuter ? - Dakdada (discuter) 4 décembre 2008 à 16:23 (UTC)

J'en avais parlé sur la Wikidémie justement. On m'a dit OK, ce serait bien à faire. Faut-il que je garde seulement les accords du passé ? La conversation a du t'échapper... verdy_p 4 décembre 2008 à 16:41 (UTC)

Zut, j'ai cherché pourtant, je voulais pas dire de bétises (tu aurais un petit lien pour que je me mette au fait ?)... Pour les accords du participe passé, pas de problème je pense (du moment que les cas invariables sont aussi prévus, genre être... ce qui est le cas). Je recommanderais par contre d'éviter les abréviations, je pense qu'on a la place. On pourrait aussi carrément mettre un petit tableau d'accord (mais c'est pas pressant, et pas forcément adapté). - Dakdada (discuter) 4 décembre 2008 à 17:08 (UTC)

Pas la peine de chercher, c'était ici : Wiktionnaire:Gestion_des_modèles#Accords_des_participes. Il faudrait copier ces conversations dans les pages de discussions concernées. - Dakdada (discuter) 4 décembre 2008 à 17:25 (UTC)

Fais attention aux modèles du 3egroupe, parfois les dérivés ne suivent pas tout à fait les règles du verbe racine, il y a alors des paramètres optionnels spécifiques (exemple : {{fr-conj-3-aller}}). Peut-être existe-t-il des cas qui concernent le participe, auquel cas il faudrait éventuellement ajouter des paramètres. N'oublie pas de tester sur les exemples listés ou sur liste complète des verbes utilisant ce modèle. Amitiés. --Szyx 4 décembre 2008 à 16:53 (UTC)

Bien vu pour dû/redu. --Szyx 4 décembre 2008 à 21:03 (UTC)

C'est une des raisons qui ont motivé l'ajout des accords de participes, puisque seul le masculin singulier du particpe passé de devoir prenait (et prends toujours) un accent circonflexe, alors que les autres accords et les verbes dérivés n'avaient pas d'accent, puisqu'il n'y a vait pas d'ambiguïté. C'est un peu comme le tréma sur ambigüe/ambiguë et ambigüité/ambiguïté (il est là au féminin ou dans le nom seulement pour lever une ambigüité de prononciation, car le u doit se prononcer : l'orthographe de 1990 l'a conservé même si on a maintenant la liberté de le placer sur le u ou sur la voyelle qui suit). verdy_p 4 décembre 2008 à 21:12 (UTC)

L'autre raison c'est pour les verbes du 3e groupe dont le participe passé se termine par une consonne (t ou s): elle est muette au masculin, mais se prononce lorsqu'on accorde au féminin... De plus si cette consonne est un s, le participe n'est invariable qu'au masculin, mais pas au féminin... Exemple de correction que je viens de faire: clore qui indiquait à tord l'invariabilité du participe. verdy_p 4 décembre 2008 à 21:15 (UTC)

Conjugaison à réfléchir

Tu pourrais tester les modèles sur Annexe:Conjugaison française:férir ? --Szyx 9 décembre 2008 à 00:02 (UTC)

Je croyais avoir tout fait, mais le verbe férir était absent du tableau général des verbes du 3e groupe (pour le premier et le second les règles étaient simples).

J'ai du oublier le fait qu'un participe présent pouvait être absent. Je vais regarder si ce verbe utilise une règle spéciale échappant à la règle. Ceci dit, le tableau n'est pas faux, il affiche juste des points d'interrogation pour les phonétiques manquantes.

Note qu'il me reste à accorder les participes passés dans les temps composés, en utilisant les règles des participes (pour afficher le féminin correctement). J'ai d'abord voulu terminer la partie des participes. verdy_p 9 décembre 2008 à 01:29 (UTC)

Je viens de regarder, je n'ai rien oublier dans les modèles : il te manquait 'ppr.déf=1' pour indiquer que le participe présent était défectif. Il ne suffit pas de ne pas indiquer de participe présent pour tout désactiver.

Je pourrais faire en sorte que si un participe présent n'est pas indiqué du tout dans le troisième groupe, il ne s'affiche alors pas du tout (mais note que dans les autres groupes, on ne passe pas de participe présent dans les annexes de verbes, pourtant ils s'affichent par défaut grace aux modèles des 1er et 2e groupes qui leur donnent des valeurs par défaut (à moins que le verbe mentionnait déjà pp.déf=1 ou ppr.déf=1 pour ces verbes déjà conjugués dans les annexes).

Je n'ai fait aucune exception en fonction du groupe : ce sont les modèles ou annexes appelants qui donnent ces exceptions de défectivité. verdy_p 9 décembre 2008 à 01:34 (UTC)

Cependant j'ai déjà lu « férant » (on dit bien « sans coup férir » et alors on entend aussi « en lui férant un coup », comme on devrait dire « en lui conférant un coup », bien que ce dernier soit le verbe conférer du 1er groupe et non « conférir », car il aurait le sens très différent de attribuer ou référer ; je pense d'ailleurs que le verbe conférer à la même origine que férir, puisque conférer c'est férir ensemble, dans un débat mutuel, voire un duel; le verbe férir d'ailleurs se dit aussi ferrer ou « donner un coup de fer », le fer étant l'arme blanche, généralement l’épée, le sabre ou le couteau). verdy_p 9 décembre 2008 à 01:37 (UTC)