Discussion utilisateur:Verdy p/archive4

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)

Salut,

Je crois que c'est toi qui avait modidié {{reli}} pour permettre une categorisation plus fine comme avec {{reli|fr|rel=chrétienne}} serais-tu favorable a la même modif pour {{transp}} ?? avec par exemple {{transp|fr|trans=maritime}} — Serpicozaure 18 janvier 2010 à 16:55 (UTC)Répondre

Non je l'avais juste corrigé pour le normaliser (au niveau du paramètre de langue uniquement, afin que ce ne soit plus le français par défaut, car ça pose des problèmes, et aussi pour mieux le documenter).

• L'introduction du paramètre "reli=" vient de Szyx, et ne consiste (consistait?) pas à ce qu'il affine la catégorisation, mais à compléter le libellé (la sous-catégorisation thématique en fonction de la religion ne marche pas bien, on tombe dans des sous-catégorisations absurdes pour des religions difficiles à distinguer ou classer, alors qu'on ferait mieux de distinguer clairement le vocabulaire chrétien, juif ou islamique, sans pousser trop loin au delà ce qui est nécessaire à la compréhension des définitions et distinctions de termes et d'emplois, nécessaires à leur bon emplou ou à la bonne traduction).
• Si tu veux faire en sorte de sous-catégoriser le vocabulaire des transports, la question est de savoir si c'est réellement discriminant (les catégories sont-elles surpeuplées ? La sous-catégorisation permet-elle de distinguer les traductions entre elles?) Personnellement, si des distinctions thématiques sont nécessaires, il me semble que ce devrait être des sous-modèles séparés pour certains domaines particulier (par exemple, au lieu de claser dans les transports, faire un modèle séparé pour l'aéronautique, ou le vocabulaire maritime, ou automobile, ou ferroviaire). Je ne suis pas trop favorables aux paramètres optionnels (et on a déjà des modèles spécialisé par type de transport, dont les catégories thématiques/lexicales sont déjà classées, avec très peu de termes en fait utilisant {{transp}} directement, avec ou sans langue précisée, on est très loin d'avoir des catégories surpeuplés, justement car le domaine des transport est déjà largement sous-catégorisé).

En revanche, le paramètre de langue est standardisé (paramètre 1) et devrait être obligatoire (à défaut de ce paramètre, le modèle devrait catégoriser dans une catégorie "sans langue mentionnée" mais surtout pas utiliser le français (ou une autre langue) par défaut (car ça mélange tout dans des catégories qu'on veut précises). verdy_p (d) 19 janvier 2010 à 13:38 (UTC)Répondre

Merci beaucoup pour ton explication détaillée et argumentée, ca va me permettre de categoriser plus justement mes contributions Serpicozaure(discuter) 21 janvier 2010 à 07:43 (UTC)Répondre

Peux-tu régler le problème de « {{métadonnées}} en boucle » de ce modèle ? Merci d’avance. Urhixidur 8 avril 2010 à 14:10 (UTC)Répondre

Il y a quelques pages de conjugaison (abimer, abîmer, y avoir) dans lesquelles tu as inséré des constructions avec {{{}}} pour substituer un paramètre, mais comme ce ne sont pas des modèles, ces paramètres ne peuvent pas prendre des valeurs. Y a-t-il une raison, ou est-ce que je peux les effacer ? Joriki 13 avril 2010 à 12:04 (UTC)Répondre

Amicalement.--✍ Béotien lambda ☏ 18 juillet 2010 à 05:22 (UTC)Répondre

Oui, je suis d'accord pour avoir le statut de patrouilleur. Pourquoi pas, mais ce ne sera pas mon occupation favorite. Je ferai ce que je pourrai de temps en temps. verdy_p (d) 18 juillet 2010 à 05:26 (UTC)Répondre

Merci. C'est tout à fait la philosophie du système. Aucune obligation, liberté individuelle. Bon dimanche. --✍ Béotien lambda ☏ 18 juillet 2010 à 05:37 (UTC)Répondre

Tu as désormais les outils de patrouilleur. --✍ Béotien lambda ☏ 17 août 2010 à 09:04 (UTC)Répondre

Attention, tu as remplacé un modèle donnant un résultat apparemment correct (même si son utilisation était illogique vu son nom) par un modèle n'existant pas. j'annule donc les modifications. Lmaltier 22 juillet 2010 à 20:29 (UTC)Répondre

Normal ce n'est pas du tchèque. Le modèle pour le serbe est à créer séparément !!! verdy_p (d)

Tu aurais du voir que j'étais en train de vérifier et classer les déclinaisons tchèques. Et ce mot n'avait rien à faire dans les listes tchèques.

Je viens de copier le modèle tchèque réutilisé à tord pour le serbe (qui au passage mériterait une sérieuse reclassification entre ses versions latine et cyrillique, même en conservant la catégorie mère pour le code "sr" sans précision (dont tous les termes seraient à reclasser de toute façon selon l'écriture, mais qui incluerait les deux catégories latine et cyrillique (codes "sr-Latn" et "sr-Cyrl").

Des regroupements de catégories en tant que sous-catégories s'imposeraient aussi pour mettre le serbe (sr) dans le serbo-croate (sh) avec aussi dedans le croate (hr), ou le bosniaque (bs), sachant que pour de nombreux termes, ce sera ambigu de choisir entre les différents dialectes de la langue.

Et aussi créer les divisions entre serbo-croate latin (sh-Latn, contenant le croate hr qui n'existe qu'en latin, et le bosniaque latin bs-Latn), et serbo-croate cyrillique (sh-Cyrl, contenant le serbe cyrillique sr-Cyrl, et le bosniaque cyrillique bs-Cyrl)

Et enfin trier les mots de toutes ces variétés du serbo-croate selon le lexique national (si possible), et l'écriture utilisée (indispensable).

Sinon c'est un énorme mélange inutilisable. Je pourrai m'en occuper éventuellement plus tard.

verdy_p (d) 22 juillet 2010 à 20:45 (UTC)Répondre

Pour le serbo-croate, il ne faut surtout pas retirer les sections existantes : en effet, il existe un wiktionnaire en serbo-croate, en plus de ceux en serbe, en croate, etc. On peut juste rajouter les sections Serbe, etc. manquantes. Pour les sous-catégories, pourquoi pas, mais ça peut avoir des conséquences inattendues, il faut absolument en discuter avant (sur la Wikidémie).

Je ne demande pas de retirer les catégories du serbo-croate, mais que cette langue générique regroupe tous ses dialectes (devenus des « langues » seulement récemment). En revanche la séparation entre latin et cyrillique s'impose dans tous ces dialectes, car les modèles utilisés seront tous différents pour l'orthographe, le tri des catégories lexicales, les modèles de conjugaison ou de déclinaisons et accords, de même que pour les entêtes de langue dans les articles (bien qu'il existe une règle assez simple de transcription entre latin et cyrillique, il connait maintenant de nombreuses exceptions ! verdy_p (d) 22 juillet 2010 à 21:02 (UTC)Répondre

Dans tous les cas, il ne faut pas remplacer volontairement quelque chose d'affiché correctement par quelque chose de mal affiché, c'était tout ce que je disais. Lmaltier 22 juillet 2010 à 20:54 (UTC)Répondre

J'étais en train de faire le tri, je n'aurais pas laissé cela en plan. verdy_p (d) 22 juillet 2010 à 21:02 (UTC)Répondre

je note ton travail de romain sur les modèles de déclinaisons tchèques.

si tu as besoin d'aide (mise-à-jour des mots utilisant un modèle à rendre désuet, en double, etc.), n'hésites pas à me faire signe.

bravo et merci

--Diligent 23 juillet 2010 à 12:08 (UTC)Répondre

En général une fois le ménage fait, je marque les doublons restants avec {{suppr}} et ce sera nettoyé plus tard...

Je note aussi un mélange des emplois: les modèles tchèques utilisés pour le polonais par exemple !

Ou omment se compliquer la vie pour revérifier tout ça !

verdy_p (d) 23 juillet 2010 à 12:10 (UTC)Répondre

à tout hasard : j'ai créé Modèle:cs-décl-nom-ma-dur-ch, je note l'argument classé. Dans le doute sur ce que cela signifie, j'attire ton attention. --Diligent 12 août 2010 à 09:36 (UTC)Répondre

Le pramètre classé m'a servi à déterminer les usages directs du modèle de base pour former toutes les déclinaisons, au lieu d'un sous-modèle spécifique au paradygme de déclinaison. Cela permet de garder à part les déclinaisons sans paradygme pour l'instant, et permet de vérifier les tableaux de déclinaison (car j'y avais noté des erreurs dans les articles, qu'il a fallu revérifier un par un, ce qui était une tâche ardue). Maintenant les déclinaisons sans paradygme indiquées dans les articles sont réduites à quelques exceptions, tous les autres mots utilisant les modèles spécialisés avec paradygmes, ce qui facilite leur vérification en parcourant la liste des emplois de chacun (en cas d'utilisation seulement du mauvais paradygme pour un mot, ce qui ne nécessite que de changer le nom du modèle spécialisé utilisé dans l'article mais pas de refaire le tableau en entier). Le but étant d'avoir moins d'erreurs dans les articles. verdy_p (d) 13 août 2010 à 08:44 (UTC)Répondre

Note: si le paramètre n'est pas passé dans le modèle, tout article qui emploira le modèle sera classé dans Catégorie:Accords à vérifier en tchèque. C'est un paramètre donc destiné à la maintenance (et dans l'immédiat, je préfère ne pas le documenter pour éviter que certains soient tentés de l'utiliser avec le modèle de base dans les articles (si la déclinaison est bien une exception, on n'emploira pas le modèle de base, mais le modèle de déclinaison "-autre" qui passera ce paramètre (et permettra aussi un suivi des emplois). verdy_p (d) 13 août 2010 à 08:48 (UTC)Répondre

+ Modèle:cs-décl-nom-mi-dur-ch

je crois comprendre. Merci pour les explications détaillées.

--Diligent 13 août 2010 à 10:26 (UTC)Répondre

Je fais un peu de maintenance et de nettoyage. Je ne sais pas si tu as noté, j'ai supprimé un modèle inutile employé dans obvod qui n'est pas neutre mais masculin inanimé. Je ne comprends pas pourquoi tundra, jikra, prohra se retrouvent dans la catégorie. Rien dans l'article ni dans le modèle de déclinaison qui explique cela... hmmm. mystère. Tu as une idée ? --Diligent 15 août 2010 à 11:03 (UTC)Répondre

La catégorie a été créée pour permettre de vérifier des appels de modèles non spécialisés. Si on emploie un modèle spécialisé qui ne nécessite pas de vérification, ce modèle doit contenir "classé=oui". Si plus tard on constate que même ce modèle doit être sous-classé et vérifié, on remplacera par "classé={{{classé|}}}" dans ce modèle et on passera à nouveau "classé=oui" dans les modèles sous-classés.

Le but étant de vérifier les utilisations selon le paradygme utilisé, puisque chaque sous-modèle spécialisé gère sa liste d'emplois qui est plus facile à vérifier que la longue liste de mots d'un modèle plus générique.

Bref j'ai ajouté "classé=oui" dans le modèle en '-f-ra', et ces mots ne sons plus marqués comme à vérifier. verdy_p (d) 4 septembre 2010 à 08:35 (UTC)Répondre

Bonjour Verdy p,

J'ai voulu t'envoyer un mail à l'instant pour te prévenir de la création d'une liste de diffusion pour le Wiktionnaire francophone, mais je n'ai pas pu car tu as désactivé cette option dans ton profil.

Je t'invite à t'y inscrire pour être informé régulièrement des différents événements : https://lists.wikimedia.org/mailman/listinfo/wiktionary-fr

Je te souhaite une agréable soirée -- Quentinv57 ✍ 22 août 2010 à 16:12 (UTC)Répondre

Justement je ne veux pas de mailing list, ni aucun email. Je suis sur Wikipédia assez souvent (c'est ma page principale, mentionnée sur ma page utilisateur sur tous les projets où j'ai une activité) pour y être joignable.

En cas d'urgence, c'est sur ma page Wikipédia qu'il vaut mieux me contacter (car je ne suis pas en parallèle tous les projets, et il peut s'écouler des jours parfois avant que je revinne sur un projet).

Donc pas besoin d'inscrire mon email (j'ai essayé, il y a beaucoup trop d'emails envoyés automatiquement par les différents projets pour des raisons futiles ou mineures). J'ai désactivé cette option tout à fait volontairement sur TOUS les projets Wikimédia (les emails ne peuvent être envoyés personnellement que par les admins pour des raisons administratives (licence, etc...), mais pas des mailing lists ou un robot, ou si quelqu'un écrit ou répond sur ma page perso). verdy_p (d) 4 septembre 2010 à 08:25 (UTC)Répondre

Les clés de tri de chromo-lithographe, etc. étaient pleinement justifiées. Il y a deux façons classiques de faire, celle utilisée dans les dictionnaires en général, et celles utilisée par exemple pour les listes de gares ou les choses comme ça. Ici, nous utilisons cette deuxième méthode : nous voulons classer boulanger-pâtissier entre boulanger et boulangerie. Ce choix est justifié par le fait qu'on a énormément de locutions et qu'on les traite dans des pages séparées, contrairement à ce que font la plupart des dictionnaires, faute de place. Lmaltier 11 décembre 2010 à 16:53 (UTC)Répondre

Oui mais dans ce cas ce n'est pas une expression, et la fusion existe pour ces mots (qui n'existent pas séparément, puisque l'un d'eux est un préfixe uniquement)... Jusqu'à présent partout on pronait la fusion pour les clés de prfixes, quelqu'chose a du changer dans les clés de tris parce que ce cas n'est pas isolé du tout ! verdy_p (d) 11 décembre 2010 à 16:55 (UTC)Répondre

Non, non, rien n'a changé, on fait ça depuis très longtemps, et c'est logique, comme le montre l'exemple que j'ai donné. On laisse les espaces dans les clés de tri, et on remplace les tirets par des espaces. C'est un choix. Lmaltier 11 décembre 2010 à 16:58 (UTC)Répondre

Ton exemple est très différent, car on a les mots séparés "boulanger" et "pâtissier".

"chromo-" est un préfixe qui ne s'écrit pas seul, et on veut que "chromo-lithographe" se classe avec "chromolithographe"... Le trait d'union est totalement superflu dans ce mot c'est une variante mineure (et désuète) et même dans ce cas on voudra le placer après le préfixe. verdy_p (d) 11 décembre 2010 à 17:03 (UTC)Répondre

C'est vrai qu'ici c'est un préfixe, et que boulanger n'est pas un préfixe. Mais il y a des cas beaucoup moins clairs. Nous nous sommes donné des règles simples et claires, adaptées à nos particularités, et faciles à comprendre pour les lecteurs. Lmaltier 11 décembre 2010 à 17:07 (UTC)Répondre

Si tu ne veux pas respecter les règles en vigueur ici, ou les changer unilatéralement, je t'invite à créer ton projet concurrent. Lmaltier 11 décembre 2010 à 17:09 (UTC)Répondre

Par ailleurs Lmaltier refuse d'appliquer les règles habituelles pour les indentations des messages sous MediaWiki... Je sais, c'est hors sujet. Mais quand on parle d'appliquer des règles... --GaAs 11 décembre 2010 à 17:13 (UTC)Répondre

Il y a surtout que les règles ont visiblement changé et sont incohérentes alors dans plein d'endroits ! car jusqu'à présent on ignorait les traits d'unions de préfixes, comme mentionné dans la doc ! Tu confonds avec les mots composés, qui ici n'en sont pas ! verdy_p (d) 11 décembre 2010 à 17:20 (UTC)Répondre

Je viens de vérifier, et c'est vrai qu'une IP avait unilatéralement modifié la documentation du modèle, ce qui la rendait d'ailleurs complètement incohérente, c'est vrai. Il ne faut pas modifier ce genre de chose sans discussion. On en avait discuté, de ces règles. Lmaltier 11 décembre 2010 à 17:24 (UTC)Répondre

Correction : c'était toi qui avait fait cette modification sans discussion. Je ne comprends pas : j'avais clairement vu les adresses IP dans l'historique, et maintenant je vois Verdy p à la place... Non, j'ai compris : j'avais consulté l'historique du modèle clé de tri, et affiché les versions avant l'intervention de l'IP et après. Mais ce qui s'affichait était la page de documentation, une autre page, avec donc un autre historique... Lmaltier 11 décembre 2010 à 17:47 (UTC)Répondre

Quoi ? Je ne comprends rien à ce que tu dis là, tout et son contraire ! verdy_p (d) 11 décembre 2010 à 19:39 (UTC)Répondre

Bon alors, je résume : tu ne dois pas vouloir imposer de nouvelles règles à tout le monde en changeant discrètement une documentation, sans discussion. Lmaltier 11 décembre 2010 à 19:54 (UTC)Répondre

Et puis je ne vois pas pourquoi tu m'agresses, alors que le tri c'est moi qui l'ai mis en place depuis longtemps alors qu'avant il n'y en avait pas du tout et ne fonctionnait qu'avec des clés incohérentes. Comme visiblement tu ne comprend pas le tri multiniveaux, c'est toi qui change les règles. Le tri multiniveau a été compliqué à mettre en place à cause de limites actuelles de MediaWiki (qui n'a pas de support natif de UCA) et que ce modèle prend en charge pratiquement intégralement ; en particulier la gestion des majustcules, que tu n'as pas compris, de même que l'ajout inutile des pronoms verbaux, prises en charge automatiquement dans la clé tertiaire, mais qu'on doit éliminer de la clé passée qui génère les clés secondaires et tertiaires où ces pronoms gênent le tri correct : ces pronoms sont bien des éléments mineurs de tri (donc tertiaire, et donc à éliminer du paramètre) qu'on ne doit pas indiquer pour trier les verbes pronominaux avec le verbe non pronominal correspondant.

Je pense que tu ne connais pas le tri UCA. Certes on ne peut atteindre la perfection UCA avec les fonctions du parseur actuel, mais on s'en approche pratiquement (il le niveau tertiaire actuel est en fait un composite du niveau tertiaire UCA et du dernier niveau quaternaire UCA des différences binaires, mais on ne peut pas faire mieux avec un modèle). Il importe que les clés secondaires et primaires soient toutes deux correctes: la clé primaire n'aura jamais de majuscules (mais elle est générée par le modèle), alors que la clé secondaire prend en compte les différences de casse (qu'il faut donc préserver dans le paramètre).

Et je n'ai rien imposé, cela a été discuté il y a longtemps et ma solution a été approuvée alors (après une phase de tests longue ayant conduit à divers compromis, sur une liste de mots alors encore expérimentale bien avant même que le modèle soit utilisé de façon généralisée), sauf par ceux qui ne l'ont pas comprise ensuite et qui n'ont pas participé, toi par exemple.

Et concernant le trait d'union des préfixes et suffixes, cette règle a été une des premières écrites et très stable (bien avant de stabiliser celle des mots composés, y compris avec l'apostrophe où divers essais ont été faits aussi).

Et je note que tu a supprimé des mises en garde concernant les langues où l'apostrophe a valeur de lettre et non de marque d'élision ; ce n'est pas parce que tu ne la comprends pas (la remarque ne concerne pas les mots français), qu'il faut la supprimer car elle est importante ; ce cas avait aussi été discuté contrairement aux modifs faites ensuite qui ont ignoré ces discussions et tenté de "simplifier" les choses).

En l'occurence c'est toi qui veut changer les règles et pas moi. verdy_p (d) 11 décembre 2010 à 19:58 (UTC)Répondre

Tu n'as pas mis en place les clés de tri, tu as inventé des règles très compliquées dont nous n'avions pas besoin, sans discussion, ça, je me rappelle très bien. Ce genre de critères de tri pour obtenir un ordre toujours prévisible est parfois fondamental dans certaines applications, mais pas ici. Que paris soit listé dans une catégorie avant ou après Paris, ça n'a aucune importance en pratique. Nous sommes un wiki, nous devons rester simples et compréhensibles par tous, nous ne sommes pas un logiciel. J'ai simplement remplacé un texte incompréhensible par un texte compréhensible, mais je vais rajouter l'exception où l'apostrophe a valeur de lettre. Lmaltier 11 décembre 2010 à 20:11 (UTC)Répondre

Je t'invite à remonter dans mes "Archive1" (début 2008) : déjà tu n'avais pas compris à l'époque à quoi ça servait mais je croyais cette discussion close car j'en avais montré l'utilité. La casse est bien à conserver (si tes robots ignorent encore cette règle, il va falloir la revoir, cela conduit à des tris incohérents dans la Catégorie:français très peuplée et où ces détails font la différence). Ces règles je ne les pas inventées, je me suis approché au plus près du tri UCA (standardisé au plan international) avec le modèle, sinon le modèle n'aurait pas été nécessaire. verdy_p (d) 11 décembre 2010 à 20:14 (UTC)Répondre

Même sans être un logiciel, « garder la casse » n'est pas une question de logiciel, c'est très compréhensible et linguistiquement parlant. Si on doit fournir un paramètre c'est uniquement pour filtrer certaines différences que MédiaWiki ne sait pas éliminer lui-même simplement (notamment les accents). Pour le reste on garde les capitales qu'ils sait traiter lui-même par des fonctions parseur.

De toute façon UCA est en cours d'implémentation (quand ce sera fait, il ne sera même plus nécessaire de fournir de paramètre au modèle), et j'ai participé déjà à cette partie du code encore testé pour diverses langues. Le seul intérêt du paramètre c'est uniquement faire ce que MediaWiki ne sait pas faire tout seul.

Et je ne l'ai pas discuté qu'ici mais aussi pour Wikipédia et dans l'édition anglophone et d'autres wikis hors de Wikimedia qui demandent aussi l'approcher au mieux UCA (en attendant d'avoir aussi des clés de tri multiples pour des langues différentes, et même plusieurs tris possibles dans une même catégorie offrant plusieurs tris alternatifs). Ceux qui bénéficieront le plus d'UCA seront les wikis des langues asiatiques (à commencer par le coréen et le japonais, le cas du chinois étant bien plus compliqué, les langues indiennes à la composition complexe, ainsi que l'arabe et l'hébreu pour leurs diacritiques multiniveaux, ou encore le thaï et le lao qui nécessite des inversions documentées par Unicode pour les voyelles combinantes codées en préfixe avant la consonne de base). verdy_p (d) 11 décembre 2010 à 20:22 (UTC)Répondre

Qu'est-ce qui est le plus important ? Que paris soit juste après Paris (ou l'inverse) dans une catégorie, ou rester le plus simple possible pour les contributeurs ? Moi aussi, je suis dans l'informatique, mais je sais que nous ne devons pas devenir une application informatique, et à plus forte raison encore, pas devenir une application incompréhensible. Ce sont les contributeurs qui font ce projet, il ne faut pas les décourager.

Est-ce que tu veux dire que tu participes au logiciel MediaWiki ? Si des modifications sont prévues pour que les clés de tri soient automatiques sans qu'on ait à s'en occuper, c'est parfait, puisque ça simplifie pour les contributeurs. Je suppose donc qu'on pourra indiquer dans les pages de catégorie de quelle langue il s'agit pour que le tri soit cohérent. Quelle syntaxe est prévue pour ça ? Lmaltier 11 décembre 2010 à 20:32 (UTC)Répondre

La syntaxe n'est pas décidée (dans un premier temps ce sera une fonction parseur destinée à être testée séparément sans mettre à jour le schéma de base de données, et permettant les tests pour différentes langues dans des catégories de test).

Un autre développement concerne le tri dynamique des tableaux (qui a aussi besoin d'un support côté serveur avec AJAX, sinon pris en charge en Javascript côté client de façon compatible).

Mais effectivement on pourra indiquer dans les catégories une liste de critères de tri applicables, en fonction des langues qui y sont contenues. De fait, la clé de tri précisée ne servira que pour les cas non pris en charge par UCA, et ne sera alors qu'une clé "préfixe" destinée surtout à créer des groupes dans la liste affichée, les doublons étant alors admis dans ces préfixes, et gérés au sein de chaque groupe par UCA.

Il devrait faire des exceptions (comme par exemple le renversement "nom, prénom" d'un article nommé "prénom, nom". Le tri sera multiniveau et pourra prendre en compte aussi un suffixe. Ce qu'on précisera dans les articles ne sera alors plus que ce groupe d'exception (la plupart du temps même, ces sous-groupes devraient devenir des sous-catégories).

Parmi les sujets évoqués figure le problème de la "première lettre", notamment pour le chinois, car cela dépend de l'interprétation de ce tri (après une translittération Pinyin par exemple, dans une catégorie chinoise admettant deux tris en pinyin ou par clé/traits !), et cela fixe ce qui est affiché dans les entêtes, mais aussi la consultation à partir d'une position donnée par un préfixe d'index.

Cela demandera une mise à jour du schéma de la base de données, mais globalement la majorité des usages actuel de {{DEFAULTSORTKEY:}} deviendra inutile et pourra être nettoyé des articles (comme aussi des modèles qui l'emploient indirectement).

C'est compliqué et prendra du temps (parmi les difficultés: l'intégration d'ICU ou non selon les versions, et comment assurer la compatibilité sur les plateformes MediaWiki dont le moteur PHP ne supporte pas les extensions natives (dans des librairies partagées, .dll ou .so) : une solution toute en PHP est recherchée (et là aussi j'ai écrit du code ; ce développement n'est d'ailleurs propre à MediaWiki, et est en fait un challenge pour l'internationalisation de PHP en général). verdy_p (d) 11 décembre 2010 à 20:58 (UTC)Répondre

Pour les cas comme l'inversion du nom et du prénom, nous ne sommes pas concernés. Nous serions plus intéressés par la possibilité de légèrement paramétrer l'ordre alphabétique pour une langue donnée (comment traiter les tirets dans cette langue, par exemple), mais c'est apparemment prévu.

Donc, tu participes bien au logiciel MediaWiki ? J'étais persuadé que c'étaient des salariés de la fondation qui s'en occupaient, que ce n'était pas un logiciel collaboratif. Comment on fait pour participer ? Lmaltier 11 décembre 2010 à 21:06 (UTC)Répondre

Les salaries de la Fondation sont très peu nombreux mais ne s'occupent pas du logiciel lui-même (ou très peu, seulement pour l'organisation et la gestion financière des ressources, commandes, factures à payer), car même les décisions stratégiques se font en comité ouvert (par élection et/ou cooptation). Les contributions au logiciel ne sont d'ailleurs pas ouvertes aux seuls projets Wikimedia, mais à tous les utilisateurs et administrateurs de sites wiki. Ca se discute, certains font des modules, les internationalisaent, et la Fondation n'intervient que pour organiser l'adoption ou non d'un nouveau module sur ses serveurs (après avoir fait des tests, y compris de montée en charge, afin de ne pas planter les sites du jour au lendemain). N'importe qui peut proposer, discuter du logiciel sur son site dédié, via Bugzilla, les IRC et mailing-lists. verdy_p (d) 11 décembre 2010 à 21:39 (UTC)Répondre

w:MediaWiki indique :

• environ 195 développeurs qui ont accès en écriture aux sources officielles. Ce sont les SVN committers, terme venant de la commande commit du programme subversion, qui permet de transmettre les modifications sur le serveur central ;
• un certain nombre de développeurs d'extensions à MediaWiki, sans privilège sur le dépôt subversion de la Wikimedia Foundation ;
• un certain nombre d'utilisateurs et testeurs actifs sur bugzilla, déposant bugs et/ou patchs.

Si je comprends bien, on peut développer des extensions de manière totalement libre (et donc prendre dans ces extensions les décisions qu'on veut), mais sans avoir le droit de modifier les sources de MediaWiki.

Oui, mais même si on n'a pas les droits SVN, il y a aussi des repositories indépendants pour certains projets (qui peuvent même recevoir une internationalisation via translatewiki.net qui est aussi indépendant de la Fondation). De temps en temps des extensions jugées stables et utiles peuvent être reproposées pour l"intégration aumoins partielle de certaines de leurs fonctionalités. MediaWiki est un logiciel ouvert et pas destiné uniquement à Wikipédia ou au Wiktionnaire, il y a des tas de sites privés commerciaux qui l'utilisent aussi pour leur documentation ou leurs projets internes ou des bases de données payantes (et pas nécessairement des sites collaboratifs non plus)... Le nombre d'extensions est donc impressionnant (parmi elles on trouve plein d'extensions pour le ecommerce, la publicité, le CRM, l'ERM, l'analyse financière et des tas d'interfaces avec diverses bases de données métier, des logiciels comptables, boursiers, la gestion de catalogues produits et tarifaires, les portefeuilles commerciaux,, l'animation commerciale, des applis scientifiques, et aussi bon nombre de bases de références documentaires et bibliothécaires... UCA est déjà utilisé dans un certain nombre de ces extensions) verdy_p (d) 11 décembre 2010 à 22:10 (UTC)Répondre

Et puis, il y a 195 développeurs MediaWiki réels, qui ont le droit de modifier le logiciel (je suppose que c'est après beaucoup de discussions).

De laquelle des deux catégories parlais-tu ? De laquelle fais-tu partie ? Lmaltier 11 décembre 2010 à 21:50 (UTC)Répondre

Concernant les tirets, UCA ne prendra pas en charge ce genre d'exception tout seul. Cela s'oriente vers la gestion des règles de tri telles qu'elles sont discutées et standardisées via le projet CLDR (maintenant hébergé par Unicode). Il n'est pas encore prévu de supporter des tailorings plus complexes, sauf si on peut formaliser cela de façon générique pour une locale (par exemple, aux moins deux tris pour l'allemand, le standard allemand, le standard suisse). Gérer des options spécifiques doit pouvoir se préciser dans un identifiant de locale BCP 47 (voire la nouvelle RFC publiée par Unicode ces derniers jours à ce sujet, qui permet de passer des options de tri ; options désormais intégrées au registre IANA).

Il ne semble pas qu'on pourra faire des tailoring dynamiques, mais l'option retenue utilisera une liste de locales supportées avec lesquelles il faudra composer. L'une d'elle sera présente sur tous les wiki (ce sera le tri de la locale "root" de CLDR, uniquement basé sur la table DUCET sans aucun tailoring, qui devrait être le tri par défaut, l'autre sera le tri standard dans la langue par défaut du wiki, mais chaque wiki pourra préciser plusieurs tris pris en charge par défaut dans toutes les catégories sans qu'il soit nécesaire de mettre quoi que ce soit dans les pages de catégories). L'utilisateur aura le choix du tri avec des options affichées dans la catégorie dans un sélecteur et via l'API (paramètres de requêtes URLs) ; la solution devrait tenir compte aussi (sans que l'utilisateur ait besoin de répéter ce choix à chaque catégorie visitée, de sa locale par défaut (donc en plsu du choix de la langue dans son profil, on pourra aussi préciser le tri préféré dans cette langue, parmi ceux supportés). Devrait apparaître une page spéciale destinée à gérer ou lister les tris supportés.

Mais je n'affirme rien, pour l'instant, tout cela reste encore expérimental et il y a beaucoup de chemin à faire (et pour chaque langue supportée actuellement il va falloir affiner les tris proposés, mais on aura au minimum le tri DUCET (CLDR "root") dans toutes les locales (et sans doûte encore le tri binaire UTF-8 pour la compatibilité au moins transitoirement, mais ce ne devrait plus être l'option par défaut).

La mise à jour prendra aussi du temps sur les gros wikis et demandera des ressoruces serveur importantes pendant des jours, et ne se fera sans doute pas sur tous les wikis en même temps, les catégories étant traitées alors une par une avant qu'un nouveau tri y apparaisse ou y soit sélectionnable.

Les filtres de tailoring seront ensuite à affiner et on pourra alors procéder au nettoyage de certains groupes de clés devenus inutiles dans les articles, une fois un tri de base mis en place, puis ajouter de nouvelles locales de tri.

Tant tout ça il y a beaucoup d'idées, tout reste à planifier, je ne sais pas dans quel ordre tout cela apparaîtra ici en pratique, mais du code est déjà proposé. verdy_p (d) 11 décembre 2010 à 22:10 (UTC)Répondre

Où peut-on y avoir accès, à ce code ? J'ai vu des propositions sur le site MediaWiki, effectivement, mais c'est tout. Et ça ne parlait pas vraiment des questions concrètes. Lmaltier 11 décembre 2010 à 22:16 (UTC)Répondre

Bonjour. Puisque tu as créé la structure des modèles de codes de langue sur Wiktionnaire, tu t’intéresseras probablement à participer à Wiktionnaire:Prise de décision/Modèles de codes de langue. — TAKASUGI Shinji (d) 15 avril 2011 à 04:18 (UTC)Répondre

… et sera bientôt supprimée. --GaAs 17 mai 2011 à 21:00 (UTC)Répondre

Il y en a une... CC-BY-SA comme indiqué depuis le début. De toute façon cette image je m'en fous c'était uniquement dans le cadre d'une vieille discussion ici, et pas pour un quelconque article. C'était pour illustrer un problème évoqué dans cette discussion de la Wikidémie en décembre 2008. verdy_p (d) 24 mai 2011 à 22:16 (UTC)Répondre

Ah oui, pardon (il fallait de bons yeux). Néanmoins je l'ai supprimée, car si vraiment la CC-BY-SA est applicable, autant la mettre sur Commons (mais je ne donne pas cher de sa peau là-bas). Amitiés. --GaAs 4 août 2011 à 17:33 (UTC)Répondre

J'ai annulé tous tes essais sur cette page (sauf l'intro). Ça ne veut pas dire que je les trouvais « stupides », au contraire. Mais il était temps, àmha, que cette page présente au moins un minimum de choses valides. --GaAs 4 août 2011 à 17:39 (UTC)Répondre

Bonjour. Pour information : J'ai tenté de résumer les volumineuses notes que tu avais ajouté, mais petit à petit j'ai fini par les supprimer soit qu'elles étaient redondantes, hors-sujet ou "encyclopédiques". Les liens logiques entre les informations m’ont aussi paru confus. En fait, je pense que la précision "non-synonyme" que nous avons rajouté dans les définitions suffit à lever toute ambigüité. Stephane8888 ✍ 30 mai 2012 à 08:07 (UTC)Répondre

Comme à tous les patrouilleurs, je t’adresse ce message : Wiktionnaire:Bulletin des patrouilleurs existe désormais, et est fait pour toi. Merci de venir y participer, et sutout d’y aider ceux qui posent des questions.--GaAs 1 juillet 2012 à 17:11 (UTC)Répondre

Cette page n'est pas la page appropriée pour faire de longs paragraphes sur les codes langues, ce n'est pas du tout son objet (comme son nom l'indique). Lmaltier (discussion) 7 décembre 2012 à 22:22 (UTC)Répondre