Merci. Ces modèles sont sympathiques, ne peut-on vraiment pas les mettre en minuscules ? Car il me semble que les majuscules soient plutôt réservées aux modèles "système". Qu'en pensent les autres ? Stéphane8888discuter2 novembre 2008 à 13:14 (UTC)[répondre]
On pourrait par exemple convenir que le nom est suivi d'un point d'exclamation (par exemple mdr!)... Ceci dit, même si ça peut servir en pratique, il faut essayer que ce qu'on dit soit clair indépendamment de ça. Tout le monde n'est pas expert là-dedans, alors que tout le monde ici parle français, en principe. Lmaltier2 novembre 2008 à 13:59 (UTC)[répondre]
Tu noteras que vouloir signer avec une binette classique commençant par un deux-points, il faut être un peu expert (utiliser nowiki ou mettre en gras ou italique ces yeux, car mettre un espace avant ne produit pas le résultat attendu), sinon il manquera les yeux si on signe en début de ligne ! verdy_p6 novembre 2008 à 19:56 (UTC)[répondre]
PS : vous remarqué la signature de Spacebirdy ? (:> )=| Excellente, non ?
Est-ce qu'il y a une convention pour les exemples en langue étrangère ? Je n'ai rien trouvé sur l'Aide. Contrairement aux exemples en français, il faut ajouter une traduction à la phrase d'exemple. Est-ce qu'on met aussi une éventuelle romanisation ? Qu'est-ce qu'on met en italique ? J'ai essayé un exemple très simple sur 马.
Koxinga2 novembre 2008 à 03:48 (UTC)[répondre]
Bonne idée. L'indentation permet de distinguer plus facilement l'exemple de sa traduction... surtout s'il y a beaucoup de longs exemples. De plus, cela permet d'ajouter une éventuelle romanisation. Il y a assez peu d'exemples présents dans les sections de langues étrangères. Autant en profiter pour établir les grands principes. ;-) Stéphane8888discuter3 novembre 2008 à 15:17 (UTC)[répondre]
Je voudrais relancer cette discussion, et cette fois-ci en prenant une décision formelle. La notion de langue est fondamentale pour le projet, et le choix du nom qu'on adopte comme standard également, à mon avis. Je pense qu'il faut respecter l'usage, à la fois pour ne pas désorienter le lecteur et par souci de neutralité. Choisir un nom sur la simple base de ce qui est utilisé par un organisme ne marche pas, parce que différents organismes peuvent utiliser différents noms, et aussi parce que ça peut désorienter les lecteurs quand le nom ou l'orthographe est très rare, ou ne pas être neutre (on n'a pas à promouvoir un nom ou une orthographe rare par rapport à un nom courant). Je pense qu'il pourrait y avoir consensus là-dessus (j'espère).
Je propose d'officialiser la règle suivante, de la ranger dans une page d'aide, avec référence à la discussion et à la décision, et de corriger les modèles qui ne la respectent pas :
si un seul nom est utilisé en français pour désigner la langue, on le prend, bien sûr (par exemple : russe)
s'il existe en français un nom usuel pour la langue (de toute évidence plus courant que les autres), on adopte ce nom (par exemple : espagnol plutôt que castillan, bien que castillan ait aussi des avantages),
s'il existe en français une orthographe usuelle pour le nom de la langue (de toute évidence plus courante que les autres), on adopte cette orthographe (par exemple : yiddish plutôt que yidiche),
s'il y a plusieurs noms ou orthographes usuels, sans qu'aucun se détache très nettement, on adopte le même nom que Wikipédia (pour être cohérent entre projets); un exemple possible serait de choisir irlandais plutôt que gaélique irlandais comme actuellement (mais c'est peut-être un mauvais exemple, car je ne sais pas si un des noms se détache nettement ou non),
si ce n'est pas possible d'appliquer les critère précédents, par exemple, deux noms usuels d'usage en gros équivalent (ou tous les deux très rares), et page Wikipédia inexistante, ou bien deux langues avec le même nom usuel (d'où conflit), le nom est choisi après discussion.
Pourrais-tu mettre des exemples pour les 4 possibilités pour bien illustrer. Je ne vois pas trop ce que tu veux dire. Excuse-moi, mais c'est pour pouvoir voter sans me tromper. -Béotien lambda2 novembre 2008 à 12:48 (UTC)[répondre]
Le 20 novembre est passé (depuis une semaine). Personne n'a voté dans la partie "contre". Les deux réticents n'ont pas répondu à l'argument de base : Choisir un nom ou une orthographe très minoritaire, cela perturbe les lecteurs, et cela n'est pas neutre (alors que la neutralité est une exigence non négociable de la fondation). Je propose donc de conclure le vote positivement. C'est d'autant plus urgent qu'il y a encore eu un renommage anormal aujourd'hui (de provençal en occitan provençal). Provençal est beaucoup plus courant, c'est évident (pour un Français, tout au moins). (attention, je ne parle pas du code, ni de la bonne façon de traiter le provençal, qui n'est pas évidente, voir discussion dédiée ci-dessous, mais uniquement du nom choisi) Lmaltier27 novembre 2008 à 17:38 (UTC)[répondre]
Pour la question du caractère vague de mots comme usuel : les premiers critères ne doivent s'appliquer que quand il n'y a pas de doute, c'est ce que j'entends par de toute évidence.
Est-ce qu'on peut supprimer les premiers critères, et simplement s'aligner sur Wikipédia ? C'est vrai que ça reviendrait au même presque tout le temps, mais je me méfie de Wikipédia, parfois : le dernier changement que j'y ai fait était pour corriger une phrase prétendant qu'appeler le dioxygène oxygène était incorrect, alors que c'est le mot utilisé par 99 % des gens (et même sans doute beaucoup plus)...
Je précise que le gaélique irlandais, est un exemple qui vient de moi, et qui est à mon avis un compromis bâtard, et jamais utilisé dans le langage courant, entre deux usages, gaélique tout court (le plus fréquent mais faux car l'écossais et le mannois sont aussi des gaéliques) et irlandais (moins fréquent mais conforme à l'usage local et pas ambigü).
Si on est clairement dans ce cas 4 (et pas dans un des précédents), la proposition est de prendre irlandais, comme Wikipédia. Cela ne me semble pas choquant.
Est-ce que gaélique est réellement le plus fréquent, est-ce bien sûr ? Et si c'est le cas, est-ce que ce ne serait pas la forme abrégée de gaélique irlandais, tout simplement, utilisée quand aucune confusion n'est possible ? Si c'est ça, on devrait considérer que le nom qui domine est gaélique irlandais, même s'il est souvent abrégé, et donc ne pas changer notre pratique actuelle.
Je tiens à préciser que le mot gaélique tout seul désigne normalement l’écossais (à ne pas confondre avec le scots). Et l'irlandais n'est que rarement affublé du terme géalique à cause justement de la confusion possible avec l’écossais. En fait gaélique désigne ue famille de langues (dont l’écossais, l'irlandais, etc...) Si le mot "gaélique" est communément utilisé au lieu de "écossais" c'est à cause justement de la confusion possible avec le scots (l'autre langue écossaise). Aussi je penche pour maintenir "gaélique écossais"/"Sottish Gaelic" (contre toute confusion possible), et "irlandais"/"Irish" tout court (comme le fait l'ISO 639, et The Ethologue dans le nom pris par défaut) verdy_p14 novembre 2008 à 16:36 (UTC)[répondre]
Par ailleurs, une règle, de toutes façons, peut toujours connaitre des exceptions, décidées après discussion. Simplement, il faut vraiment que ces exceptions soient justifiées, pour des cas exceptionnels (et on peut améliorer la règle pour les prendre en compte). Lmaltier5 novembre 2008 à 07:41 (UTC)[répondre]
Je proposerais de supprimer fr1835 (qui avait été créé à titre expérimental), mais c'est peut-être une question un peu différente : qu'est-ce qu'on appelle une langue ? Lmaltier5 novembre 2008 à 09:08 (UTC)[répondre]
Attention au point 2 et la façon de l'évaluer; l'usage ne se mesure pas à une recherche sur Google, où bon nombre d'auteurs ignorent tout bonnement s'il existe un nom français défini. Par exemple ici "yiddish" peut paraître usuel, alors qu'il s'agit d'un emprunt arbitraire à l'anglais, utilisé par méconnaissance sourtout. Ce n'est même pas l'orthographe originale du nom en yiddish (qui utilise une orthographe allemande avec un "j" et non on "y"): l'anglais a adapté l'orthographe yiddish car le "j" en anglais se prononce différemment. Il n'y a pas de raison de prendre cette adaptation anglophone et d'ignorer l'adaptation à l'orthographe française surtout quand elle existe. Donc avant de chercher la "popularité", il faut d'abord s'interroger sur l'existence d'une recommandation officielle, d'autant que le Wiktionnaire est là justement pour faire référence aux recommandations orthographiques propres au français en évitant les imports abusifs. Le mot "yidiche" n'est pas inventé, il résulte d'une recommandation (et le wiktionnaire n'a qu'à donner l'orthographe alternative dans un article lié). Le Wiktionnaire se veur pédagogique, et doit aider les lecteurs à rectifier leurs usages et clairement identifier les orthographes d'origine étrangère en ayant conscience de l'étymologie. Et tant pis si cela ne correspond pas (pas encore) à ce qui est dans Wikipédia, car l'usage peut changer, notamment pour un terme d'usage rare en français hormis nu nombre limité de spécialistes de cette langue pratiquement pas utilisée en France (et dans ce cas il faut revenir à la source de cette langue, et aux recommandations adoptées).
Note: je n'ai pas fait de renommage n'importe comment dans les articles: plus aucun nom "en dur" n'est utilisé (contrairement à ce qui était là avant, notamment pour les catégories thématiques insérées manuellement dans les articles), mais tout fait référence au modèle {{yi}}, de sorte qu'en cas de nouveau changement de nom, il n'y aura pas des dizaines ou centaines d'articles à modifier plus tard, mais seulement ce modèle. Cette façon de procéder facilite le suivi et la résolution ultérieure de possibles conflits ou de changement possible de convention de nommage.
Il y a d'autres langues qui ne respectent pas les références officielles, mais elles sont nettement plus rares que le yidiche, et ont très peu d'infos liées à leur nom dans le Wiktionnaire. Je me contente de vérifier les sources officielles (dont la source officielle ISO 639-2), et m'assurer qu'aucun conflit de nom ne subiste et que toutes les catégories en doublon sont fusionnées, et correctement sous-catégorisées. J'ai relevé des erreurs dans une page de test, mais j'ai fini à priori les tests pour les langues de l'ISO 639-1, je continue les vérifications sur l'ISO 639-2, et l'ISO 639-3 n'est pas encore vérifié au delà des références actuelles les plus courantes du Wiktionnaire. Cela fait déjà près de 400 noms vérifiés et hormi le yidiche je n'ai pas encore trouvé de grosses erreurs ou conflits à corriger.
Je prépare d'ailleurs une page complète de vérification (déjà très avancée) puis plus tard, une fois les modèles uniformisés, une page synthétique de liaison des codes langue, avec leurs liens et données de référence concernant leur classification, leur nommage et leur codification dans l'ISO ou sur les projets Wikimedia. Il y aura un tableau général avec tri multicolonnes pour faciliter les recherches, au lieu d'avoir à éditer des tas de pages différentes non maintenues et contradictoires entre elles ou incomplètes. Avec ce système, il sera possible de générer automatiquement aussi la plupart des pages de catégorie et fournir des infos complémentaires à destination des non-francophones et outils d'analyse. Et on aura un système de nommage blindé et facile à administrer de façon centralisée; d'autant que nombre de noms français de langues présentes uniquement dans l'ISO 639-3 sont provisoires, et même l'ISO 639-3 subit encore de nombreuses et fréquentes corrections (y compris des suppressions de code, fusions, scissions, reclassification en macrolangues), qu'il serait bon de faire suivre aussi dans notre Wiktionnaire (à ce sujet, le Wikitionnaire devrait éviter de référencer dans les traductions toutes les macrolangues si cela infue sur l'orthographe (donc exception faite de la langue arabe et du chinois en écriture idéographique: les distinctions apparaissent lorsqu'on utilise une autre écriture pour ces langues, par exemple pour les transcriptions, et ces transcriptions nécessiteront alors une catégorisation spécifique propre à chaque langue et non à la macrolangue). verdy_p5 novembre 2008 à 08:58 (UTC)[répondre]
Une précision : l'usage, c'est l'usage. Si 99 % des gens utilisent une orthographe, il faut considérer que c'est l'orthographe usuelle, et non pas considérer que ces 99 % se trompent. C'est justement le sens de la proposition. Google peut aider, et aussi Google livres (dans les cas probablemenet très rares où il y a contradiction flagrante entre Google et Google livres, on peut considérer que l'orthographe usuelle n'est pas évidente, et se rabattre sur Wikipédia). Lmaltier5 novembre 2008 à 09:08 (UTC)[répondre]
(conflit de modif avec Lmaltier) "Donc avant de chercher la "popularité", il faut d'abord s'interroger sur l'existence d'une recommandation officielle, d'autant que le Wiktionnaire est là justement pour faire référence aux recommandations orthographiques propres au français en évitant les imports abusifs". Pas d'accord. Les recommandations officielles sont une information très intéressante pour le Wiktionnaire (on doit en faire mention), mais c'est l'usage, la popularité qui prime. Pour yiddish/yiddiche, la différence de fréquence est énorme et nous ne pouvons ni ne devons l'ignorer, même si l'une des deux orthographe peut être considérée comme "fautive" par certaines recommandations ou par une analyse de l'étymologie. Markadet∇∆∇∆5 novembre 2008 à 09:13 (UTC)[répondre]
Et non, le Wiktionnaire n'est pas là justement pour faire référence aux recommandations orthographiques propres au français en évitant les imports abusifs, pas plus que Wikipédia n'est là pour relayer les positions officielles des gouvernements. C'est tout le contraire : comme Wikipédia, le Wiktionnaire a à rester neutre, il ne doit pas prendre position. Comme, pour le nom des langues, on est bien obligé de tout de même faire un choix (malheureusement), la proposition vise à faire le choix le plus neutre possible. Un autre exemple qui montre bien cette exigence de neutralité : le Wiktionary anglophone a des articles indépendants (et aussi complets que possible tous les deux) pour les orthographes anglaises et américaines (genre color / colour), afin de ne pas avoir l'air d'en privilégier une des deux. Lmaltier5 novembre 2008 à 09:40 (UTC)[répondre]
D'accord avec Markadet et Lmaltier. (L'exemple "colour/color" (après conflit de modif) va tout de même me faire bien gamberger...) La neutralité oblige à expliquer les positions de chacun, mais oblige parfois à choisir la forme majoritaire, sans quoi on privilégie une des minorités. La question de la popularité est tout de même assez bien tranchée par les moteurs de recherches et Google livres en particulier. Un tableau des langues "problématiques" serait un bon outil pour discuter et choisir.
Le principe d'utilisation du modèle {{yi}} que Verdyp suggère est excellent, (par exemple dans les étymologies, les {{-drv-int-}}, etc.) mais il faut qu'on choisisse un autre intitulé de modèle, car cela entre en conflit avec l'utilisation qu'on en fait dans la section {{-trad-}}. Notamment la catégorisation automatique. Voir aussi cette discussion. Stéphane8888discuter5 novembre 2008 à 10:16 (UTC)[répondre]
Le conflit sur masaï et massaï auquel on peut rajouter maa (les formes maasaï et masai semblent moins fréquentes en français) est un cas difficile à résoudre au vu des attestations. Compte tenu des fréquences d'utilisation très proches, de la neutralité de point de vue, de la concision de ces noms, le mieux serait peut être d'indiquer dans les modèles : {{=mas=}} et {{mas}} quelque chose comme : « maa, masaï ou massaï ». On peut imaginer une page "Wiktionnaire:Dénomination des langues en français" avec un grand tableau détaillant les différentes dénominations des langues décrites sur Wiktionnaire. Celle recommandée par telle norme francophone, celle (ou celles juxtaposées) retenue dans les modèles de langue. Le lecteur (imaginons qu'il recherche maassaï) pourrait d'emblée trouver la(les) correspondance(s) qu'on a choisi. Ce grand tableau devrait idéalement être accessible depuis la page d'accueil, depuis les articles relatifs aux dénominations des langues, depuis les modèles de langues... Ainsi notre choix, quand nous en faisons un, serait moins arbitraire. On pourrait modestement commencer par quelques langues. C'est utile ou pas ? Stéphane8888discuter6 novembre 2008 à 14:19 (UTC)[répondre]
Je pense qu'on pourrait juste adapter la page Wiktionnaire:Liste des langues, plutôt que d'en faire une nouvelle. Une fois réécrite (notamment en mettant la liste sous la forme d'un tableau, ce qui éviterais les redondances dûes aux ordres de tri, et en ajoutant pour chaque langue un lien vers sa catégorie etc.), on pourrait remplacer le lien de la page d'accueil actuellement pointé sur Catégorie:Langues vers cette page. - Dakdada(discuter)6 novembre 2008 à 14:38 (UTC)[répondre]
1. - Pas de problème.
2-5. - Nous devrions nous en remettre à ISO et Unicode CLDR pour les noms et graphies. Les graphies alternatives (par ex. yiddish) auront leur article, c’est entendu. Je crois que les cas où il existe plusieurs alternatives devraient être débattus au cas par cas. La Wiktionnaire:Liste des langues est un début dans cette direction.
Une remarque : ni ISO ni Unicode ne cherchent à normaliser le langage (et les noms de langues non plus), ils définissent seulement des codes normalisés. Ils utilisent des noms de langues, ils ne les normalisent pas (d'ailleurs, on ne peut pas normaliser le langage, à l'exception des langues artificielles, on peut seulement l'étudier). Lmaltier6 novembre 2008 à 18:18 (UTC)[répondre]
Note: la page de vérification est surtout une page de travail, elle est assez volumineuse et demande un écran large (au moins 1280 pixels en largeur); elle est pourtant encore incomplète et va probablement être remaniée pour des raisons pratiques d'utilisation (car justement elle n'est pas finie). J'y ai noté plein de choses, et je m'occupe de vérifier pas mal de codes et les annoter (OK j'ai fait deux renommages que d'autres n'ont pas apprécié, grace à cette page, mais dans l'immédiat je ne ferai plus de renommage, mais je renseignerai les infos encore manquantes). La page est complète concernant l'ISO 639-1, et en cours d'achèvement pour l'ISO 639-2. Elle n'est pas classée par code langue, mais par type de code et en fonction des anomalies trouvées ou infos manquantes.
Voilà cependant ci-dessous une autre page prête contenant une table complète des codes de langues ISO 639-1 (toutes sont totalement paramétrées), triable, avec les noms utilisés et documentés dans les modèles ou les autres noms référencés dans le Wiktionnaire. La liste affiche aussi les noms officiels français et anglais de l'ISO 639 (sans aucune modification, laisser ces noms ISO intacts). Une autre page est en préparation pour les codes ISO 639-2 (plus tard je ferai celle des codes ISO 639-3). Cette page est bien plus simple à utiliser, y compris pour la maintenance. Les liens rouges sont des noms pour lesquels il n'y a pas encore d'entrée dans le Wiktionnaire. Ne PAS toucher aux noms ISO qui doivent rester tels qu'ils sont dans la norme, sans aucune modification: faites attention si vous modifiez un modèle en changeant le nom par défaut à ce que cela ne touche pas aux noms ISO qui ont été vérifiés: si vous avez besoin de le faire dans la valeur par défaut, garder le nom français en réserve dans le nom ISO s'il n'est pas déjà là, et gardez l'ancien nom dans la liste des autres noms synonymes.
L'idée de cette page montre qu'il est possible de lister les noms alternatifs et les utiliser pour faire des titres améliorés, tout en conservant la centralisation des infos pour un paramétrage simple et cohérent partout dans le Wiktionnaire. Des infos provenant de l'ISO 639-3 pourraient s'y ajouter (notamment le type et l'étendue de la langue, et le code éventuel de la langue collective contenant la langue donnée, ainsi que les codes ISO 639-2 ou -3).
Voir Wiktionnaire:ISO 639-1. J'ai décidé de scinder pour l'instant la liste finale en plusieurs parties par type de code pour des raisons pratiques et de priorité afin de pouvoir afficher plus d'infos si besoin. Une liste contenant tous les codes et noms n'est pas encore possible (cela dépendra de l'avancement du paramétrage). verdy_p6 novembre 2008 à 18:30 (UTC)[répondre]
Voir encore une référence en provenance de la Bibliothèque Nationale de France, pusiqu’il s’agit de son référenciel de codes langues (basé sur les codes de la norme ISO 639-3 et d’autres normes bibliothécaires). On y voit toute une liste de noms en français et synonymes :
À ce jour c'est la seule référence à peu près complète pour les codes alpha-3 avec tous ceux de l'ISO 639-2 et une grande partie de ceux de l'ISO 639-3(à qui il manque encore une liste de noms en français, hormis ceux déjà normalisés dans les volets 639-1 et 639-2), mais attention les codes peuvent être différents dans l'ISO 639-3 (à rechercher: mise à jour des normes INMARC mentionnant les noms français).
Attention aussi dans cette liste certains codes sont des codes collectifs, le premier nom désigne le groupe de langue entier, les suivants désignent les langues individuelles faisant partie du groupe. Pour distinguer les codes collectifs, utiliser l’étendue normalisée dans l'ISO 639-3. En revanche même dans ce cas, les noms listés sont intéressants (pour leur orthographe française) pour les langues individuelles listées dans le groupe et qui ont reçu leur propre codification (différente du code collectif) dans l'ISO 639-3. verdy_p6 novembre 2008 à 19:33 (UTC)[répondre]
Eh oui, ce ne sont pas des pages du Wiktionnaire mais des pages de projet et de travail. Cependant la page simplifiée Wiktionnaire:ISO 639-1 se lit très bien en 800x600 (je n'ai pas essayé de la lire sur l'écran d'un téléphone portable!) ;o)verdy_p7 novembre 2008 à 06:00 (UTC)[répondre]
Votes (fin du vote le 20 novembre, je pense que ça laisse le temps nécessaire à la discussion)[modifier le wikicode]
Pourquoi pas mais ça me semble encore très vague. Des termes comme "usuel" et "courant" risquent de ne pas aider. Dans les exemples que tu cites pour les deux premiers cas, on est toujours d'accord avec Wikipedia. Pourquoi ne pas dire qu'on s'aligne sur Wikipedia quand c'est possible ? Si il y a débat, il a déjà eu lieu, probablement avec beaucoup plus de contributeurs bien informés qu'ici. Koxinga3 novembre 2008 à 07:33 (UTC)[répondre]
À la fois pour et contre. Le problème, c’est qu’on n’a aucune façon de déterminer « l’usage ». Google n’est pas du tout une bonne méthode à cause de son échantillon fortement biaisé. Même Google Livres est dangereux, parce qu’il ne compte que les pages (alors qu’il faudrait plutôt compter à tout le moins les ouvrages, mieux encore les auteurs). Enfin, l’usage c’est l’entropie. Quant à la cohérence avec la Wikipédie, j’oublierais ça car la qualité du français de cette dernière est très faible, en général. Enfin, la neutralité, ça n’existe pas : omettre de mentionner une controverse ou un raisonnement lexicographique, c’est prendre position. On peut tenter d’approcher la neutralité, mais c’est se leurrer de croire qu’on puisse l’atteindre. Urhixidur6 novembre 2008 à 15:09 (UTC)[répondre]
Je me permets de nuancer ta position concernant Wikipédia : particulièrement pour les titres, il y a un nombre non négligeables de contributeurs dont la passion est de discuter leur choix (pour les connaisseurs, cf Tōkyō/Tokyo ou endive/chicon), et souvent le résultat est bien plus fiable que d'autres sources. En particulier, il est intéressant de regarder les redirections et leur historique (mas(s)aï)). --Szyx6 novembre 2008 à 18:11 (UTC)[répondre]
Oui, il y a parfois des perles dans cette boue, tu as tout à fait raison. Dans le cas particulier de massaï, malheureusement, les pages de discussion ne contiennent à peu près rien qui soit lexicographiquement utile. Urhixidur9 novembre 2008 à 15:15 (UTC)[répondre]
Je vais passer le modèle {{-vidéo-}} de niveau 4 (il est de niveau 3). Il sera donc relatif à une section Nom, Adjectif, Verbe... au lieu d'être relatif à une langue. Car il y a plusieurs sections possibles dans une langue, par exemple avec glouton, robot. Le problème apparait clairement au niveau du sommaire, par exemple pour glouton :
1.2 Adjectif
1.3 Nom commun 1
1.4 Nom commun 2
1.5 Images vidéo
Après on aura :
1.2 Adjectif
1.3 Nom commun 1
1.4 Nom commun 2
1.4.1 Synonymes
1.4.2 Vocabulaire apparenté
1.4.3 Traductions
1.4.4 Images vidéo
La "charge serveur" de ce changement est faible : 3 pages concernées !.
La page d'Aide du modèle a déjà été modifiée en conséquence.
Je ne connaissais pas ce modèle :-) Il me semble que ce serait peut-être mieux de le présenter comme les illustrations, dans un cadre propre à droite des définitions ? Sinon, en attendant, il me semble que si on reste dans l'optique d'une section, alors oui ce serait mieux de changer le niveau. - Dakdada(discuter)4 novembre 2008 à 11:15 (UTC)[répondre]
Le cadre de Dakdada est séduisant : il est bien visible, il évite d'avoir une section supplémentaire. Je l'ai mis dans lit en cathédrale pour voir (j'ai centré le mot vedette).
Quid de l'utilisation de Youtube, Dailymotion... ?
Je trouve que les liens vers des vidéos auraient plus leur place comme sous-section de "liens externes" ou de "voir aussi", car la vidéo est souvent liée au concept plus qu'au mot, et parce que les liens seront souvent morts (et je pense qu'un lien mort est "moins gênant" en section "lien externe" que dans le corps de l'article). Markadet∇∆∇∆5 novembre 2008 à 23:17 (UTC)[répondre]
Pour éviter les liens morts, le mieux serait de se baser uniquement sur WikiCommons. On est bien d'accord que les illustrations (images ou vidéos) font davantage référence au signifié, et ne font que répéter la définition. Soit on considère cette redondance comme pouvant être utile aux étrangers, aux débutants en français (mais une photo suffit !). Soit (et c'est ma préférence) on réserve les vidéos dans les cas où la définition est floue (ex.: lit en cathédrale). N’oublions pas les cas très utiles des calligraphies chinoises et des langues des signes. Stéphane8888discuter6 novembre 2008 à 10:52 (UTC)[répondre]
OK pour le cadre si la vidéo (ou le clip sonore) est sur Commons ou un projet supporté par Wikimedia. Sinon ça passe dans la section des références externes (et pas besoin d'intégrer la vidéo dans un composant, il vaut mieux dans ce cas afficher directement le lien externe avec la description du lien, comme n'importe quelle référence externe, en bas de page). [Message du 7 novembre 2008 à 07:33 de Verdy_p]
La conclusion de Verdy_p me convient. La section Références est commune à toutes les sections (Nom, Verbe, etc) mais pour un simple lien (qu'on peut décrire) cela est moins gênant. Il n'y a pas d'impact sur le sommaire. On acte ? Stéphane8888discuter7 novembre 2008 à 11:10 (UTC)[répondre]
Ma conclusion n'impliquait pas qu'il fallait mettre totues les vidéos en références.
Il y a des cas où on peut les intégrer dans la page, si la vidéo est sur Commons, ou si elle est presque indispensable :
Les langues des signes par exemple, car s'il existe bien des systèmes d'écritures permettant de les représenter (par exemple le VisibleSpeech ou la symbolique Bliss), ces systèmes encore en gestation dans certaines communautés spécifiques, forment en fait de nouvelles langues à part entière (surtout les Bliss), ils sont encore très jeunes, très malconnus, et difficile à représenter informatiquement car c'est un système bidimensionnel (le VisibleSpeech surtout) et ces systèmes demandent une initiation spécifique (contrairement à la vidéo) ; ils n'ont pas le même niveau de support que le système de transcription Braille pour les aveugles, qui est un système d’écriture à part entière adapté dans chaque langue avec des conventions supplémentaires et des tas d'abréviations et d'informations contextuelles, car il n'est pas totalement réversible dans l'alphabet d'origine et il crée donc une nouvelle orthographe de ces langues spécifique au Braille).
Note : les langues de signes sont des langues totalement différentes des langues parlées, par leur syntaxe et leur vocabulaire : la phrase ne s'énonce pas du tout de la même façon, la nature grammaticale des termes est très différente, on ne conjugue pas les verbes mais on représente des adverbes de temps génériques seulement en cas de besoin (la langue des signes française par exemple est beaucoup plus proche du chinois que du français par sa syntaxe, même si cette langue permet aussi d'épeler orthographiquement des mots français ou d'autres langues, et qu'elle peut aussi se combiner avec une expression orale de la langue (pour lire certains mots sur les lèvres, mais il ne sont pas dans le même ordre que dans la phrase française si on combine cette langue sur les lèvres avec la langue des signes qui dicte alors l'ordre et dirige la syntaxe). verdy_p17 décembre 2008 à 02:54 (UTC)[répondre]
Autant j'étais pour le cadre autant je suis contre la section Références. Dans un article court comme lit en cathédrale, à la limite cela pourrait être visible mais dans glouton, par exemple, si on met une vidéo de petites bêtes à poils qui gigotent, c'est en fin de section Nom commun 2 qu'il faut la mettre pas au diable Vauvert de la section Français. Vidéo, c'est pour être vu, non ? Ce serait un comble ! Ou alors j'ai mal compris. -Béotien lambda7 novembre 2008 à 12:27 (UTC)[répondre]
Tout réside, en fait, dans l'intérêt lexicographique d'une vidéo. L'article chat mérite-t-il une image ? Oui : Un étranger peut comprendre. Une vidéo ? Non (tout le monde sait ce qu'est un chat). Pour glouton, pour robot, la vidéo sert davantage à découvrir comment ça bouge qu'à expliquer ce à quoi on fait référence. On n'est pas là pour expliquer à l'enfant sauvage, ou à la réincarnation de Louis XIV, les découvertes scientifiques. [pour cela il y a Wikipédia ]. Sans parler du contrôle de la pertinence d’une vidéo car on perd du temps à la visualiser. Néanmoins, les vidéos sont utiles pour les actions ((faire un) lit en cathédrale), les verbes... Un éternuement. On débute sur le sujet, alors restons très sévère sur le choix des vidéos.
Je résume les volontés de chacun :
pas de nouvelles sections : donc boîte au niveau des définitions ou lien dans Références
relatif à la section concernée : donc boîte au niveau des définitions ou section dédiée niv 4
que ce soit visible : donc boîte ou section dédiée avec encart
pas de liens morts : projets Commons car gestion des liens morts
sélection très rigoureuse : pas de redondance avec une possible image
Je propose Wiktionnaire:Citations et vous invite à donner vos avis, vos suggestions ici pour l'ensemble de la proposition et/ou dans la page de discussion Discussion Wiktionnaire:Citations en respectant les sections pour pouvoir suivre plus facilement les avis par sections. Merci.
dans Comment faire une citation ? en supplément de ce qui est proposé, qu'en est-il du renvoi dans la section référence en bas de la page, voir tabung, en utilisant les modèles {{périodique}} ( il en existe beaucoup d'autres suivant la provenance de la source), {{Références}} et autres modèles utilisés dans la section référence de WP, en ajoutant pourquoi pas, comme c'est le cas dans certains modèles de WP une option qui affiche un message très visible quand l'un des paramètres obligatoire n'est pas renseigné ?? Serpicozaure(discuter)5 novembre 2008 à 11:42 (UTC)[répondre]
un nombre inconnu (inconnaissable, voir plus bas) utilisant directement la syntaxe [[wikt:xxx]]
(ajouté suite à la question de Verdy) moins d'un millier utilisant la syntaxe [http://fr.wiktionary.org] [1]
Il serait bien de soigner notre vitrine en faisant une revue des mots concernés. Peut-être en piochant dans cette liste pour les travaux de la semaine ? --Szyx6 novembre 2008 à 23:35 (UTC)[répondre]
Il y a une page spéciale donnant la liste des pages utilisant des liens d'un espace de nom à un autre au sein du même wiki.
N'y-a-t-il pas une extension permettant de lister les pages de Wikipédia utilisant certains préfixes inter-wiki ?
Et il manque (pour tous les projets Wikimedia) une page permettant de rechercher les liens externes (http, https, ftp...) utilisés (si possible indexée par nom de domaine inversé par exemple "http://abc.exemple.com:80/chemin/page" trié en interne en "http://com.exemple.abc:80/chemin/page", afin de rechercher plus facilement les liens pourris et abusifs, et utilisant les noms de domaine IDN sous forme Punycode).
Ces deux outils seraient utiles aux patrouilleurs et débusqueurs de pages introuvables, sans avoir à télécharger, installer puis utiliser un énorme dump d'export de base de données, ni avoir un accès direct à la base SQL en ligne. verdy_p7 novembre 2008 à 06:19 (UTC)[répondre]
N'y-a-t-il pas une extension permettant de lister les pages de Wikipédia utilisant certains préfixes inter-wiki ? Non, à ma connaissance (ils ne sont pas considérés comme liens externes au sens du point suivant).
Et il manque une page permettant de rechercher les liens externes. Non, elle ne manque pas : Special:Recherche de liens (version non localisée, c-à-d qui fonctionne sur tous les projets : Special:LinkSearch).
D'une manière générale, les pages de ce genre, quand elles existent, sont mentionnées sur Special:Pages spéciales.
<soupir>
Je viens de passer une demi-heure à te répondre (je voulais être certain de ne pas dire de bêtise), et j'espère que cela sera utile.
orm désigne aussi l’oromo (générique) dans ISO 639-2 et ISO 639-3 (où il est effectivement codifié comme une macrolangue)
L’ISO 639-3 liste les langues individuelles comprises dans l'oromo (mais ne cite pas "oromigna" parmi les noms ou synonymes de ces langues individuelles)
Le mot "oromigna" semble désigner l'une de ces langues individuelles; cependant il est impossible de savoir laquelle précisément selon les données de l’ISO 639-3 et de l'Ethnologue; ce qui explique que le mieux qu'on puisse faire est d'utiliser pour l'oromigna le code générique de l’oromo.
Il est possible de citer seulement oromigna parmi les autres noms possibles de l'oromo utilisables en français (cependant je ne suis pas certain cependant que le mot "oromigna" soit réellement utilisé en français, je ne trouve que des références en anglais sur le web).
Le seul mot présent dans le Wiktionnaire dans cette langue est Oromoo qui désigne à l'évidence l'oromo (générique) et pas seulement une désignation locale d'une des langues individuelles représentées par la codification de l’oromo.
En cas de fusion effective des codes {{orm}} et {{om}} (ce qui serait souhaitable pour éviter les confusions de codes entre ISO 639-1 et ISO 639-2), il serait bon alors de fusionner les catégories nommées "en oromigna" (dans Catégorie:oromigna) vers celles "en oromo" (dans Catégorie:oromo),
C'est moi qui avait créé tout ça. Mais je n'arrive plus à retrouver pourquoi, ni où j'avais pris le nom oromigna. Ce qui est proposé me semble la façon naturelle de faire. Lmaltier12 novembre 2008 à 15:30 (UTC)[répondre]
La redirection de catégories ne devrait jamais se faire par un simple #redirect [[:Catégorie:...]] mais par utilisation d'une bannière de maintenance. En effet, cette redirection masque le fait que la catégorie redirigée avec #redirect peut encore contenir des pages qui ne seront pas listées dans la catégorie cible de la redirection (pour les voir il faut remonter le lien en haut de la page indiquant que la page affichée provient d'une redirection, et suivre ce lien).
Le modèle {{catégorie redirigée}}, que j'ai importé de Commons (avec plusieurs synonymes, avec ou sans capitale initiale, avec ou sans espace, et les noms anglais de Commons) et adapté ici, est fait pour ça : il autodétecte et catégorise les articles liés au nom d'une catégorie "redirigée", et autocatégorise les catégories redirigées non vides de contenu, ou dont la "redirection" est rompue (la page cible de la redirection ne pointe nulle part). Voir la documentation sur la page de ce modèle.
Donc, c'est une catégorie qui autocatégorise les redirections de catégories autoredirigées censées être vides et... ça a l'air compliqué à lire tout ça ^^. Plus sérieusement, ce sera très utile, mais il faudra bien penser à mettre ce modèle sur les catégories redirigées. - Dakdada(discuter)7 novembre 2008 à 15:19 (UTC)[répondre]
Pas compliqué du tout, regarde Catégorie:oromigna puisque c'est déjà fait, et consulte sa source. Même chose pour Catégorie:kara-kalpak qui est synonyme de Catégorie:karakalpak. Le modèle travaille tout seul pour repérer ces catégories et leur emploi. Les trois catégories de maintenance des catégories redirigées sont en place et visibles parmi les catégories spéciales de maintenance du Wiktionnaire.
Ce modèle permet de maintenir des catégories synonymes, au cas où..., puis d'indiquer à l'utilisateur où il doit reclasser ou retrouver ses pages. C'est exactement le même système en place sur Commons
C'est vrai que le modèle du bandeau est un peu ardu à comprendre pour savoir comment il marche : il utilise une fonction spéciale de MediaWiki ({{PAGESINCAT:nom de la catégorie}}) qui compte et retourne le nombre de pages dans la catégorie citée): si ce compteur est non nul, la page de catégorie redirigée est recatégorisée elle-même dans une catégorie de maintenance. Toute nouvelle page entrant dans une catégorie teste si la page de la catégorie utilise un tel compteur de pages, et dans ce cas, la catégorie est marquée comme étant à réévaluer en tâche de fond, ce qui permet de régénerer la page de catégorie et donc de recatégoriser toute catégorie redirigée nécessitant une opération de maintenance pour les pages qu'elle contient.
Je viens de (re)lancer Salebot sur le Wiktionnaire. C'est un bot qui surveille les modifications récentes et révoque le vandalisme. Il est actuellement en rodage et ne révoque pas encore les modifications.
Je voudrais lancer des discussions sur diverses modifications sur les modèles de langues, qui n'ont pas été discutées. C'est devenu tellement compliqué que je vais probablement en omettre, d'autant plus que je ne maîtrise pas du tout, merci de compléter en rajoutant les discussions que j'ai omises. S'il y a besoin, il faudra rajouter les votes correspondants. D'abord, la catégorisation des modèles de langue.
Au départ, le modèle fr ne générait que français. La catégorisation a été rajoutée, pour regrouper ces modèles dans une catégorie. Je ne vois pas dans quels cas cette catégorie peut être utile : on avait déjà une page récapitulative des modèles, ça suffit a priori pour les contributeurs (et cette catégorie n'est utile qu'aux contributeurs). Les inconvénients que je vois :
c'est un peu plus compliqué en interne au modèle
(peut-être, je ne suis pas du tout sûr de cet argument) le traitement du modèle est plus gourmand en mémoire, et augmente le risque de dépassement des limites du logiciel.
En tout cas, si on ne voit pas une utilité claire et importante, il faut simplifier en supprimant la catégorie, à mon avis. Qu'en pensez vous ? Lmaltier8 novembre 2008 à 21:17 (UTC)[répondre]
Tu parles de la catégorisation du modèle lui-même ? Je ne suis pas d’accord qu’on la supprime. Le Wiktionnaire est un des rares projets Wikimedia qui catégorise presque toutes ses pages de modèles, ce qui est très utile pour l’entretien, en plus de forcer les créateurs de modèles à réfléchir au pourquoi de leur création. Les pages listant ces modèles ne sont pas tenues à jour automatiquement par le logiciel, et peuvent devenir incomplètes très rapidement (sans compter les modèles considérés désuets). Grâce à la catégorisation des modèles, si je consulte la page d’un modèle de conjugaison en langue x (par exemple), en un clic ou deux je peux obtenir la liste des autres modèles comparables et ainsi trouver celui dont j’ai besoin. Utiliser la fonction pages liées avec un filtre peut permettre la même chose, mais ça prend plus d’expertise et est certes plus laborieux. Urhixidur9 novembre 2008 à 15:08 (UTC)[répondre]
Si seulement ça pouvait forcer les créateurs de modèles à réfléchir au pourquoi de leur création, ce serait bien. Mais je vois pas en quoi ça peut les aider de ce point de vue. Pour la mise à jour des listes de modèles de langues disponibles, c'est en partie lié à la discussion suivante : où et comment centralise-t-on l'information sur les langues ? Pour les cas où c'est utile, je n'ai pas bien compris. T'es-tu réellement déjà servi de cette catégorie ? Quelqu'un d'autre s'en est-il déjà servi ? Peux-tu donner un exemple plus précis où c'est vraiment utile ? Lmaltier9 novembre 2008 à 18:44 (UTC)[répondre]
Si tu parles bien de la catégorisation du modèle, je ne vois vraiment pas ce que ça coûte. Pas d'appel en plus, pas de texte inséré en plus, pas de fonction logique compliquée en plus, une syntaxe à peine plus complexe, un coût mémoire dérisoire. Je rate quelque chose ? Même si on ne voit pas d'intérêt actuellement, une catégorie ne coûte pas cher et peut être utile un jour, je suis d'accord avec Urhixidur que c'est toujours mieux qu'une longue liste manuelle.Koxinga9 novembre 2008 à 19:31 (UTC)[répondre]
La catégorie facilite énormément la maintenance (d'autant que la page de liste est très lourde à manipuler): du coup des codes sont ajoutés, et sont oubliés de la liste. La mise à jour de la lsite devient de plus en plus délicate, et il y manque chaque fois des infos, rajoutées manuellement et à mettre à jour sur plusieurs pages.
Ceci dit, cette catégorisation permet de séparer proprement les modèles, savoir ceux qui manquent ou sont redondants, ceux pour lesquels il y a des redirections à ôter des articles. Depuis que je me suis attelé à vérifier tous les codes langues, j'en ai trouvé pleins qui n'étaient pas mentionnés dans les listes, et il en manque encore, et d'autres qui étaient erronés. La catégorisation a permis de les détecter. Je considère ces catégories utiles à la maintenance car ces modèles sont très nombreux (plus de 2500 maintenant) et j'ai même du les sous-classer par type (avec quelques catégories supplémentaires de maintenance, qui peuvent être temporairement vides, mais servent au suivi du travail de reclassement et vérification).
Ces catégories de toute façon sont parmi la catégorie des Modèles du Wiktionnaire, donc internes à notre cuisine. Il est naturel d'y trouver des catégories de maintenance. verdy_p26 novembre 2008 à 14:33 (UTC)[répondre]
La catégorie des noms de langues va aussi être structurée pour faciliter les recherches de langues. Mais j'attends encore un peu de finir le nettoyage actuel (les derniers cas restants qui ne sont pas normalisés sont plus compliqués et plus longs à vérifier et corriger). Pour mois une catégorie vient toujours en premier avant la création (et la maintenance ultérieure) d'une liste qui reste toujours compliquée et lourde à mettre à jour, même si on préfère mener les utilisateurs vers une liste. Tant que la catégorie ne sert pas de vrac fourre-tout, et qu'elle est elle-même correctement nommée et catégorisée, cela ne pose pas de problème.
On voit des exemples de listes pas à jour partout sur tous les projets Wiki, alors que les catégories se maintiennent relativement mieux et de façon plus cohérente et globale (elles sont aussi plus pratiques que les longues listes d'utilisation de modèles générées par "what links here", où se mèlent aussi tous les articles utilisant un modèle donné ou les modèles basés sur un modèle de base). Elles ont leurs limites, mais sont indispensable à la gestion et au recensement exhaustif des contenus. La liste des langues n'étant pas stable (et loin d'être terminée, je préfère qu'on garde ces catégories, ne serait-ce que pour faciliter la maintenance et permettre de remettre à jour plus facilement les pages de listes) verdy_p26 novembre 2008 à 14:33 (UTC)[répondre]
Modèles de langues : ajout d'informations diverses : noms utilisés par l'ISO, etc.[modifier le wikicode]
Si on veut mentionner ces informations, il vaut bien mieux les mentionner :
soit sur les pages consacrées aux noms de langues (par exemple espagnol)
soit sur les tables récapitulatives des codes et des noms correspondants (en découpant la page en sous-pages si besoin est),
soit les deux.
Mais il n'y a aucune raison d'aller mettre ça dans des modèles, en mettant l'information mais en la cachant bien. Si on pense que c'est utile, il faut que ce soit accessible. En plus, il y a peut-être un risque que ça contribue à faire dépasser les limites du logiciel.
Par ailleurs, on peut parler à juste titre de codes ISO de langues, mais parler de noms ISO n'a guère de sens, il faudrait parler de noms utilisés par l'ISO-639.
L'idée de référencement est bonne (afin de bien savoir de quelle langue on parle). C'est vrai que placée dans un modèle, c'est moins visible. A moins d'appeler le paramètre correspondant. Là aussi l'idée de base de l'utilisation du modèle est de centraliser l'information. Stéphane8888discuter8 novembre 2008 à 23:15 (UTC)[répondre]
"Centraliser" dans divers endroits non suivis, et qui obligent ensuite à devoir les vérifier tous pour chaque langue me semble une mauvaise idée, alors que ces modèles sont extrèmement légers en terme de charge de travail. Il n'y a aucune complication pour les infos annexes qui seraient ajoutées, et qui n'alourdissent pas du tout le travail pour retourner le nom par défaut.
C'est bien plus simple de centraliser les infos à un seul endroit que de devoir modifier à différents endroits. Si ces infos sont là, c'est dans le but de pouvoir les afficher pour compléter l'information affichée par le nom par défaut, quand cette information serait jugée insuffisante. Cependant cela permet de ne pas avoir à multiplier les catégories (dont certaines ont été créées de façon très incohérente, ou en doublon, ou pour des langues inexistantes alors que ce sont des familles de langues).
Une seule page de suivi (commune et qu'il n'est pas nécessaire de multiplier) centralise tout à partir d'un seul modèle spécialisé par langue: une page technique, à usage des experts, et une page simple donnant la liste détaillée sous forme de tableau très lisible où on peut y chercher ce qu'on veut, et vérifier que les codes utilisés ne sont pas incohérents par rapport à d'autres normes (qui peuvent évoluer et nécessiter plus tard de la maintenance, et pour laquelle l'utilisation de méthodes automatisée simplifie le travail de mise à jour). verdy_p10 novembre 2008 à 11:36 (UTC)[répondre]
Mais c'est beaucoup plus simple de mettre à jour une information directement dans une page unique que d'aller chercher dans quel modèle elle peut bien se trouver... Beaucoup sont déjà découragés rien qu'avec la structure des articles qui utilise des modèles, alors là... Je ne suis pas le seul à être dépassé. Lmaltier10 novembre 2008 à 14:43 (UTC)[répondre]
Modèles de langues : ajout de formes diverses : féminin de l'adjectif, nom précédé de de, etc.[modifier le wikicode]
Ce n'est pas parce qu'on a un modèle qui génère un mot qu'il faut utiliser ce modèle à chaque fois qu'on veut utiliser ce mot. Il faut parler français, normalement, sinon les pages deviennent très vite incompréhensibles. Quand on juge qu'il y a utilité pour des modèles, ils doivent être définis pour un usage déterminé, et être réservés à cet usage, sinon on perd tout leur intérêt, puisqu'on ne peut pas les modifier sans prendre des risques pour des cas d'utilisation imprévus.
L'idée de rajouter ces diverses formes était visiblement de prévoir tous ces cas imprévus. Mais il suffirait qu'il n'y ait pas de cas imprévus pour prévenir les problèmes. On ne va pas quand même pas compliquer le modèle f pour pouvoir écrire Sous sa forme féminine, ... avec un modèle. Il faut écrire ça sans modèle, il faut écrire clairement ce qu'on veut dire, afin d'être compris par tous. Un dictionnaire papier ne va pas écrire : Les noms m. sont... même s'il a défini l'abréviation m comme signifiant masculin... Pour les langues, c'est pareil. Il n'y a aucune raison d'écrire dans une étymologie Du latin en utilisant un modèle. Je préférerais en tout cas que ce soit écrit en clair. Si on veut absolument un modèle, il faut un modèle spécialisé pour ça, pas un modèle qui sert à tout, et qui devient incompréhensible. On a déjà eu des problèmes de dépassement des limites du logiciel (alors qu'on n'est pourtant qu'au tout début du Wiktionnaire, créé en 2004), ça m'a traumatisé. Je ne veut pas que ça recommence, et je pense que ça ne va pas recommencer, à condition d'utiliser les modèles à bon escient, et de les conserver simples.
Pour finir, je pense qu'il serait sans doute mieux de revenir à la version initiale des modèles de langues (qui générait simplement le nom de la langue).
Je suis d'accord qu'il faut garder à l'esprit les limitations du logiciel. Cependant, tant qu'il n'y a pas de problème avéré, cela ne doit pas être la seule raison qui pousse à la simplification. Il faut aussi se servir au maximum des possibilités du logiciel et si cela apporte un avantage assez faible mais présent pour un coût acceptable en terme de performance, il faut garder les modèles tels qu'ils sont. Cela n'empêche pas d'essayer d'optimiser ou de trouver une meilleure solution. De plus, si un jour un problème se présente, on saura qu'on pourra agir rapidement en simplifiant ces modèles très utilisés. Cependant, tant que ce n'est pas nécessaire, cela ne me semble pas urgent.
La différence avec une abréviation de dictionnaire papier, c'est que là le modèle n'est pas visible à la lecture. Cela complique tout de même l'édition et il y a en effet de nombreux modèles dont je ne suis pas convaincu de l'utilité ({{ucf}} par exemple). Je reste tout de même un grand fan des modèles, et si seulement on avait utilisé des modèles pour les références aux dictionnaires qui sont sur toutes les pages de sinogrammes, je n'aurais pas à programmer un bot pour les modifier.Koxinga8 novembre 2008 à 22:01 (UTC)[répondre]
Je voulais parler de la lisibilité pour les contributeurs, ça aussi, ça compte. Et certains ont déjà été découragés à cause de ça. D'accord pour les modèles de référence, bien sûr. Je ne critique pas les modèles, seulement les complications injustifiées ou irréfléchies. Mais pour ce cas précis, quelle est ton opinion ? Lmaltier8 novembre 2008 à 22:05 (UTC)[répondre]
Je ne comprend pas forcément réellement l'intérêt de la complexité actuelle mais il ne faut pas être trop timide avec le logiciel et se servir des possibilités d'automatisation qu'il peut offrir. Si des gens se servent des codes de langue "améliorés" à l'intérieur d'autres modèles, l'intérêt commence à se voir, même si pour l'instant c'est un peu un marteau pilon pour écraser une mouche, puisqu'on n'a pas tellement de modèles à changer si on change un nom de langue.Koxinga9 novembre 2008 à 19:28 (UTC)[répondre]
Je suis bien d'accord : l'automatisation présente des avantages certains en terme de quantité de travail pour la maintenance, tant pour les contributeurs que pour le serveur, en évitant d'avoir à recourir régulièrement à des robots vérificateurs et correcteurs, et dont la charge de travail qu’ils imposent sur le serveur est très élevée, alors que leur nombre ne fait que s'accentuer. Et les autres avantages sont qu'il devient possible de suivre la catégorisation et l'adapter à de nouveaux problèmes, en autodétectant et sous-catégorisant des pages à vérifier par exemple. D'ailleurs tout le Wiktionnaire fonctionne déjà sur ce principe, et cela permet d'en augmenter la qualité et la cohérence. verdy_p10 novembre 2008 à 11:23 (UTC)[répondre]
Je trouve les modèles de codes de langue « augmentés » quasi-incompréhensibles, mais peu importe : dans un texte étymologique, le nom de langue doit être écrit en clair, ce qui fait que, pour un contributeur moyen, le seul endroit où il doit utiliser le code de langue, c’est dans la table des traductions. La page d’aide donnant la liste des codes (ainsi que les tables de traductions existantes) est tout ce dont il a besoin pour savoir lequel utiliser. Les bizarreries du modèle augmenté ne sont utiles que pour d’autres modèles, lorsqu’ils font de la catégorisation automatique, etc. Bref, il y a un niveau d’apprentissage requis avec les modèles, mais ce niveau n’est pas trop difficile, il me semble, et l’apprentissage approfondi n’est requis que des administrateurs et programmeurs de modèles. Un bon exemple serait {{fr-conj}}, qui est très lourd, mais dont l’usage a été grandement simplifié (grâce à des modèles intermédiaires) afin que la création d’annexes de conjugaison reste abordable pour l’éditeur moyen. Sommes-nous sur la même longueur d’onde ? Urhixidur9 novembre 2008 à 15:00 (UTC)[répondre]
C'est vrai que ces modèles peuvent sembler incompréhensibles, mais on ne les crée pas tous les 4 matins, et ils disposent chacun de leur page de test grace à la page d'aide commune qui explique ce qu'on doit y mettre.
Ces modèles sont déjà en place depuis un an et demi sur toutes les langues majeures, à une époque où pourtant il y avait d'autres soucis de performance que ces modèles nouvelle version ont aidé à régler; cependant la lourdeur n'était pas dans ces modèles de langue, mais dans le modèle {{trad}}, pour lequel j'ai trouvé et mis en place la solution qui a réglé efficacement le problème de l'année dernière, en permettant de mentionner des centaines de traductions par article. Cela est confirmé par les statistiques de génération insérées dans les commentaires HTML par le serveur.
Pour les concevoir il y a déjà tous les nombreux exemples similaires déjà renseignés (ainsi que ceux déjà montrés sur la page d'aide commune). Ils paraissent complexes mais sont très optimisés en terme de compacité, puisqu'ils utilisent pratiquement tous des valeurs par défaut à partir du nom par défaut: il suffit déjà de renseigner uniquement cette seule valeur (on prend l'exemple du {{la/type}} pour le latin qui est le plus simple et dont le code figure sur la page d'aide commune) pour que ça marche directement pour l'essentiel du wiktionnaire. Le reste des infos, ou la spécialisation peut s'ajouter par un contributeur plus expérimenté.
Maintenant vous arrivez tard, alors que ça a été discuté en début 2007... Vous ne faites que le découvrir aujourd'hui parce qu'ils sont généralisés à plus de langues (dont toutes les langues individuelles de l’ISO 639-1, déjà faites l'année dernière, et de l’ISO 639-2 depuis quelques jours).
Pour les contributeurs, cela ne change pas du tout la façon d'utiliser les codes qui pour l'essentiel sont déjà tous créés. Quand à la lourdeur très relative le coût se mesure en une dizaine d'octets par rapport à un modèle simple mentionnant le nom et une catégorie pour le modèle lui-même. Les "complications" relatives aux autres données que le nom par défaut n'empiètent pas du tout sur le fonctionnement du nom par défaut où ces données alternatives (et le sous-modèle commun qui les référence) ne sont même pas lues du tout ni même testées ou référencées par le serveur.
Cela ne répond en rien à la discussion sur l'utilité d'avoir introduit ces complications. Si quelqu'un se rappelle d'une discussion en 2007, merci de le dire et de mettre un lien. Lmaltier10 novembre 2008 à 11:27 (UTC)[répondre]
Note bien que si quelqu'un veut rajouter des codes (pour des langues à ajouter dans les traductions par exemple, toutes dans l'ISO 639-3 puisque les codes ISO 639-1 et 639-2 sont maintenant complets) selon l'ancienne méthode, cela marche encore immédiatement, même s'il manque des infos. Un plus expert passera derrière et remettra ça en forme facilement.
Il suffit de regarder toutes les pages de listes de codes actuelles pour voir qu'elles sont devenues difficiles à maintenir, et qui oublient de mentionner des infos, et ne sont pas à jour (il manque plein de codes sur ces listes, elles sont difficiles à vérifier; le seul endroit où on trouve tous les codes étant une catégorie interne où ils sont quasiment impossibles à trouver, pour un contributeur lambda, ce qui a pour conséquence que certains créent encore aujourd'hui des codes invalides ou en conflit avec d'autres langues ou désignant des familles de langues très différentes, ou encore sont des doublons synonymes alors qu'ils auraient pu être mentionnés pour éviter l'erreur de créer un code supplémentaire pour la même langue). verdy_p10 novembre 2008 à 11:43 (UTC)[répondre]
Quelqu'un a fait « pire » en les 6-8 octobre en rajoutant un test dans des sous-modèles séparés (qui doivent être lus par le serveur) pour le modèle {{trad}}} spécifiquement pour le chinois : http://fr.wiktionary.org/w/index.php?title=Modèle:trad&diff=prev&oldid=3525269. C'est une régression (en terme de temps de traitment et nombre d'inclusions par le serveur) par rapport à ce qu'il y avait.
Noter que le coût pour le serveur dépend très largement moins de la taille d'un modèle que du nombre d'inclusions de modèles distincts, et un {{#switch:}} dans un modèle unique a un impact totalement invisible; ce qui compte c'est d'abord le nombre de substitutions de paramètres et leur longueur (tous niveaux de récursion confondu) en terme de capacité mémoire, et le nombre de modèles à lire en terme de temps I/O. La longueur des modèles elle-même explose a un impact en terme de mémoire si ils sont passés en valeurs de paramètres d'autres modèles (ce qui n'est pas du tout le cas des modèles de langue discutés ici).
C'était évitable avec une astuce utilisant une info centralisée, et une convention de nommage. Le coût de cette modif s'impacte maintenant sur toutes les langues et sur chacune des insertions de traduction dans tous les articles, alors qu'on pouvait l'éviter même si on voulait un traitement spécial du chinois. En revanche je n'ai pas introduit de complication supplémentaire (pour le serveur) concernant les langues qui n'utilisaient pas encore la technique, notamment pour les traductions où figuraient toujours des modèles nouvelles versions depuis plus d'un an vers le français, l'anglais, l'allemand, l'italien, l'espagnol, le chinois.... verdy_p10 novembre 2008 à 12:01 (UTC)[répondre]
Oui, j'ai fait ça. Je ne savais pas que les performances du serveur étaient un enjeu aussi majeur et je pensais que la facilité et la cohérence d'édition étaient plus importantes. Je l'ai d'ailleurs fait sur une suggestion de Szyx (la discussion est au début de la page Wiktionnaire:Wikidémie/octobre 2008). Si ça pose un problème, je peux tout changer et utiliser un modèle {{trad-zh}}. Ceci dit, on est encore très loin des limites du logiciel.
Une page avec 1000 modèles trad et beaucoup d'arguments divers donne ce résultat :
C'est un cas déjà extrême, si on arrive à ce nombre de traductions quelque part, il va falloir faire des pages séparées, etc. Même comme ça, on est respectivement à 5%, 45%, 3% et 0% des compteurs.
Je reconnais que je ne connais pas la charge des serveurs. S'il y a un problème de ce point de vue là, je veux bien revenir en arrière. Bien sûr, s'il y a une meilleure façon de programmer qui ne change pas la syntaxe, c'est encore mieux.
Si on optimise trad, il y a d'autres choses à faire, par exemple enlever cette convention qui dit que si l'argument n'est pas là on met le nom de la page. Ça ne sert à rien et ça complique les modèles, les traitements automatiques, la lisibilité pour les nouveaux contributeurs, ça provoque des erreurs. Le plus souvent ce n'est même pas utilisé (voir Mali).
Je suis 100% d'accord sur le caractère néfaste du défaut du modèle trad (mais merci de ne pas changer ça unilatéralement, il faut regrouper les changements). Mais, SVP, merci de ne pas mélanger les discussions, pour qu'on s'y retrouve. Tout cela ne répond en rien à la discussion sur l'utilité d'avoir introduit ces complications. Si quelqu'un se rappelle d'une discussion en 2007, merci de le dire et de mettre un lien. Lmaltier10 novembre 2008 à 14:38 (UTC)[répondre]
Tu peux me dire ce que les modèles augmentés ont ajouté comme complication par rapprot à ce qu'il y avait avant ? C'est toujours la même syntaxe supportée, et rien ne change concernant les modèles trad. Seulement on a le cas à gérer des noms de langues parit-ils rares mais qui ont été mal orthographiés dès le début (justement par méconnaissance ou mauvais choix du code, ou mauvais renseignement d'un code langue qui a fait croire que c'était une langue unique, comme l'apache par exemple. Du coup on se retrouve avec des termes définis pour une langue inconnus, ou traduits dans une langue finalement tout aussi indéterminée. L'utilisation du modèle permettrait d'en faire un suivi plus facile, surtout pour les langues dont le nom en français est encore questionnable (il y en a beaucoup dans l'ISO 639-3 car la source ne mentionne que les noms en anglais, et on découvre plus tard des noms bien français en usage depuis longtemps).
Mon idée était aussi de centraliser les synonymes de langue pour pouvoir identifier une langue par l'un de ses synonymes (tout le monde n'utilise pas le même, ou certains "réputés synonymes" sont ambigus bien que d'usage plus fréquent que le nom plus précis.) Lors du nettoyage j'en ai découvert beaucoup, pour lesquels j'ai du lever les ambiguités par de longues et patientes recherches (la source de certaines traduction n'étant pas mentionnée, ça fait des heures de recherche dans Google, dans les autres Wiktionnaires, ou dictionnaires en ligne, dans The Ethnologue, etc.). Le recensement des synonymes a aussi permis de fusionner des langues qui avaient été créées séparément.
À ce sujet, mon travail a suscité l'intéret des auteurs de l'ISO 639-3 qui cherchent encore les moyens de produire une référence en français (ils travaillent dessus, mais ce n'est pas dit qu'ils en feront une partie normative équivalente comme dans l'ISO 639-2 ou 639-1 ; ils travaillent aussi avec les participants au projet CLDR d'Unicode pour supporter plus de langues que le seul français.)
Note :
Je suis un participant direct au CLDR depuis plusieurs années (et je suis mentionné parmi les auteurs importants, puisque l'essentiel de mes ajouts, commentaires ainsi que les votes pour la locale française ont été retenu dans déjà 3 versions de cette base de données ; à côté de ça, IBM, Apple, Adobe et Microsoft n'ont pas fait leur travail et bloqué des corrections indispensables en oubliant de voter depuis des mois, je ne peux être tenu responsable de leurs oublis qui ont fait que la locale CLDR française contient encore plein d'incohérences et que finalement chaque éditeur de logiciel participant ne s'en est pas encore remis à la version diffusée de CLDR mais conservent encore leurs propres traductions : ils ont déjà du mal à suivre les modifications nécessaires même en anglais ; s'ils avaient seulement fait un tour sur l'interface de vote, la locale française CLDR aurait été complète, mais de version en version, des erreurs se reproduisent et je doit revoter pour redemander les changements oubliés, en espérant qu'ils le feront aussi : dans le CLDR le premier qui ajoute un terme emporte la mise presque sans discussion, même s'il s'est trompé, et c'est très dur de corriger sans un nombre de votes suffisants, sachant que les éditeurs comme IBM, Apple etc. ont un poids énorme par rapport au nombre de participants puisque leur vote pèse 5 fois plus que les autres, et puisqu'en plus il faut un quorum supplémentaire pour corriger et un nombre de votes suffisants ; enfin un participant CLDR de poids important, Google, a commis énormément d'erreurs, dans toutes les langues auquel il a participé à partir de ses fichiers de traduction erronées collectées de façon automatique depuis ses bases de données internes).
C'est bien pour ça que je surveille les ouvertures de sessions du projet CLDR pour signaler très tôt les problèmes avant que les "gros" ajoutent leurs incohérences dans la locale française : quand ils viennent ils ont déjà mes propositions, et presque toujours les valident directement, et ça passe facilement. Je m'attahe à chaque fois à faire une traduction la plus exhaustive possible, cependant certains changements techniques auraient du nécessiter d'autres modifications dans les données de versions précédentes et seules les nouvelles entrées bénéficient des nouvelles règles.
La difficulté du projet CLDR vient aussi du fait que son interface est extrèmement lente, le serveur étant immédiatement surchargé par une seule requête (une validation de données pour un seul mot prend souvent plusieurs minutes, parfois plus de dix ! C'est un problème de qualité de conception du logiciel qui gère ça, très mal optimisé en terme de requêtes SQL et de modélisation. Il fait être TRES patient et persister durant le seul mois de l'année où la soumission de données est possible, puis le mois suivant pendant la phase de vote, et le deuxième mois pour tenter de résoudre les difficultés techniques empêchant la publication. La seule partie à laquelle je ne participe pas c'est la finalisation lors du 4e mois juste avant la release (cette partie se fait uniquement au CDLR TC, par un vote interne).
Dernière difficultés : la base de traduction (anglaise) ou les règles changent en plein milieu de la phase de soumission, et il ne reste plus assez de temps pour effectuer les changements avant la fin de session. On se retrouve alors à devoir voter uniquement sur des données incohérentes, sans possibilité de faire les corrections pourtant demandées.
Espérons que la nouvelle phase qui débute bientôt (version alpha du logiciel mis à jour en cours de test) sera bien plus rapide pour pouvoir corriger plus facilement et supporter tout le monde travaillant dans toutes les langues du projet (une seule personne connectée depuis Internet peut bloquer facilement tous les autres participants, même avec une seule soumission d'un seul mot dans une seule langue toutes les 3-4 minutes !!! Les places sont sévèrement limitées, et il faut savoir choisir son heure !).
Hello, sorry for writing in English, but I don't speak French; I hope we'll understand each other. There's an initiative on Polish Wiktionary to change favicon of Wiktionary from current one (the same as Wikipedia's favicon) to something different. In our opinion Wiktionary needs to distinguish itself from Wikipedia and the fact that it has the same favicon as its greater sister does not help to gain recognision as an independent and mature project. There's already a favicon ready to use: . I think you may be interested in choosing this as a new favicon, since it matches the French Wiktionary logo.
Will French Wiktionary support making a request on Bugzilla to change the favicon? Currently there's a support on Polish and German Wiktionary and no enthusiasm on English Wiktionary, so the plan is to request change only on those projects, which want it (so on pl, de and perhaps also fr). Greetings, --Derbeth10 novembre 2008 à 12:08 (UTC)[répondre]
Bonjour, désolé d’écrire en anglais mais je ne parle pas français ; je suis sur que vous comprendrez. Il existe une initiative sur le Wiktionnaire polonais pour changer la (icône du site, utilisée dans la barre d'adresse, devant le titre d'un onglet, ou dans une liste de liens favoris) actuelle du Wiktionnaire (qui est la même que celle de la Wikipédia) en quelque chose de différent. Selon nous, le Wiktionnaire a besoin de se différencier de la Wikipédia et le fait que la favicon soit le même que celle de sa grande sœur n’aide pas à obtenir la reconnaissance en tant que projet indépendant et mature. Il y a déjà une favicon prête à utiliser : . Je pense que vous pourriez être intéressé dans le choix d’une nouvelle favicon, car il correspond au logo du Wiktionnaire francophone.
Le wiktionnaire francophone appuiera-t-il une requête sur Bugzilla pour changer la favicon ? Actuellement, il y a un appui sur les Wiktionnaires polonais et germanophone mais pas d’enthousiasme sur le Wiktionnaire anglophone, le plan est de demander le changement uniquement sur les projets qui le veulent (pl, de, et peut-être aussi fr). Salutations, Derbeth 10 novembre 2008 à 12:08 (UTC)
Pour, j'ai beau ne pas aimer le logo actuel (pour de nombreuses raisons), il faut être cohérent, et ce sera en effet plus facile pour se démarquer des favicons des autres projets. - Dakdada(discuter)12 novembre 2008 à 10:30 (UTC)[répondre]
Note: la Wikipédia allemande voudrait aussi ajouter un petit DE affiché dans le coin inférieur-droit de l'icône actuelle W... Cela suggère qu'ils en voudront aussi un dans l'icône de leur Wiktionnaire. Le lien vers la discussion allemende est indiqué sur la page de suivi de la demande sur Bugzilla. verdy_p26 novembre 2008 à 14:40 (UTC)[répondre]
Puisqu'on est dans une période de grande discussion sur les modèles, j'aimerais qu'on discute un peu du modèle {{trad}} :
J'ai fait une modification assez radicale dans son fonctionnement récemment. J'avoue que je n'ai peut-être pas assez prévenu la communauté. Ce changement permet de spécialiser le traitement suivant les langues. Comme avant, tout commence par {{trad|langue|mot|... mais on peut ajouter des arguments supplémentaires si une langue l'exige. Pour l'instant, seul le chinois est séparé, j'ai ajouté un argument pour indiquer le mot en caractères traditionnels en plus des caractères simplifiés. Une traduction en chinois peut donc s'écrire : {{trad|zh|中国|R=zhōngguó|tradi=中國}}. Je suis d'ailleurs en ce moment même en train de toutes les uniformiser sur ce principe. Je ne sais pas quelles autres langues pourraient se servir d'un modèle spécifique, je pense principalement à l'hébreu et au japonais. J'ai aussi ajouté pour toutes les langues un paramètre R pour indiquer une romanisation, mais ce changement me parait beaucoup plus bénin.
Ma modification n'est pas la seule façon possible de traiter les langues "difficiles". Le chinois peut se contenter d'un seul modèle trad, avec un argument supplémentaire "tradi". Cependant, j'avais peur que cela devienne ingérable si on ajoute d'autres arguments pour d'autres langues. j'ai préféré essayer de construire un système de modèles qui facilite l'extension.
La pire solution à mon sens est de créer un autre modèle {{trad-zh}}. Soit on casse l'uniformité et les contributeurs occasionnels doivent se rappeler que pour le chinois, il y a une autre syntaxe. Soit on doit créer un modèle {{trad-langue}} par langue, ce qui n'est pas gérable non plus ;o) Ceci dit, c'est la solution la plus légère pour le serveur.
Les performances ne m'ont pas semblé être réellement un problème. Voir ci-dessus les chiffres, on est loin des limites du logiciel. S'il y a un problème avéré de charge serveur, bien entendu je m'incline. Koxinga10 novembre 2008 à 22:20 (UTC)[répondre]
Si, tu avais prévenu, et lancé une discussion, mais tu as peut-être été trop pressé de passer à l'action. La tendance de beaucoup est de toujours compliquer les modèles. Pour moi, les solutions les plus simples sont les meilleures (et ce n'est pas seulement une question de charge serveur ou de limites de logiciel). Quand j'ai créé des traductions dans des langues à plusieurs alphabets, j'ai simplement mis les traductions à la suite. On peut faire la même chose pour le chinois, éventuellement en mettant entre parenthèses (traditionnel) et (simplifié). Où serait le problème avec cette solution ? Lmaltier11 novembre 2008 à 08:22 (UTC)[répondre]
Traditionnel et simplifié ne sont que deux représentations du même mot. Par exemple, ils partagent la même romanisation. On doit pouvoir obtenir un résultat pas mal en utilisant deux modèles trad. Ce n'est cependant pas forcément mieux sur les performances et il y a des subtilités perdues (j'utilise des marqueurs zh-Hans et zh-Hant pour utiliser les bonnes polices, je développe si ça vous intéresse). La différence est surtout une différence de point de vue. En utilisant un modèle normal on peut obtenir un bon résultat mais on ne se sert pas des possibilités d'automatisation au maximum. Mon but est plus d'obtenir une source modifiable et exploitable automatiquement dans le futur.
Pour resituer la discussion, mon modèle est de la forme : {{trad+|zh|马|R=mǎ|tradi=馬}}, qui donne : 马(zh) (馬) mǎ. J'ai enlevé le lien interwiki sur la caractère traditionnel parce que je ne sais pas encore trop comment le traiter.
On peut faire quelque chose comme {{trad+|zh|马}} (''pinyin'' mǎ, ''trad.'' {{trad+|zh|馬}}), qui donne 马(zh) (pinyin mǎ, trad.馬(zh)), c'est pas mal. Par contre, une fois fait c'est impossible à modifier sans passage d'un bot.
Un simple ''simp.'' {{trad+|zh|马|R=mǎ}} ''trad.'' {{trad+|zh|馬|R=mǎ}}, qui donne : simp.马(zh) mǎ trad.馬(zh) mǎ, cela me parait moins acceptable, on voit à peine que les deux sont liés.
Ton modèle mets en avant les sinogrammes simplifiés par rapport aux sinogrammes traditionnels, ce qui est plutôt une mauvaise idée. Le chinois n’est pas parlé qu’en RPC et donc pas toujours simplifié. Cdlt, VIGNERON * discut.11 novembre 2008 à 14:16 (UTC)[répondre]
Bien sûr, mais il suffit de changer le modèle pour mettre le caractère traditionnel en avant et le caractère simplifié entre parenthèses, ou mettre les deux au même niveau mais je n'ai pas trouvé de façon légère et compacte de le faire. Idéalement cela pourrait être une décision de l'utilisateur mais cela compliquerait encore un peu le modèle. L'important pour moi est de les avoir dans le même modèle pour que leur relation soit claire. Koxinga11 novembre 2008 à 14:47 (UTC)[répondre]
Ta proposition ci-dessus (mettre (pinyin ....)) me semble bien, mais on devrait effectivement mettre à égalité les deux écritures, par exemple en les séparant par un ou. Et cela n'empêche pas cette information d'être traitée automatiquement plus tard, si on en a besoin, en utilisant un bot. Compliquer un modèle général au cas où ce serait utile un jour, cela ne semble pas une très bonne idée. Pour les subtilités de police, je ne comprends pas bien : afficher les caractères corrects, ça suffit, non ? Restons simple. Lmaltier12 novembre 2008 à 09:54 (UTC)[répondre]
Le problème est que afficher les caractères corrects n'est pas quelque chose de simple. Et ça ce n'est pas moi qui décide. Il y a des discussions dessus sur le wiktionary anglais, pas ici parce que personne ne s'y est intéressé je crois. Les caractères chinois sont utilisés en chinois mais aussi en japonais et coréen. Il y a de plus les caractères traditionnels et simplifiés. Unicode a essayé de représenter tout cela. Une solution aurait été d'affecter un code par caractère en chinois, un code par caractère en japonais, etc. Cependant, c'était un gaspillage de codes très important. Les auteurs ont donc décidé de regrouper certains caractères dans les différentes langues, y compris des caractères pas exactement identiques（voirw:en:Han Unification). En plus de cela, les gens peuvent avoir des polices de caractères différentes pour les différentes langues.
Certains caractères ont été simplifié, d'autres pas. Si on ne met pas de code, un navigateur configuré pour le chinois simplifié avec une police de secours pour le chinois traditionnel peut afficher un mot en traditionnel en mélangeant les deux polices, ce qui donne un résultat horrible.
Parmi les caractères unifiés, certains n'étaient pas exactement identiques. Il y a quelques exemples sur ma page perso, si vous avez les bonnes polices, vous pourrez voir des différences de ligne à ligne. Les différences sont minimes, mais dans un dictionnaire, je pense qu'il faut être irréprochable sur ce genre de détail.
La solution propre est donc de spécifier à chaque fois si on écrit en chinois traditionnel ou simplifié, en japonais, en coréen. Oui, c'est chiant. mais c'est recommandé (par exemple, ici).
Pour revenir à mon modèle, ce que tu dis est plutôt un argument pour. Il suffit que je le change pour obtenir les deux écritures "à égalité" (ou presque, puisque je prédis une bataille un jour pour savoir lequel on met devant). Pas besoin de bot. Je pense qu'il vaut mieux des modèles à la programmation plus complexe (complexité qui ne se voit pas à l'édition, il y a juste un paramètre facultatif en plus) et pas de bots, c'est plus "propre" comme solution, cela donne moins d'erreurs (voila ce qu'on obtient avec des bots : [2])Koxinga12 novembre 2008 à 12:06 (UTC)[répondre]
Quand une discussion est en cours, il vaut mieux ne pas préjuger de sa conclusion dans les modifications qu'on fait. Il y a en général plusieurs solutions à tout problème. Mais il serait bon que d'autres donnent leurs idées et leurs avis. Lmaltier12 novembre 2008 à 14:01 (UTC)[répondre]
Ce n'est pas un mépris de la discussion en cours, je ne préjuge pas du résultat. par contre, si tout est sous la même forme, il sera très facile ensuite de faire passer un bot pour donner la forme que l'on veut à chaque modèle. Là j'ai écrit un programme qui me permet de le faire très vite, mais il y a besoin d'une intervention manuelle à chaque fois. Vois ça comme un effort de standardisation pour rendre les traductions existantes plus maniables plutôt que comme une pression pour imposer ma solution ou quelque chose comme ça. Je m'étais organisé, je sais où j'en suis, j'ai une liste des traductions traitées et une liste des traductions à traiter (plus que 800 à faire). Même si on considère que mon modèle n'est pas satisfaisant, il vaut mieux finir cette étape avant de passer à autre chose. Koxinga12 novembre 2008 à 14:51 (UTC)[répondre]
Le chinois est ce qu'on appelle une macro-langue, contenant une bonne douzaine de langues au moins, écrites de façon plus ou moins phonétique en partageant un même répertoire de caractères. Ce répertoire ayant été revu et étant aussi partagé par d'autres langues, il en est subsisté deux orthographes qui ont parfois des sens distincts y compris en chinois lui-même (puisque c'est en fait la même écriture pour plusieurs langues parlées). Puisqu'ici il ne s'agit pas tellement de distinguer les langues parlées mais celles écrites, on peut voir le chinois écrit comme étantdeux langues distinctes regroupées dans la macro-langue. Il n'y a pas de raison de privilégier l'une ou l'autre forme écrite (simplifiée ou traditionelle, mais il y en a d'autres si on tient compte des variantes japonaises, coréennes, vietnamiennes anciennes, ou mongoles).
Je suis donc plutôt favorable à ne pas compliquer le modèle trad avec un paramètre: il vaut mieux dans ce cas utiliser les codes langue zh-hans et zh-hant et faire apparaître les deux traditions à égalité complète, commesi c'était des langues différentes. C'est bien plus simple à gérer, et cela ne casse pas les liens interwikis (j'ai déjà commencé à prendre en charge la conversions des codes langues en codes interwikis, de sorte que "zh-hans" et "zh-hant" utiliseront le même lien interwiki avec le code "zh"). Ce cas se reproduit pour d'autres langues, notamment celles supportant plusieurs écritures, ou pour les variétés dialectales (par exemple alsacien et suisse alémanique pour la même langue alémanique).
En revanche l'utilité du modèle modifié pour zh est uniquement pour la présentation : cela active des codes langue distincts dans le HTML généré pour afficher le mot, permettant aux navigateur d'utiliser la bonne police et d'afficher de préférence le bon caractère pour cette orthographe (codée de la même façon avec les mêmes caractères Unicode). Mais il n'était pas nécessaire du tout de surcharger le modèle trad pour ça avec un autre paramètre, il suffisait de passer directement les codes normalisés zh-hans et zh-hant suivant le cas !
Le cas du chinois reste unique, à cause justement de l'unification Han dans Unicode. Pour les autres écritures ayant nettement moins de caractères, l'unification n'a pas été faite en cas de distinction nécessaire à la bonne compréhension du texte codé: des caractères distincts ont été codés.
L'unification pour les écritures brahmiques a été aussi partielle, de même que pour l'hangûl du coréen, où subsistent les variantes contextuelles des mêmes lettres (notamment les voyelles dans les écritures brahmiques): cela a été fait pour des raisons de compatibilité avec d'autres normes plus anciennes et encore utilisées
En effet l'hangûl aurait pu utiliser nettement mois de caractères en ne codant pas toutes les formes précomposées, et en utilisant une lettre finale vide unique pour distinguer les consonnes initiales et finales dont le placement varie dans le carré de composition graphique, ce qui l'aurait fait ressembler à un véritable alphabet (ce qu'il est pourtant bel et bien: ce caractère vide était jugé indésirable bien que la forme graphique représente pourtant bien explicitement les séparations de syllabes, dont toutes les lettres sont assemblées dans le même carré). verdy_p26 novembre 2008 à 15:11 (UTC)[répondre]
Encore une fois je me rends compte quej'ai été trop long et pas assez clair pourtant.
Pour résumer, ma position est que si un même mot ou une même expression chinoise doit avoir deux graphies différentes dans les traductions, il vaut mieux écrire: * {{trad|zh-hans|中国}} * {{trad|zh-hant|中國}} d'autant que la romanisation dans ce cas peut-être différente entre le chinois simplifié et le chinois traditionnel, même en Pinyin, car la prononciation change dans certains cas.
Si la romanisation dépend du pays, la région ou la variété linguistique, je ne suis pas contre le fait qu'on ajoute * {{trad|yue|...}} ou * {{trad|zh-cn|...}} à la liste pour préciser la langue effective, au lieu du code générique "zh" pour le chinois (qui est un macrolangue et non une langue individuelle rappelons-le, et dispose donc de codes spécifiques pour ses langues individuelles). Cela n'empêchera pas de classer l'article dans une catégorie chinoise, ni de se lier au même Wiktionnaire chinois qui répertorie simultanément toutes ces variétés (les modèles de langue savent maintenant le faire en permettant de préciser l'interwiki ciblé).
Même chose pour le serbe : on peut avoir deux lignes l'une sous l'autre, une pour "sr-Cyrl", l'autre pour "sr-Latn", et malgré tout lier l'interwiki au même wiktionnaire serbe unique "sr.wiktionnary.org" pour les deux codes langue (sachant qu'une écriture peut être dans ce wiktionnaire cible et pas l'autre, le fait de les séparer permet aussi de l'indiquer avec trad+ et trad-).
Les paramètres optionnels sont à ôter des modèles trad qui devraient juste avoir deux paramètres obligatoires, pour le code langue et le mot traduit à lier...
Et pour les romanisations qui ne constituent le plus souvent pas une orthographe officielle pour la langue, car trop approximative ou admettant d'autres variantes possibles en fonction de la langue utilisatrice (français ou anglais: c'est souvent un système de romanisation différent), ou pour les éventuelles autres précisions phonétiques, on les mets hors de l'appel du modèle, à la suite de celui-ci, comme on met aussi les précisions pour le genre ou la nature grammaticale.
En revanche il sera bien plus utile de prévoir un paramètre optionnel (peut concerner toutes les langues) pour indiquer une ancre cible dans l'article lié en Interwiki (car l'ancre devrait pouvoir aussi être gérée par Bot et importée telle quelle d'un wiki à l'autre), surtout si le Wiktionnaire cible a décidé de ne pas traiter pas le mot traduit (ou une flexion de celui-ci) directement mais dans une page de liste ou sous une autre forme. verdy_p27 novembre 2008 à 08:36 (UTC)[répondre]
Je vais essayer de répondre sur quelques points, mais on a vraiment des points de vue très différents.
J'aimerais bien voir un exemple où mot en caractères traditionnels et simplifiés n'ont pas la même prononciation. Je ne vois pas comment cela est possible, puisque la simplification des caractères n'est que l'équivalent d'une gigantesque réforme orthographique. Cela n'a pas changé le sens des mots. On pourrait presque faire des soft redirects, en parlant de l'étymologie graphique, du nombre de traits, du classement du caractère, puis en liant vers le caractère traditionnel pour le sens, ou l'inverse.
Pour l'instant, tout ce qui est sous le code zh est en mandarin. Les autres langues chinoises n'ont quasiment aucune présence sur le wiktionnaire. Leur traitement est difficile, ce sont surtout des langues orales, il n'y a pas de romanisation clairement définie, etc. En gros, il faut attendre d'avoir des gens mieux informés. Je veux bien faire une migration de zh vers cmn, mais il faudra peut-être alors dire que c'est du chinois mandarin, plutôt que du mandarin, sinon les gens vont avoir plus de mal à trouver. En gros sur ça on est d'accord, utiliser le pinyin alors qu'on a un code zh, c'est très douteux.
Avoir un modèle compliqué permet de se simplifier la vie plus tard. Je ne parle même pas forcément en terme d'édition, mais par exemple en terme de personnalisation, en terme d'extraction de données. De mon point de vue, il faut que le wiktionnaire devienne plus facilement manipulable automatiquement que maintenant. Pour un mot en mandarin, l'écriture simplifiée, l'écriture traditionnelle et la romanisation ne sont que trois façons différentes de représenter la même entité. Elles devraient donc être liées, pour ensuite faire les combinaisons qu'on veut. Oui, cela fait des modèles compliqués, mais c'est plus simple qu'écrire un bot qui prend en compte toutes les combinaisons tordues. Là je suis en train de reprendre à la main toutes les traductions en chinois pour les standardiser. Même si on ne garde pas mon modèle, je pourrai facilement me conformer au nouveau style. Avant il y avait des caractères simplifiés sans les traditionnels, des caractères traditionnels sans les simplifiés, même des mélanges des deux parfois, des pinyins, parfois dans un autre modèle trad, des romanisations étranges.
Imaginons que le wiktionnaire devienne un outil de grande qualité. Il faut que des gens puissent copier la base de données et en extraire des dictionnaires spécialisées. Avec des modèles trad comme j'ai fait, il est facile de supprimer les caractères traditionnels, de mettre en valeur la romanisation correspondante, de choisir ce qu'on privilégie. Même pour nous, si un jour on décide de ne plus afficher les romanisations, ou seulement en petit, ou de créer une catégorie pour les traductions n'ayant pas de romanisation, on peut faire tout cela automatiquement.
Ta solution casse donc le lien traditionnel-simplifié, mais ce n'est pas grave. Je ne vois pas comment tu compte faire la différence entre simplifié et traditionnel. C'est à l'utilisateur de rentrer 中国, 中國 ? Ou alors on crée des codes langue cmn-hans, cmn-hant, yue-hans, yue-hant, etc. ?
Je fait deux sections pour séparer les éventuelles réactions.
J'ai d'autres critiques du modèle trad. Le comportement par défaut d'afficher le titre de la page à la place du mot de traduction si l'argument n'est pas présent me paraît nuisible:
Cela ne fait que gagner quelques frappes de clavier à quelques initiés, voire un copier-coller.
Cela induit tous les autres en erreur.
Cela complique le travail des bots.
Cela complique le code du modèle.
Je ne l'ai jamais réellement vu utilisé.
Le paramètre dif me semble douteux lui aussi, donnant un affichage différent du mot lié. Dans quelles langues cela sert ?
Je viens de regarder le dump, ça a l'air de servir pas mal (environ 1200 traductions ont plus de deux arguments, sans compter celles en chinois). par contre, certains des emplois ne me semblent pas adaptés.
Je n'aime pas trop non plus toutes les complications sur le code de langue ou l'étoile. Il y a des gens qui se servent réellement de cela ?
Par contre, je rêve d'un argument précisant à quel sens la traduction se rapporte, mais je ne sais pas réellement comment mettre cela en place. Un simple numéro est trop facile à casser, peut-être un mot clé que le créateur de la définition devra mettre quelque part ? Cela permettrait de changer ensuite automatiquement pour créer divers tableaux lorsque le nombre de traductions et de sens différents est trop grand. L'autre possibilité est de créer les tableaux dès maintenant même si on les crée quasiment vide, car plus on le fait tard plus c'est difficile.
Koxinga10 novembre 2008 à 23:01 (UTC)[répondre]
Le comportement par défaut n'a que des inconvénients, c'est vrai.
dif, qu'est-ce que c'est ?
dif est un argument permettant d'afficher un texte différent de celui de la page lié. Cela donne un lien du style [[cible#Langue|dif]]. Ce comportement existait (avec un troisième argument nom nommé) mais n'était pas documenté donc je me suis dit que son usage devait être très très peu répandu. Je l'ai appelé dif mais j'ai peut-être été un peu cavalier là-dessus, j'ai peut-être cassé quelques liens. Il avait été supprimé par Utilisateur:Urhixidur le 16 décembre 2007 et remis par Utilisateur:Verdy p le 18 janvier 2008, il peut peut-être nous expliquer mieux à quoi il sert.Koxinga11 novembre 2008 à 10:06 (UTC)[répondre]
J'ai un peu regardé les endroits où ce troisième argument était utilisé. Beaucoup de mots en hébreu ancien ou arabe, je ne sais pas s'il y a une subtilité à prendre en compte. Quelques mots s'en servant pour lier sur le mot de base, je ne pense pas que cela soit justifié (donner un pluriel en traduction mais lier au mot au singulier). D'autres lorsque la traduction est une expression : par exemple à impropre, on a {{trad|en|suitable|dif=not suitable (for)}} (je viens d'ajouter le dif pour éviter de garder le contre-sens. Est-ce que c'est une bonne solution ? Koxinga11 novembre 2008 à 10:55 (UTC)[répondre]
Surtout pas d'argument pour le sens, trad s'applique à un sens, pas à un mot. Mais on pourrait peut-être s'inspirer du Wiktionary pour la gestion des sens (mais sans cacher les traductions) ? Lmaltier11 novembre 2008 à 08:57 (UTC)[répondre]
Bon, pas d'argument de modèle, même si je ne comprend pas trop ta phrase (cela ne change rien au fait que trad s'applique à un sens, cela précise juste quel sens). Il y a quand même une réflexion importante à faire sur les traductions, je vois de plus en plus de problèmes qui apparaissent ... Les tableaux par sens du wiktionary sont pas mal, mais je n'aime pas trop la petite phrase pour rappeler la définition. Ceci dit, je n'ai pas grand chose de mieux à proposer. Mes idées sont trop loin de la structure du wiktionnaire et de Mediawiki Koxinga11 novembre 2008 à 10:06 (UTC)[répondre]
Ce que je voulais dire, c'est que
il ne faut pas utiliser de numéros pour repérer les sens, c'est le meilleur moyen d'aboutir à des incohérences (rajout d'une définition pour un nouveau sens au milieu des autres, par exemple); il vaut mieux une petite phrase
Je note que tous les liens rouges viennent de disparaître au profit de mots en noirs (qui ne sont soulignés que quand on passe la souris dessus).
Du coup il est difficile d'identifier les liens morts, les articles manquants dans la page, s'il faut survoler chaque mot avec la souris pour voir où sont ces liens morts.
Je viens de raffraîchir deux fois mon navigateur et je n'ai pas la berlue. A mon avis c'est un effet indésirable d'une modification de la page CSS avec un effet global non attendu.
Note: si le passage en noir et sans soulignement est destiné au rendu lors de l'impression, il faut faire cette modification dans une section CSS "@media print { ... }". verdy_p11 novembre 2008 à 21:02 (UTC)[répondre]
Note : cela ne concerne pas toute la page, mais ce changement survient dans les citations données en exemples sous les définitions, indentées avec ":" (notamment en fin de citation là où figure le nom de l'auteur, ou le titre de l'œuvre, ou une note explicative specifique à cette citation. verdy_p11 novembre 2008 à 21:06 (UTC)[répondre]
Voir la discussion Wiktionnaire:Wikidémie/avril_2007#Monobook. Pour résumer, il a été décidé alors de rendre les liens dans les exemples le plus discret possible (les raisons sont données dans la discussion). Les liens vers des articles existants sont en bleu faible, et les liens vers des articles inexistants sont de couleur noire comme le reste des exemples. Tu peux si tu le désires changer ce comportement dans ton propre monobook, en y réécrivant les paragraphes /* Pas de couleur pour les liens des exemples sans article */ (ou d'autres) du monobook global en le paramétrant à ta guise. Si tu as une proposition pour améliorer l'affichage global, ne te gêne pas. - Dakdada(discuter)12 novembre 2008 à 10:21 (UTC)[répondre]
Je prends un exemple : en espagnol, ll est considéré dans les tris comme une lettre (classée entre l et m). Il faudrait donc définir une convention pour ce genre de cas, pour chaque langue concernée. Actuellement, cette convention n'existe que pour l'espéranto (x rajouté dans la clé de tri pour certaines lettres). Pour le cas de ll en espagnol, on pourrait dire : ll est remplacé dans la clé de tri par lzzzz (ce n'est qu'un exemple). Mais je ne parle pas espagnol. Des volontaires pour faire une proposition et rédiger ça ?
Là où ça se corse, c'est quand il y a plusieurs langues dans la page. Par exemple paella : il faut que la clé de tri soit différente selon la langue, français ou espagnol. Des idées pour résoudre ce problème ? Lmaltier12 novembre 2008 à 09:39 (UTC)[répondre]
Après réflexion (et lecture des commentaires de Verdy_p sur le sujet), je pense qu'on devrait se contenter d'un ordre général, normalisé, en utilisant une clé de tri pour chaque article. Faire plus deviendrait trop compliqué (encombrement des articles, multiplication des clés de tri, clés de tri tarabiscotées). Tellement compliqué et contraignant qu'il serait plus simple d'avoir une fonction du logiciel MediaWiki (enfin un truc automatique) qui ferait le boulot à notre place (dans l'idéal : quelque chose comme un mot magique {{AUTOSORT:fr}} à mettre dans les catégories). Ah, s'il suffisait de demander... - Dakdada(discuter)12 novembre 2008 à 16:39 (UTC)[répondre]
Oui, et ça permettrait de supprimer complètement le modèle clé de tri. Peut-être qu'on pourrait leur demander, quand même (en demandant de traiter les espaces, tirets... de façon spéciale) ? Après tout, ils n'ont pas fait grand chose pour les wiktionnaires, jusqu'à présent. Lmaltier12 novembre 2008 à 16:52 (UTC)[répondre]
Comme je te l'ai dit, c'est insoluble actuellement, pour des raisons techniques. on ne peut pas trier en respectant simultanément plusieurs conventions, alors autant utiliser ici, dans le Wiktionnaire français, la convention de tri normale (qui est aussi la plus proche du français, avec seulement trois exceptions par rapport au tri UCA par défaut, c'est à dire DUCET).
Le modèle de tri permet de simuler le mieux possible le tri multiniveaux UCA avec 3 niveaux, ce qui suffit pour presque toutes les langues, le français y compris :
un premier niveau des lettres de base (tant pis si on ne reconnait pas les bigrammes ou trigrammes de l'espagnol, catalan ou breton, en revanche on sait éclater un caractère comme le ess-tsett allemand en deux ss dans la clé de tri précisée en paramètre)
le second niveau qui trie et différencie les majuscules après le minuscules (ça marche bien déjà, si on conserve la casse dans les clés de tri précisées en paramètre, et cela marche pour les clés de tri par défaut quand on ne met pas de paramètre à {{clé de tri}}). Ce niveau marche très bien actuellement, y compris pour les formes contextuelles spéciales du grec (sigma final qui n'existe qu'en minuscule) ou de l'arménien.
le troisième niveau qui trie et différencie les accents (et autres caractères ignorables comme les tirets ou apostrophes) qu'on a supprimé ou remplacé par des espaces dans le paramètre de la clé de tri. Ca marche pas trop mal, cependant le tri des différences reste binaire (dans l'ordre de codage UTF-8 des caractères différenciés), sachant aussi que la méthode actuelle sait déjà trier correctement toujours le caractère sans accents avant le même caractères avec accents et signes ignorables ou remplaçés par des espaces.
En revanche l'espéranto ne trie PAS les caractères avec accent circnoflexe comem s'ils étaient suivis d'un "x". C'est faux, c'est une convention d'écriture, mais pas celle recommandée. Le wikitionnaire espéranto, comme la wikipédia espéranto font automatiquement la conversion pour enregistrer unqiuement des lettres avec accents circonflexe, puisque c'est la graphie recommandée, qui est aussi utilisée pour le tri.
Et dans ce cas, le tri "façon UCA" utilisé par {{clé de tri}}} marche parfaitement pour l'espéranto, il n'est même pas nécessaire de transcrire avec un "x" après la lettre dans la clé de tri, mais on indique simplement la lettre de base sans accent circonflexe ni rien d'autre ! Le tri fonctionnera car la différence est bien reconnue au troisième niveau, le ĝ sera bien classé entre g et h sans le transcrire "gx" et tomber sur l'anomalie où "ĝ" sera alors classé après "g" mais avant "gy".
Note: si vous ne comprenez pas ce qu'est un tri multi-niveau, passez votre chemin : c'est pourtant celui qu'on utilise en français (même si vous n'en avez pas conscience) et dans presque toutes les langues... Allez vous documenter.
Wow, t'écris vite dis-donc . Bon, donc apparemment on est d'accord la dessus : on se contenterait de bien gérer la clé de tri, avec un ordre général pour chaque type d'alphabet : latin, cyrillique, grec, etc. (il faudrait préciser le etc.). Je rajouterais que pratiquement, pour un francophone, ça parait plus simple de garder l'ordre le plus proche de celui du français, par exemple pour retrouver paella. - Dakdada(discuter)12 novembre 2008 à 17:02 (UTC)[répondre]
Même si je suis conscient du problème technique, je ne peux pas être d'accord sur le fait que la situation actuelle aurait des avantages :
les catégories sont faites pour simuler une suite d'entrées, comme dans un dictionnaire. Il faut donc essayer de reprendre l'ordre des dictionnaires (même l'exception apparente du traitement des espaces, des tirets... va dans ce sens de se rapprocher de l'ordre de traitement des dictionnaires usuels)
même un francophone, s'il a un peu l'habitude des dictionnaires espagnols, est forcément dérouté par l'ordre actuel de la catégorie espagnol (car la catégorie espagnolest un dictionnaire espagnol !)
si les langues utilisant l'alphabet cyrillique n'utilisent pas toutes le même ordre, ne me dites quand même pas qu'il faudrait en privilégier une, et utiliser un ordre faux pour certaines autres !
J'ajouterais que se focaliser sur des détails de tri sur l'ordre minuscule/majuscule, avec ou sans accent, qui n'ont pas vraiment d'importance pour les lecteurs, en pratique (puisque les mots concernés seront de toutes façons regroupés dans la catégorie), tout en s'accommodant parfaitement d'un problème aussi important qu'utiliser un ordre alphabétique incorrect pour la langue (au premier niveau !), ce qui peut empêcher de trouver ce qu'on veut, c'est paradoxal... Lmaltier13 novembre 2008 à 21:36 (UTC)[répondre]
Je soutiens l'initiative d'une cle de tri differente par langue. Je travaille pas mal sur les mots tcheques et c'est peu naturel pour moi de chercher les mots en CH a la lettre C alors qu'elles devraient venir apres la lettre H, de meme que les lettres Č Ř Š Ž qui devraient se retrouver apres C R S Z et pas au sein du classement.--Diligent26 novembre 2008 à 17:01 (UTC)[répondre]
En typographie, si l'on ne dispose pas des lettres accentuées de l'espéranto, il faut utiliser des substitutions. Il n'est pas acceptable d'omettre complètement les accents sans distinguer des lettres normalement différentes. Il est impossible de saisir les lettres accentuées de l'espéranto sur les machines à écrire et sur certains systèmes informatiques. Afin de résoudre ce problème, le système de remplacement le plus couramment utilisé est le système X.
Il consiste à faire suivre la lettre majuscule ou minuscule correspondante d'un x minuscule. Cela n'entraîne pas d'ambigüité, la lettre x n'étant pas utilisée en espéranto. Rappelons toutefois que le système X est avant tout utile pour taper en espéranto sur une machine à écrire.
(Un autre système, qui fut originellement proposé par Ludwik Lejzer Zamenhof, consiste à faire suivre la lettre majuscule ou minuscule correspondante d'un h minuscule, sauf pour le ŭ qui est simplement remplacé par un u classique ; mais il est à déconseiller en raison des ambigüités qu'il peut entraîner. En effet, le système H butte sur des mots comme flughaveno, longhara, dishaki, ĉashundo, etc, ou le h est une lettre à part entière et non le substitut d'accent de la lettre qui le précède.) X3 mars 2010 à 09:01 (UTC)[répondre]
Proposition d'extension MediaWiki à faire : les variables globales de contexte[modifier le wikicode]
Je propose de poster une spécification d'extension pour MediaWiki de façon à supporter ces variables de contexte, et je vais l'écrire sur Méta. Comme je ne connais rien à la façon d'écrire une telle extension, même si j'ai lu un peu de code source PHP de certaines, j'attendrai que quelqu'un qui s'y connait mieux l'implémente.
En revanche je voudrais documenter les exemples d'emploi et l'intérêt que cela aurait, notamment pour les Wikitionnaires qui gagneraient énormément à avoir ces variables de contexte.
Par exemple on n'aurait plus à préciser partout un paramètre de langue dans les appels de modèle, si la valeur de ce paramètre pouvait être lue directement dans une variable de contexte (au lieu d'un paramètre explicite à passer chaque fois) dont la valeur a été positionnée par un moddèle comme {{=fr=}} qui définirait la variable de contexte suivante : {{#v:set:lang|fr}} utilisée ensuite avec {{#v:get:lang}} ou modifiée et utilisée sur place avec {{v:get:lang|fr}}
Un raccourci possible, en supposant que l'action "get" soit celle par défaut : {{#v::lang}} pour lire et {{#v::lang|fr}} pour modifier et utiliser immédiatement.
Toujours dans cette extension, que je nommerais GlobalContextVariables et utilisant la syntaxe générale {{#v:action:variable|paramètres optionnels}}, les variables pourraient être des listes ou tableaux indicés, et gérées chacune comme une pile (dont on n'utilise par défaut que la valeur au sommet, en position 0 du tableau indicé ou de la liste, et les actions push et pop seraient définies pour modifier ces variables en permettant de les faire se comporter comme des variables locales de contexte.
Concernant les noms de variables, ils seraient restreint à des identifiants valides commençant par une lettre et faits de lettres ou chiffres, les autres caractères (notamment de ponctuation) restant réservés pour gérer des espaces de noms par exemple (on utiliserait le point "." ou ":" comme séparateur d'espace), ou pour lire des variables de contexte internes au reste de la MediaWiki si celui-ci définit des espaces de noms spéciaux pour ses propres extensions. En revanche il n'y aurait pas de limitation dans la valeur des variables (tout ce qu'on écrit en syntaxe wiki, y compris les appels de sous-modèles qui seraient évalués normalement, serait possible).
Quel intérêt pour nous ?
Il est évident : on gagnerait à avoir une variable de contexte contenant la langue de la section courante (ici on utiliserait la valeur obtenue par {{#v::lang}} (l'action par défaut, non indiquée entre les deux ":", est "get" pour lire la variable de contexte nommée ici "lang".
Le choix du préfixe {{#v: }} (qui peut aussi être {{#var: }} ou même seulement {{#: }} !) reste à définir avec l'équipe de méta où cette proposition d'extension pour MediaWiki pourrait être proposée, je nomme cette extension à l'avance "GlobalContextVariables".
Cela allégerait énormément l'utilisation de nos modèles, en n'ayant plus à passer le paramètre de langue partout, et en permettant de définir en une seul fois, au début de la section de langue, la clé de tri qu'utilise cette langue pour les catégorisations faites ensuite par les sous-modèles utilisés dans la section de langue.
Comme les variables de contexte sont modifiables, on peut les utiliser pour stocker un résultat intermédiare de calcul (par exemple pour faire des sommes dans un tableau, le total étant calculé et affiché en bas de tableau. Utilise pour simplifier l'édition des tableaux complexes de données sur Wikipédia.
On pourrait définir une variable de contexte {{#v::clédetri}}, définie en début de section de langue avec ou juste après {{=fr=}} par exemple, et contenant la clé de tri propre à cette langue, et les sous-modèles dans la section n'ont alors qu'à utiliser la valeur de cette variable de contexte pour utiliser la bonne clé de tri pour les catégories par langue que ces modèles insèrent automatiquement.
En terme de ressources sur le serveur on gagne énormément sur certaines pages car on peut stocker dans une variable de contexte l'évaluation d'un appel de sous-modèle pour éviter d'avoir à l'inclure et l'étendre à chaque appel. Les pages contenant pleins d'appels répétés à un modèle paramétré complexe sont alors simplifiées et évaluées bien plus vite puique le serveur ne fait le travail d'expansion qu'une seule fois, à l'endroit où la variable de contexte est définie.
En terme technique, le bloc des variables de contexte n'est rien d'autre qu'un tableau normal en PHP, indexé par le nom de la variable. Ce tableau est transmis en référence implicite lors de l'évaluation de tous les sous-modèles, sans qu'il soit nécessaire de le passer en paramètre explicite. (il faut que cette évaluation soit garantie pour se faire de haut en bas et pas dans le désordre, je ne suis plus sûr que ce soit le cas actuellement car le moteur de templates a été largement modifié et remanié avec des caches internes, l'ordre d'expansion n'étant peut-être plus garanti comme se faisant dans l'ordre, du début de lapage vers la fin).
Cela fait plein de paramètres embêtants à répéter dans le Wiktionnaire qui deviennent inutiles, et on gagne en cohérence globale, et en possibilité d'automatisation et de vérification ou d'insertion automatique par des robots.
etc...
En principe on commence par une spécification avant d'écrire le code. Elle doit être suffisamment générale pour être extensible, mais pas trop compliquée à utiliser pour les cas simples comme le notre.
Qu'en pensez vous ? Il serait bon de discuter ensemble de ce qu'on veut en faire, et de ce que l'extension pour MediaWiki devrait gérer (en garder en tête le fait que des extensions sont possibles pour d'autres utilisations hors du Wiktionnaire, y compris sur Wikipédia, Commons, Wikispecies où je vois pleins de possibilités, ou des wikis hébergés hors de la Fondation Wikimedia.
Je propose de poster cette discussion aussi sur Meta (si vous voulez vous pouvez y faire un tour et faire référence à ce message qui est une première ébauche de proposition d'extension.
Je pense que ce serait utile, mais je doute fort de l'accueil : il y a une aversion constante, à juste titre, vers tout ce qui risque de réserver peu à peu l'édition sur Wikipedia (et autres projets) à une "élite" technique.
Mais ce serait peut-être mieux accepté si c'était limité à des variables standards connues du logiciel (par exemple une variable collation_order pouvant être mise dans les catégories pour choisir l'ordre de tri, comme dit dans la discussion précédente, en permettant de supprimer toutes les clés de tri). Lmaltier12 novembre 2008 à 18:42 (UTC)[répondre]
Tu noteras que justement, en évitant d'avoir à passer des tas de paramètres inutiles, cela rendrait globalement l'édition des articles bien plus facile. Les variables de contexte seraient en fait définies et utilisées en interne dans nos modèles existants ! Ca donne un code Wiki bien plus élégant, plus court, et plus facile à manipuler et plus compréhensible (y compris au travers des imports de données d'un wiki à l'autre).
Cela n'empêchera pas qu'il faut déjà être expert pour définir nos modèles actuels qui sont d'une complexité croissante justement parce qu'ils n'ont pas accès simplement au contexte de leur utilisation, autrement que par des paramètres explicites et des tas de tests... verdy_p12 novembre 2008 à 18:49 (UTC)[répondre]
D'autre part, ces variables de contexte peuvent simplifier énormément l'écriture des modèles complexes actuels, si on peut éviter d'avoir à référencer les valeurs de paramètres et les valeurs par défaut données, chaque fois avec une syntaxe très complexe qu'il faut répéter à chaque utilisation, alors qu'il suffirait de définir une variable de contexte au début du modèle, et utiliser la valeur stockée dans cette variable de contexte ensuite dans tout le reste du modèle ! Les modèles complexes où s'enchevètrent plein d'accolades imbriquées et de #if deviennent alors beaucoup plus faciles à écrire, lire, comprendre et maintenir (il n'est plus nécessaire de faire ces imbrications et de compter les acollades, sources de plein d'erreurs ! verdy_p12 novembre 2008 à 18:58 (UTC)[répondre]
Ces arguments peuvent être employés, on peut toujours essayer, mais je ne parlais pas du cas particulier du Wiktionnaire, mais en général. Lmaltier12 novembre 2008 à 19:03 (UTC)[répondre]
Justement je parle d'une façon générale: les modèles actuels dans tous les wikis sont d'une complexité croissante à cause justement de l'absence de telles variables qui les simplifierait énormément, y compris sur Wikipédia, Commons, WikiSpecies, WikiNews, WikiBooks... verdy_p12 novembre 2008 à 19:11 (UTC)[répondre]
Sûr (je n'ai lu que les premières et dernières lignes de ton message, je m'en excuse) mais les développeurs de WikiMedia sont contre l'installation de cette extension. Alors : fais-le !, mais ne te fais pas d'illusion. --Szyx12 novembre 2008 à 19:06 (UTC)[répondre]
Pour les variables purement locales à un modèle, une convention de nommage de ces variables de contexte (renforcée par l'extension elle-même) suffirait pour indiquer que ces variables ne sont pas passées en retour ni durant l'évaluation des sous-modèles utilisés, par exemple des variables locales dont le nom commence par "$" ou "_". Cela donnerait {{#v:set:_x|expression complexe}} au début du modèle pour définir la variable locale nommée ici "_x", puis ensuite de {{#v::_x}} pour utiliser ensuite la valeur déjà définie. verdy_p12 novembre 2008 à 18:58 (UTC)[répondre]
Et plus j'y pense et plus je suis persuadé que cette extension conduit à du code élégant et facile à maintenir et comprendre par plus de monde que les modèles actuels sur TOUS les projets Wikimedia ! verdy_p12 novembre 2008 à 19:13 (UTC)[répondre]
Je me permet de reprendre le cas du modèle {{ucf}} (et de {{lien}}, moins répandu). Ce modèle a été créé à l'origine afin d'éviter d'avoir à réécrire le mot en majuscule en début de définition dans un lien du type Mousse. Il a ensuite été amélioré de façon à permettre un lien vers une section de langue spécifique, en lui ajoutant un paramètre appelant les modèles de langues (par exemple {{subst:s-ucf|mousse|en}}, Mousse). Un autre modèle a alors été créé sur le même modèle, à cela près qu'il ne mettait simplement pas le lien en majuscule (juste un lien vers une section de langue).
L'utilité du modèle {{ucf}} a dès le départ été controversée, notamment parce qu'il ne faisait apparemment que gagner un peu de temps aux rédacteurs, et en même temps réduisait la lisibilité du code, et ajoutait encore un modèle.
De plus, des modifications récentes des sections de langue et de types de mots permettent désormais de faire des liens directs (vers une langue voire un type de mot) de type wiki sans avoir besoin d'un modèle. Par exemple : [[mousse#en|Mousse]] (Mousse en anglais) ou [[mousse#fr-adj|Mousse]] (Mousse, l'adjectif en français).
Il me semble que ces liens, utilisables partout sans aucun problème (étymologie, définitions, y-compris dans dans le modèle {{trad}} qui fait encore appel aux modèles de langue) sont plus clairs et plus simples à utiliser : les modèles {{ucf}} et {{lien}} me paraissent donc désormais inutiles (leur seul avantage est peut-être d'écrire la langue en toute lettre dans les liens plutôt que leur code).
Merci pour cette information. Je suis pour, bien sûr. Il faudra faire attention à l'utilisation actuelle de ces modèles sans aucun paramètre, heureusement rare mais qui existe parfois. Lmaltier12 novembre 2008 à 11:41 (UTC)[répondre]
Remplacer les usages de ces modèles par les liens directs, pourquoi pas. Supprimer les modèles eux-mêmes, je suis contre. On pourrait par contre fortement suggérer de les utiliser avec subst: ? --Szyx12 novembre 2008 à 11:42 (UTC)[répondre]
Bon, si vous voulez mon avis en tant que simple rédacteur pas très habile, c'est que ce truc : {{ucf}} était très pratique justement parce qu'il était situé juste en-dessous du cadre et qu'il n'y avait pas à le chercher dans les tréfonds de sa mémoire chaque fois qu'on en avait besoin (pour ceux qui ne participent pas tous les jours, et qui d'une fois à l'autre oublient). J'aimerais bien avoir la même chose pour les notes de bas de pages que je recherchais l'autre jour, jusqu'à ce que Szyx me rappelle que c'était dans {{-réf-}} (comme je suis très bête je recherchais en vain quelque chose qui se fût appelé "note de bas de page", et qui eût été plus directement accessible, c'est-à-dire en-dessous du cadre. N'y aurait-il pas moyen de faire une recherche statistique sur les machins (ou plutôt les trucs, on se comprend) les plus fréquemment utilisés, et d'ajouter ceux qui ne le sont pas déjà en-dessous du cadre (pour qu'ils soient d'une cliquabilité plus opérationnelle pour les fainéants ou les têtes de linottes comme votre serviteur… ? (tout à l'heure, pour l'article clé des champs, j'ai aussi cherché comment faire ce censuré de lien vers wikisource, et pas retrouvé (pourtant j'ai su !). Soyez gentils, mettez-nous ça à portée de clic (et pourquoi pas parmi les boutons au dessus du cadre, dont certains sont dévolus à des fonctions qui à mon avis doivent servir dans un article sur mille !--Zorglub12 novembre 2008 à 13:57 (UTC)[répondre]
Les boutons du dessus je les ai désactivés (pour dire combien je les utilise...). Pour le reste : la plupart des modèles utiles sont dans la partie « Wiki (Modèle) ». Puisque c'est la partie API qui est montrée en priorité, peut-être qu'il serait judicieux justement de mettre ce Wiki (Modèle) par défaut : on y trouve bon nombre de modèles fondamentaux, ainsi que les préfixes pour les liens interprojets genre wikisource. Faudra juste mettre tout ça à jour. En outre, rien ne nous empêche d'en rajouter qui permettrait, par exemple, de créer directement un lien majuscule (en trifouillant un peu). - Dakdada(discuter)12 novembre 2008 à 16:18 (UTC)[répondre]
Oui, {{ucf}} ne fonctionne pas bien avec subst: (je me demande même s'il n'y a pas un bug – je vais regarder).
Il faudrait alors modifier la ligne Modèles (avec insertion de contenu) : {{voir|}}·{{cf|}}·{{pron|}}·{{subst:s-ucf|}}·{{term|}}·{{subst:}}·{{subst:|}} sous la fenêtre d'édition.
Mes caractères API ! Ne me supprimez pas mes caractères API ! Plus sérieusement, s'ils ne sont plus prioritaires, il serait bien (nécessaire !) d'ajouter une ligne dans la partie fixe (sous Caractères spéciaux : ’ à À â  æ Æ € é É è È ê Ê ï Ï œ Œ ô Ô ù Ù û Û ç Ç ) avec l'API du français.
J'ai bidouillé une nouvelle version de ucf qui peut se substituer : Utilisateur:Darkdadaah/Modèle:ucf (à utiliser comme un modèle pour tester, par exemple {{subst:Utilisateur:Darkdadaah/Modèle:ucf|étrange}} donne le lien Étrange). Il suffira d'écrire quelque chose comme {{subst:ucf|strange|en}} pour créer un lien bien formaté comme il faut (on peut même remplacer en par en-nom etc.).
Je suis en train de roder mon bot. J'ai détecté différents cas, en particulier :
tous les ucf sans paramètres sont dans des sections de langues "étrangères" qui renvoient vers la section française du même article. Il y a deux manières de remplacer ce lien :
[[mot#fr|Mot]]
[[#fr|Mot]]
Un exemple de conversion par mon bot : [3]. Les deux sont équivalents : que devrait-on choisir ? Le premier cas est le plus explicite, mais il peut devenir dur à lire si le mot est long (par exemple [[#fr|Interminable]] contre [[interminable#fr|Interminable]]). - Dakdada(discuter)14 novembre 2008 à 10:35 (UTC)[répondre]
Je préfère très nettement, sans hésitation, la première solution. C'est ce qui sera le plus facile à comprendre, en tout cas pour beaucoup de ceux qui ont un peu l'habitude de Wikipédia. Pour ceux qui n'ont pas du tout l'habitude, ce n'est pas très clair de toutes façons, mais la première solution peut permettre de deviner le sens de la notation bien plus facilement. Lmaltier14 novembre 2008 à 12:30 (UTC)[répondre]
Pour la première, elle est plus traditionnelle et donc plus facile à se rappeler
Je me souviens avoir vu quelque part dans une discussion que {{ucf}} était préconisé pour le début d'une définition. À la suite de ça tout le monde avait suivi la consigne (attention à trop de changements qui peuvent démotiver les contributeurs, à force) -Béotien lambda14 novembre 2008 à 12:37 (UTC)[répondre]
Il faudrait aussi changer les modèles {{trad}} pour qu'ils utilisent les liens directs (avec ancres du type #en) plutôt que les modèles du type {{en}}. Mais pour ça il faudrait que tous les modèles de sections de langues aient cette ancre : je ne l'ai changé (à la main) que pour quelques uns. Une fois fait, il y aura moins d'appels inutiles à ces modèles. - Dakdada(discuter)19 novembre 2008 à 17:44 (UTC)[répondre]
Je viens de créer les modèles {{s-ucf}}, {{s-lien}} substituables qui donnent les liens précis correspondants lorsqu'on les substitue. Attention : leur usage ne doit être que substitué. Il "suffit" par exemple d'écrire {{subst:s-ucf|sudoku|en}} pour obtenir Sudoku. Bien sûr ça peut paraitre lourd, mais je vais l'ajouter aux modèles insérables sous le cadre de modifications, ce qui permettra de l'insérer aisément.
Par ailleurs, je vais lancer mon bot pour remplacer toutes les occurrences actuelles de {{ucf}} et {{lien}} (ainsi que {{Lien}}). Vous pouvez voir un aperçu des transformations que ça donnera ici : diff test. Le résumé du travail du bot est consultable ici : Historique de Daahbot.
Notez qu'il sera encore possible (et ce serait d'ailleurs un usage assez simple) d'utiliser encore {{ucf}} et {{lien}}. Il suffira juste de passer le bot de substitution régulièrement. Si ça peut simplifier le travail d'édition... - Dakdada(discuter)19 décembre 2008 à 09:35 (UTC)[répondre]
Pour le « notez » : oui ce serait bien, c'est quand même plus pratique, particulièrement pour les mots longs et les locutions, et comme on ne tape le mot qu'une fois cela diminue les risques d'erreur. --Szyx19 décembre 2008 à 10:18 (UTC)[répondre]
Il faut aussi mettre à jour les pages d'aide et autres conventions. Peut-être pas pour dire qu'ils sont déconseillés mais il faut parler de s-ucf sur la page de ucf par exemple, et expliquer qu'un bot changera toutes les occurences. Koxinga19 décembre 2008 à 10:38 (UTC)[répondre]
ne voyant nulle part où contacter le staff Wiktionary, je poste un message ici. Je dois écrire un travail sur les Wikis pour mon université, et je souhaiterais poser quelques questions en privé.
Mon compte : Carluf .
Quelqu'un pourrait-il prendre contact avec moi SVP ?
Il n'y a pas de staff Wiktionary. Il y a simplement des gens qui contribuent, on ne sait pas trop combien. Pourquoi poser des questions en privé ? Visiblement, le mieux serait déjà de prendre le temps de regarder un peu comment ça se passe, puis de poser des questions ensuite. Il est bien sûr possible de communiquer en privé, mais il faudrait comprendre pourquoi (ce n'est pas l'esprit des wikis, en général). Lmaltier12 novembre 2008 à 15:43 (UTC)[répondre]
(Ce titre est une allusion humoristique à une certaine publicité que nous vîmes en France il y a quelques mois, mais ladite publicité n'a rien à voir avec le sujet, c'est juste pour le .)
En consultant à l'instant les modifications récentes, je remarque deux nouveaux bots.
Salebot (d · c · b), bien connu sur Wikipédia, est apparemment actif ici depuis le 8 novembre. Il chasse les vandalismes, et le fait sans le bot flag, « ce qui permet à ses modifications d'être visibles dans la liste des modifications récentes. » (voir w:Aide:Salebot). Je l’ajoute sur Wiktionnaire:Bot/Liste, aux côtés de Correcteur de redirection (d · c · b) (bien que techniquement ils ne soient pas de même nature).
Muro Bot (d · c · b) a fait son apparition aujourd'hui, sans s'être présenté semble-t-il. Pour l'instant, il n'a fait que deux interwikis, pas de quoi fouetter un chat, mais pour le principe je vais contacter son « dresseur », Muro de Aguas (d · c · b) (compte créé aujourd'hui [4], voir w:es:Usuario:Muro de Aguas). Mais de toute évidence c'est un bot connu (voir w:Utilisateur:Muro Bot).
Salut, prv (provençal) est devenu oci (occitan) depuis 2007. Il est peut-être mieux de le changer, il est utilisée bien souvent donc ce n'est pas quelque chose à faire à la main. — message non signé de Polyglot (d · c) du 13 novembre 2008 à 22:53
Oui, l'OSI a distingué les différentes langues occitanes en leur attribuant un code à chacune (provençal, limousin, auvergnat...) et semble maintenant revenir en arrière. Il n'empêche que certains mots définis comme provençaux (ou autres variantes de l'occitan) sont peut-être particuliers à cette variante. Changer tous ces codes sans précaution risque donc de faire perdre de l'information. Il faudrait voir comment faire. A noter aussi : il existe un code de 2 lettres (oc) pour l'occitan, c'est donc celui qu'on utilise. Lmaltier14 novembre 2008 à 07:40 (UTC)[répondre]
Je me suis brûlé les doigts quand j'ai transporté la traduction d'un mot provençal du fr.wikt vers en.wikt. prv n'était pas définie, donc j'avais commencé de la créer. Puis je me suis rendu compte de ce que je vous ai signalé par-dessus. Polyglot14 novembre 2008 à 17:33 (UTC)[répondre]
En bidouillant le modèle {{trad}} et en codant mon bot, je me suis pas mal intéressé aux parties traduction des articles. Il y a quelques points où j'aimerais avoir l'avis de la communauté afin qu'on puisse écrire cela dans les conventions et que je fasse tourner mon bot dans ce sens. C'est sûrement trop de sujets d'un coup et certains ne vont pas être traités, mais tant pis, je les remettrai sur le tapis plus tard !
Comment est-ce qu'on traite les traductions vers des langues n'ayant pas de wiktionnaire ? Garder {{trad-}} n'est pas souhaitable car le lien vers le wiktionnaire étranger propose parfois de créer une nouvelle page dans le wiktionnaire français (par exemple test(*)).
Le consensus actuel semble être de faire un simple lien interwiki. L'idéal dans ce cas est d'avoir une catégorie en bas de la page pour indiquer la traduction. Cela permet de savoir à quel point une langue est représentée, et si le wiki est créé un jour, de voir quelles sont les pages à changer. Par contre, je ne suis pas convaincu qu'un bot peut tout changer automatiquement. Je n'ai pas trop envie de voir des multiplications de cas comme celui-là.
On peut utiliser un modèle {{trad--}}. Il y avait déjà eu un débat là dessus (ici). C'est la solution que je préfère si on ne touche rien au reste. Franchement ce modèle ne coûte pas cher.
On peut modifier {{trad}} pour voir par rapport à une grande liste de langue lesquelles ont un wiktionnaire à elle et afficher le lien en fonction du résultat. Je propose cela pour être complet mais je n'y crois pas trop.
On peut garder {{trad-}}, et tant pis pour les quelques faux liens.
qu'on laisse les contributeurs utiliser des liens simples, même si ces liens sont transformés ensuite. On doit même inciter fortement à faire comme ça. Ce n'est pas à eux de faite un travail bête.
que les modèles trad soient les plus simples possibles. Je pense réaliste de penser qu'on aura un jour des pages avec 10 000 ou 20 000 appels de ce modèle, surtout pour les mots de base qui peuvent avoir de nombreux sens, du genre faire ou donner. Lmaltier15 novembre 2008 à 14:55 (UTC)[répondre]
J'ai un peu peur des liens simples, car cela empêche de faire des sections de traduction avec des entrées complexes, avec des précisions grammaticales un peu complexe, où on a envie de lier les mots (comme enclitique dans l'exemple que je donne ci dessus). Si un bot passe en change tous les mots wikifiés en modèle trad, il faut le préciser quelque part. Dire qu'un mot est une traduction ajoute une information par rapport à un lien.
Si on a 10 000 appels à un modèle trad, j'espère qu'on aura fait des pages séparées. Sinon la taille de la page aura explosé avant qu'on atteigne les limites du nombre de modèle. Koxinga15 novembre 2008 à 15:18 (UTC)[répondre]
A ce sujet, les modèles de langue savent maintenant indiquer le code interwiki associé à un code langue: il est vide s'il n'y a pas de Wiktionnaire associé. L'info est disponible dans les modèles de langue. Par exemple “{{fr|type=interwiki}}” retourne “français”, mais “{{map-bms|type=interwiki}}” retourne “banyumasan”. La liste des codes langue supportés est pour l'instant dans le modèle {{lang/interwiki}}, mais je vais plutôt distribuer les codes wikis à retourner dans chacun des modèles de langue qui ont un code interwiki associé, pour supprimer la liste du code de {{lang/interwiki}} afin d'alléger le modèle (ce modèle retourne déjà la valeur indiquée dans le switch par type du modèle code langue "xxx/type" indiqué quand il est précisé, mais au lieu ensuite de déterminer une valeur par défaut par la liste qu'il contient quand xxx/type ne retourne pas de valeur dans son switch, le modèle Modèle:lang/interwiki retournera la chaine vide (cela nécessite l'édition préalable de seulement une vingtaine de modèles de langue "xxx/type").
J'ai toutefois écrit ce modèle par avance afin de documenter la valeur retournée. Les mêmes modèles peuvent aussi indiquer des codes interwikis pour d'autres projets que le Wiktionnaire, avec la même technique (par exemple pour retourner un code interwiki vers Wikipédia, quand il existe).
Avec ça, le modèle trad pourra distinguer les codes langues dont le lien généré pointe nulle part, sans avoir à le spécialiser pour certaines langues.
Cela fait que la spécialisation faite par {{trad--}} est déjà obsolète: on pourra mettre directement {{trad}} ou {{trad-}} avec le même effet (et il ne sera pas nécessaire de changer trad en trad- pour supprimer le lien si le wiktionnaire cible n'existe pas). verdy_p27 novembre 2008 à 09:01 (UTC)[répondre]
Comment fait-on pour les cas où les traductions ne se résument pas à un simple mot?
Peut-on wikifier des mots ?
Y-a-t-il une limite de taille à la traduction ? Comment faire si on a beaucoup de choses à dire ?
Lorsqu'un mot se traduit par une expression, est-ce qu'on lie l'expression ? des mots importants de l'expression ? Est-ce qu'on met l'expression comme lien mais en fait on lie vers un mot ? Par exemple, si on veut traduire impropre, on peut faire :
Si la traduction mérite une entrée, c'est comme les traductions en un seul mot. Mais ici, la seule solution acceptable me parait la deuxième. Mais un simple lien pour suitable me semble bien. Lmaltier15 novembre 2008 à 14:16 (UTC)[répondre]
Oui, mais si on met un lien simple, ce qui me semble aussi une bonne solution, on ne peut pas utiliser de bots pour transformer un lien simple en modèle {{trad}}. C'est un peu en contradiction avec ce que tu as écrit au-dessus, il faut dans ce cas demander aux utilisateurs de rentrer directement un modèle trad lorsqu'ils ajoutent une traduction méritant une entrée. Koxinga15 novembre 2008 à 22:05 (UTC)[répondre]
Je vais voir ce que je peux faire avec mon bot, par exemple ne pas utiliser le modèle trad si le mot est à côté d'autres mots, mais l'utiliser si il est entouré de virgules, points virgules, etc. Koxinga16 novembre 2008 à 10:12 (UTC)[répondre]
Êtes-vous d'accord qu'il faut systématiquement séparer les traductions en tableaux selon le sens ? Y compris lorsqu'on n'a pas encore de traduction pour un sens. Plus on le fait tard et plus il y aura de traductions à vérifier. Le wiktionary propose des tableaux avec un résumé du sens en en-tête. Ici on met juste les titres en gras (voir maison et en:house). Notamment le wiktionary propose aussi les sens qui n'ont pas encore de traductions. Cela me paraît important pour donner envie au contributeur occasionnel de participer sans se prendre la tête.
Indépendamment de la mise en page, est-ce qu'on en fait un argument du modèle de début de tableau, comme sur le wiktionary ?
Je suis d'accord. Mais je ne vois pas l'intérêt d'avoir systématiquement un tableau, même pour une seule traduction, sauf si on adopte un modèle avec le sens comme argument, comme le Wiktionary, ce qui me paraît bien. Lmaltier15 novembre 2008 à 14:19 (UTC)[répondre]
En effet, je vois bien un modèle avec le sens en argument. Un tableau pour une seule traduction (ou pas encore de traduction), c'est pour faciliter les contributions ultérieures. Si le cadre est déjà fait, c'est plus simple d'ajouter du contenu ensuite. Koxinga15 novembre 2008 à 21:53 (UTC)[répondre]
Peut-on mettre la possibilité de n'éditer que la section traduction ? En fait pourquoi a-t-on enlevé la possibilité d'éditer les sections ? je trouve que cela rend l'édition très difficile et intimidante sur les grandes pages.
La modification directe des sections est désactivée parce que les sections sont générées par des modèles : en cliquant sur le lien [ modifier ], on modifie le modèle mais pas la section de l'article... La dernière discussion à ce sujet date de novembre 2007 ou j'avais proposé des changements. Et maintenant que j'y pense, ce serait possible de ne faire le changement que pour la section de langue (en utilisant le css), qui est un des seuls points qui ait bloqué. Si on s'y met et que les avis sont unanimes, alors on pourra restaurer l'édition par section, au moins par langues. - Dakdada(discuter)15 novembre 2008 à 15:35 (UTC)[répondre]
Merci pour ce cours d'histoire wiktionarienne, je ne suis pas revenu depuis longtemps donc je risque de reposer des questions ayant déjà été débattues en long en large et en travers. Si tu as une solution technique, je suis pour qu'on essaie un peu de voir ce que ça donne, cela me semble un point important. Koxinga15 novembre 2008 à 22:07 (UTC)[répondre]
« Si on s'y met et que les avis sont unanimes, alors on pourra restaurer l'édition par section, au moins par langues. » Pour --Szyx15 novembre 2008 à 22:18 (UTC)[répondre]
Nous ne sommes pas très nombreux ici, mais en plus nos pages de vote sont particulièrement bien planquées. Peut-être pour cela, il y a peu de votants sur ces pages, ce qui est dommage pour notre crédibilité. J'ai tenté de lister les pages concernées.
Je pense qu'il y a peu de votants simplement car nous sommes peu nombreux. Cela étant dit : un lien direct plus explicite depuis la page d'accueil est le bienvenu plutôt que "Accueil communauté : organisation, règles et outils" (lien vers Wiktionnaire:Accueil communautaire). Pour alléger la page des annonces, on pourrait supprimer (une fois le vote clos) les lignes "… pose sa candidature au poste de …". Pour être alerté rapidement il faudrait que les contributeurs intéressés ajoutent les liens de suivi des pages de vote précitées (ainsi que Wiktionnaire:Annonces) sur cette page. Stéphane8888discuter18 novembre 2008 à 13:08 (UTC)[répondre]
Wiktionnaire est là quand vous en avez besoin — aujourd’hui, elle a besoin de vous.[modifier le wikicode]
Il y aurait moyen de changer en « Wiktionnaire est là quand vous en avez besoin — aujourd’hui, il a besoin de vous. » ? --Szyx15 novembre 2008 à 22:32 (UTC) vous avez vu que j'ai fait le modèle {{small}} ?[répondre]
Apparemment on ne peut pas le modifier ici (même pour un bureaucrate), faudrait voir à un plus haut niveau... - Dakdada(discuter)16 novembre 2008 à 20:14 (UTC) C'est pas aussi simple d'écrire les balises <small></small> ?[répondre]
Je suggèrerais, si la formule est utilisée par tous les projets francophones, de remplacer 'aujourd’hui, elle a besoin de vous par et a aujourd’hui besoin de vous. Mais il faut encore trouver où changer. Lmaltier18 novembre 2008 à 10:08 (UTC)[répondre]
Non, cela vient du projet de traduction sur Meta. Il fallait être là pour corriger les traductions avant qu'elles soient diffusées par le MediawikiBot dans les ressources de l'espace "mediawiki:". On retrouve la trace de ces demandes de traduction sur Meta bien avant que la campagne de collecte commence. Cela peut se changer ici, et un admin peut le faire dans l'espace mediawiki où ces textes sont stockés. verdy_p13 décembre 2008 à 09:24 (UTC)[répondre]
Ou du moins son algorithme n'est pas adapté au Wiktionnaire. J'ai réverté presque toutes ses interventions d'aujourd'hui. Si j'avais les droits d'administrateur, je l'aurais bloqué. --Szyx16 novembre 2008 à 00:30 (UTC)[répondre]
Je l'ai bloqué. Je vais prévenir Gribeco. D'après ce que j'ai vu, le problème vient d'article nouvellement créés, sans modèle ni mise en forme "normale", qui sont blanchi alors que l'usage ici est de les garder (exemple : diff). Markadet∇∆∇∆16 novembre 2008 à 08:59 (UTC)[répondre]
C'est quand même ennuyeux qu'il révoque ceci, qui ne ressemble même pas à un vadalisme. En plus il met ce message aux pauvres IP dont le seul tort est d'avoir été maladroit, ce n'est pas ainsi qu'on va les encourager à contribuer . --Szyx16 novembre 2008 à 18:04 (UTC)[répondre]
Hum, en effet, le réglage "complet" sur le Wiktionnaire sera bigrement difficile, voire impossible à cause de la syntaxe des nombreux modèles. Mieux vaut se focaliser sur les seuls vandalismes du genre : « pipi, caca, boudin et autres gros mots », et aussi les longues répétitions de lettres... Stéphane8888discuter16 novembre 2008 à 21:47 (UTC)[répondre]
J'avais mal compris. Je m'en suis aperçu en essayant de traiter le problème. Il n'y a pas violation de copyright, mais il faudrait quand même en discuter : est-ce qu'on peut faire ça à grande échelle ? Lmaltier16 novembre 2008 à 16:59 (UTC)[répondre]
Merci à tous les deux. On ne copie pas le fichier audio mais on fait plus que faire référence au site, on fait référence au contenu du site, à sa substance (qui est la base de son existence, en partie) qu'on utilise à nos fins. Avez-vous des idées sur la jurisprudence dans ces cas, des cas sur Wikipédia ou autres ? -Béotien lambda16 novembre 2008 à 17:18 (UTC)[répondre]
Je ne sais pas, mais j'imagine qu'il n'y a pas de problème juridique, pour un cas isolé comme ça. A grande échelle, je ne sais pas. En dehors de l'aspect juridique, on peut considérer qu'il y a un problème vis à vis du Wiktionnaire : pour entendre la prononciation, on doit quitter notre site. C'est ce qui me gêne le plus. Lmaltier16 novembre 2008 à 17:27 (UTC)[répondre]
J'ai trouvé quelque chose qui dit : « Vous pouvez faire référence au contenu des sites Web uniquement sous forme de courtes citations et en citant distinctement votre source. » dans [5] mais je ne sais pas si ça a une portée générale sur le Web, auquel cas on pourrait considérer une prononciation prise « au détail » comme une courte citation. -Peut-être - Béotien lambda16 novembre 2008 à 17:31 (UTC)[répondre]
« Prononciation chez howjsay.com » est un lien externe comme il y en a des centaines de milliers sur Wikipédia, je ne vois aucun problème juridique là-dedans. En particulier, il n'y a aucune copie de contenu. Et la mention de la marque respecte les règles habituelles : ne pas porter préjudice, lien vers le site de la marque. Par contre, le rouge est-il vraiment nécessaire ?
Néanmoins, il faudrait essayer de remplacer ce genre de lien par nos propres fichiers sonores, pour garder notre autonomie. --Szyx16 novembre 2008 à 18:16 (UTC)[répondre]
C'est aussi mon ressenti sur les différents aspects de ton intervention. Et pas de problème juridique puisque c'est bien howjsay.com qui délivre l'information. Mais c'est à éviter à grande échelle car ça s'apparenterait à de la publicité pour ce site... Stéphane8888discuter16 novembre 2008 à 18:43 (UTC)[répondre]
J'aimerais modifier certains modèles pour faire prendre en charge leur style par des feuilles de style CSS. En particulier :
{{pron}}, {{phon}} : pas exactement un style, mais la liste des familles de polices serait mieux placée dans la classe API, plutôt que dans un modèle ({{Polices API}}).
{{fr-accord-mf}}, {{fr-accord-mixte}} : ces deux tables sont à la base de tous les tableaux d'accord en français. Je propose de faire les changements que j'ai faits pour{{it-accord-mf}} (voir ici), à savoir réunir tous les paramètres de style dans une classe flextable. En outre, il faudrait enlever les balises qui contiennent la classe .pron-API-SAMPA qui est déjà incluse dans le modèle de {{pron}}.
De manière identique, tous les tableaux d'accord des autres langues copiés sur le modèle des tableau du français pourraient bénéficier de ces changements.
L'intérêt de tout mettre dans ces classes est de permettre l'harmonisation des styles (sans utiliser de modèles, du genre {{Polices API}}), ainsi que la personnalisation de l'affichage de tous ces éléments (par exemple les cacher, mettre des couleurs plus vives, etc.). En plus ça simplifie un peu l'édition des modèles (pour un exemple voir cette page de test).
Il est probable que d'autres modèles pourraient bénéficier de ce genre de chose.
Pour information, j'ai modifié l'affichage des listes des modèles et catégories cachées placés sous les fenêtres d'édition, sous les caractères spéciaux. J'ai fait en sorte que ces listes souvent très longues soient écrites en petit, et, pour ceux qui sont sous firefox (ou proche), l'affichage est réalisé sur plusieurs colonnes (3 pour les modèles, 2 pour les catégories). Dites-moi ce que vous en dites, si vous trouvez ça mieux ou pas. - Dakdada(discuter)19 novembre 2008 à 17:42 (UTC)[répondre]
Autre « compte-rendu » : j'ai appliqué le style flextable aux modèles {{fr-accord-mf}} et {{fr-accord-mixte}}, de même qu'à bon nombre de modèles semblables dans les autres langues. Les modèles {{pron}} et {{phon}} ont désormais leur style de polices dans la page Mediawiki:Common.css.
Correction : Je n'ai appliqué le style au modèle {{fr-accord-mf}} que hier, car il a fallu que je refonde le modèle, celui-ci étant devenu exagérément trop complexe (notamment en recréant le modèle dans {{fr-inv}}). J'ai effectué quelques corrections, comme le découpage des cases correct avec un second singulier et/ou pluriel, et la mise en entête de la mention mf (qui complexifie inutilement la structure quand on la positionne à gauche). - Dakdada(discuter)11 décembre 2008 à 08:24 (UTC)[répondre]
Bonjour, pour pouvoir avoir rapidement une liste des nom se terminant en -f avec un pluriel en -ves, je pense que ce modèle est intéressant. A garder ?
il sagit dun CD de play station2 sur pc,je lai installé,mai g sais po comment faire mnt pr jouer,jai utilisé le jeu:TOMB RAIDER sur play station2 mai il ne veu pa le lire!!!!et sest ecri:pour play station,comment faire?
J'ai eu une idée sur les boîtes déroulantes. On pourrait les laisser visible pour celles qui ont peu de contenu et les faire passer automatiquement en boîte déroulante quand il y a beaucoup de lignes. J'ai donc codé cela en javascript. Si quelqu'un veut l'essayer, il suffit de copier Utilisateur:Koxinga/monobook.js (ou de lier vers, je ne sais pas trop comment ça marche), et d'aller voir des pages avec des boîtes déroulantes (Utilisateur:Koxinga/tests si vous n'avez pas d'idée). Pour les feignants, j'ai même un screenshot.
Normalement, les boîtes de plus de 8 lignes vont être en boîtes déroulantes normales, celle de 8 lignes ou moins vont s'afficher simplement. Cela me semble une solution élégante aux multiplications de boîtes pour les différents sens des traductions, la plupart de ces boîtes n'ayant pas encore de contenu. La limite de 8 lignes est bien entendu paramétrable (première ligne de mon monobook.js). On peut aussi la faire dépendre du nombre de boîtes sur la page.
L'idéal serait de ne pas l'enrouler complètement si il y a trop d'entrées mais de n'en afficher que quelques unes et indiquer clairement qu'il y en a d'autres accessibles. Je vais essayer de coder un petit truc pour voir.
Mon code est plus pour vous montrer une idée et demander votre avis. Il devine le nombre de lignes en comptant les balises et les paragraphes et ne gère pas trop les cas particuliers. Il ne va pas voir un grand paragraphe par exemple. Je pense quand même que c'est une solution intéressant pour certaines utilisation des boîtes.
Cela me semble une bonne idée. Mais, personnellement, je ne mettrais pas le défaut à 8 lignes, j'afficherais tout par défaut. C'est encore le plus simple pour les gens (malgré le fait que beaucoup trouvent qu'on affiche trop d'informations). Restons simple. Lmaltier19 novembre 2008 à 16:32 (UTC)[répondre]
8 lignes n'est qu'un exemple, choisi car c'est facile à tester. Cependant, je suis pour une limite, même si elle est assez haute. Si on se retrouve, pour des mots courants, à avoir plusieurs sens qui ont des tableaux de traduction qui dépassent une page, cela va être difficile de s'y retrouver. Koxinga21 novembre 2008 à 10:26 (UTC)[répondre]
Vieux, c'est pour les mots encore utilisés, mais peu, et ressentis comme vieux par la plupart des gens quand on les entend (par exemple soleil au sens de tournesol). Désuet, c'est pour ceux qui ne sont plus du tout utilisés. Lmaltier19 novembre 2008 à 16:25 (UTC)[répondre]
Le problème, c'est que la plupart des gens, dont moi, comprennent désuet (2) « Dont les manières ou l’apparence sont vieillottes ou démodées. » C'est-à-dire le sens que tu donnes à vieux. --Szyx19 novembre 2008 à 18:34 (UTC)[répondre]
Tout à fait d'accord, je ne vois pas la nuance entre désuet et vieux que Serpicozaure semble voir. En fait, dans les deux cas c'est un mot passé de mode, la nuance pouvant seulement se rapporter à l'origine temporelle à partir de laquelle on considère quelquechose (ou quelqu'un) comme "vieux". Le sens ne dépend donc pas du terme utilisé mais du locuteur (et de son âge....). Je dirais aussi que "vieux" a une nuance supplémentaire péjorative ou négative (dans le discours des "jeunes") et on l'emploie aujourd'hui moins souvent que "ancien" (plus neutre), ou on le remplace par "vieilli"; le terme "vieux" serait-il devenu lui-même désuet ? Le terme "désuet" est d'un style littéraire plus avancé (et moins connu des incultes...) ce qui fait qu'il peut être lui aussi devenu désuet... Bref il a subit le même sort que les "vieux" : il a vieilli.
Le terme moderne à la mode est "obsolète", passé du français en anglais courant, puis repris largement en français (depuis un célèbre discours en Anglais de Yasser Arafat sur la signature de l'accord de paix avec Israël, avant l'assassinat du chef d'état israélien par un extrémiste juif, et la prise de pouvoir par les conservateurs israélien qui ont relancé le conflit et reminé l'alors toute jeune Palestine), bien que celui-ci soit employé souvent de façon trop forte : "obsolète" veut dire complètement plus utilisé du tout, alors que "vieux" ou "désuet" signifie encore rencontré parfois mais d'usage plus fréquent dans le passé.
On doit exclure "obsolète" car il est trop fort, mais on pourrait ajouter "obsolescent" qui se traduit aussi comme "en déclin".
Ici on parle de mode: ce qui est "désuet" aujourd'hui pourrait redevenir "in" demain. Il est impossible de trancher entre les deux termes, les usages et sens étant finalement compltement équivalents.
Maintenant expliquez les nuances (relatives au terme "usage") des termes "vieux"/"vieilli"/"obsolète", "vieillissant/obsolescent". Si un terme est réellement complètement disparu, pourquoi l'inclure dans le français moderne? C'est devenu un mot d'une langue étrangère (le vieux français ou autre), mais plus un mot français : relativement à cette autre langue, il n'a pas à être défini comme vieux ou désuet (c'est stupide). Il ne sert même pas à désigner un registre de langue, mais plutôt un emploi par une catégorie plutôt âgée de locuteurs, sans garantie que ce soit définitif ni vrai pour tous les locuteurs de la langue française (en France ou ailleurs dans le monde): le mot peut revenir facilement en France à l'occasion d'un discours, d'un écrit, d'une chanson, d'un autre évènement, sans qu'il ait jamais vraiment disparu ni même perdu ou modifié son sens en passant par un autre pays... On retrouve aujourd'hui nombre d'anciens mots relatifs à des termes agricoles traditionnels, grâce à l'essor du tourisme vert, aux préoccupation pour le développement écologique et durable, ou l'aide au développement des régions défavorisées, ou simplement par un accroissement des communications internationales : les termes les plus anciens sont aussi les plus résistants à l'usage (contrairement à de nombreux néologismes qui peuvent devenir obsolètes bien plus vite : qui se souviendra encore dans seulement 10 ans de la musicassette, ou du magnétoscope ? ou dans 30 ans du CD ? Seulement les "vieux". Alors qu'on parlera encore des pis et bouses de vaches, ou des variétés d'élevage, ou des termes de la sellerie ou l'armurerie traditionelle, ou de cuisine...).
En résumé : les deux modèles {{désuet}} et {{vieilli}} sont totalement équivalents selon moi, chacun étant redondant par rapport à l'autre. S'il fallait en supprimer un, ce serait "vieux/vieilli" (car cet usage est trop ambigu et ne se rapporte pas réellement à l'âge réel du mot, mais l'usage supposé de sa mort qui n'a même pas encore eu lieu...)
Je viens de m'apercevoir que le modèle {{pron}} ne faisait pas ce qu'il est censé faire, parce qu'il a été cassé (il y a un an...).
Un exemple de ce que devrait faire le modèle s'il marchait correctement : /ʁɛs.to.rɑ̃/ => /ʁɛs.to.rɑ̃/.
Je rappelle qu'un des principaux buts de ce modèle est de pouvoir convertir l'API vers X-SAMPA automatiquement selon les préférences des utilisateurs, sans avoir besoin d'écrire les deux. Or cette modification de Verdy_p a complètement cassé l'intérêt du modèle .
Je vais donc devoir corriger le modèle (après quelques tests). Ceci met encore une fois en lumière la nécessité de discuter avant de toucher à ce genre de modèles (d'ailleurs ceux-ci devraient peut-être être bloqués complètement et n'être modifiés que par des admins, ça posera moins de problèmes). - Dakdada(discuter)20 novembre 2008 à 09:46 (UTC)[répondre]
J'ai testé le modèle Utilisateur:Darkdadaah/Modèle:pron pour les différents cas d'affichage, et il me semble correct. J'ai en outre éliminé le paramètre "réf" qui ne devrait pas être inclus dans le modèle (il peut très bien être mis en dehors, et ce serait mieux). Afin de ne pas précipiter les choses, j'attend votre accord pour faire le changement. - Dakdada(discuter)20 novembre 2008 à 10:20 (UTC)[répondre]
Ca a été discuté il y a un an... C'est le Javascript qui devait prendre en charge le code, pour dupliquer la ligne si nécessaire dans les préférences... Je ne vois pas l'intérêt de générer le même texte deux fois, quand la Javascript sensé l'utiliser pour afficher le X-SAMPA (pas affiché par défaut) peut aussi faire cette duplication et transformation lui-même ! Note: Sans JavaScript, il ne faut pas afficher deux fois la même chaîne, hors on n'a plus qu'un seul paramètre depuis longtemps, ce qui signifie que le code HTML de toute façon ne contient PAS depuis longtemps le X-SAMPA. verdy_p20 novembre 2008 à 11:31 (UTC)[répondre]
J'invite donc l'utilisateur qui se plaint à modifier son vieux code pour X-SAMPA lui-même (une solution à jour avait été donnée à l'époque, mais je ne sais plus où). Dommage qu'il revienne aussi tard sur cettte question.
Si on ne le retrouve plus, il est quand même facile de chercher en Javascript un div de classe X-API-SAMPA contenant un div de class X-API, pour insérer en Javascript un div de plus pour le SAMPA, et/ou cacher l'API.
On peut noter que ce code Javascript pourrait être mis à la disposition de tout le monde dans un gadget préchargé et activable directement dans les préférences. Ce code Javascript n'a pas besoin du tout de la section X-SAMPA pour fonctionner. De plus le modèle pron n'est plus nécesairemetn dans une section {{-pron-}} mais le plus souvent directement sur la ligne du terme défini et dans les tableaux (donc pas le lien avant pour dire si c'est de l'API ou du X-SAMPA; je ne vois pas comment on peut alors indiquer les deux simultanément sans ambiguité, et selon une mise en forme qui casserait les tableaux contenant aussi de l'API (voir les modèles de conjugaison, d'accords, pages rimes, etc.). verdy_p20 novembre 2008 à 11:44 (UTC)[répondre]
Il faut penser aux utilisateurs « normaux », pour qui le mot « javascript » n'évoque absolument rien. Une option dans les préférences est indispensable. --Szyx20 novembre 2008 à 16:11 (UTC)[répondre]
L'utilisateur vraiment "lambda" (je dirais plutôt "alpha" ou "bêta") n'aura pas de doute façon pas de compte utilisateur, donc pas de préférences. L'option pardéfaut pour lui est déjà d'afficher l'API uniquement, qu'il ait JavaScript activé ou non sur son navigateur).
En revanche, si un utilisateur a un compte, il vaut mieux que Javascript soit activé pour se servir des préférences et aller jusqu'à l'onglet des gadgets, où il pourra choisir la transformation d'API en X-SAMPA : la case à cocher peut préciser "(nécessite JavaScript)"... verdy_p21 novembre 2008 à 11:14 (UTC)[répondre]
Questions : est-ce que certains utilisateurs peuvent avoir fait le choix de désactiver Javascript et se servir quand même du Wiktionnaire actuellement ? Quelle est la meilleure solution si on veut tenir compte de ces utilisateurs ? Lmaltier21 novembre 2008 à 09:56 (UTC)[répondre]
Oui, c'est toujours possible, seuls quelques outils pratiques seront désactivés (par exemple les menus déroulants seront de simples tableaux). Si le javascript est désactivé, dans le cas des prononciations, on ne verra que l'API (cas actuel de toute façon) : ça me semble suffisant. - Dakdada(discuter)21 novembre 2008 à 10:11 (UTC)[répondre]
Bon, le schmilblick avance : il faudrait donc intégrer directement la possibilité de changer l'API en X-SAMPA dans les préférences, de manière à ce que ce soit transparent pour les utilisateurs. En outre, la duplication API/X-SAMPA éventuelle pourra aussi se faire dans le code javascript qui effectue le changement (niveau utilisateurs ça ne fera rien). Ce genre de chose est tout à fait possible, et d'autres fonctions pourraient éventuellement aussi être mises dans les préférences (coloration des historiques par exemple, cf Wikipédia). Je vais potasser tout ça, merci. - Dakdada(discuter)21 novembre 2008 à 09:29 (UTC)[répondre]
Dans l'immédiat, inutile de changer le modèle qui reste bien comme il est. Mais pour la fonction Javascript il y a quelques tests préalables à faire pour la compatibilité du code qui manipule le HTML via le DOM pour lire le contenu d'un "span" existant et insérer des "span" supplémentaires. Rien de très compliqué là-dedans. La fonction de conversion API-vers-SAMPA reste en revanche assez basique et ne dépend pas du navigateur. verdy_p21 novembre 2008 à 11:22 (UTC)[répondre]
Note: le span à transformer possède les deux classes API et SAMPA. Le Javascript peut rechercher les objets de classe API, mais il ne doit transformer que ceux qui possèdent les deux classes : pour ceux là, il change leurs classes en "API" uniquement, et ajoute un span de classe "SAMPA". Dès lors le code CSS mentionné dans le modèle peut fonctionner directement (pour les utilisateurs qui ont des préférences). Mais je suggère quand même que ce Javascript de transformation ne s'active pas par défaut (sur toutes les pages?) pour tout le monde (même si la feuille de style CSS par défaut mentionne de n'afficher que l'API et cacher le SAMPA), mais seulement via un gadget à cocher dans les préférences. verdy_p21 novembre 2008 à 11:30 (UTC)[répondre]
Peut-être pas un Projet Javascript à la Wikipédia, mais je verrais bien une page recensant et expliquant les fonctions, centralisant les résultats des débats (et des liens vers les discussions correspondantes). Koxinga22 novembre 2008 à 12:18 (UTC)[répondre]
Dites, pourquoi chaque fois que j'essaie de changer mes préférences, j'obtiens le message « Votre mot de passe est trop court. Il doit contenir au moins 1 caractère et être différent de votre nom d’utilisateur. » ? Cela ne date pas d'aujourd'hui (mais, dans ma jeunesse, ça ne le faisait pas ;-). Je suis obligé de retaper le mot de passe pour débloquer ça. --Szyx22 novembre 2008 à 21:53 (UTC)[répondre]
J'ai remarqué ça: le formulaire insiste pour nous demander de taper l'ancien mot de passe car il croit qu'on veut changer notre mot de passe (alors qu'on ne veut entrer aucun nouveau mot de passe, donc l'ancien mot de passe n'est pas nécessaire).
Du coup on doit taper le mot de passe actuel trois fois dans le premier onglet même si on n'y a rien modifié. C'est un bogue du formulaire, qui oublie de tester d'abord si on a saisi un nouveau mot de passe, le seul cas où l'ancien mot de passe peut être nécessaire. Ca date aussi d'il y a environ un mois et demi, mais au début je croyais que j'avais oublié quelquechose ou fait une action protégée. C'est général: même si on ne change strictement aucune option dans les préférences et qu'on fait "Valider", on aura le message d'erreurs.
J'ai ajouté la conversion API -> X-SAMPA dans les gadgets, en enlevant tout le code du Monobook.js (il n'est désormais chargé que si on active l'option : beaucoup plus léger à charger pour la majorité des personnes...). Pour des exemples, comparez ceci : /ɔʁ.nə.mɑ̃/ en activant et désactivant l'option qui apparait désormais dans vos préférences à l'onglet Gadgets. À noter qu'il n'est plus possible de redoubler les deux prononciations, mais étant donné la simplicité pour passer de l'une à l'autre désormais, je pense que ce n'est pas vraiment nécessaire.
Il faut maintenant changer les modèles {{pron}} et {{phon}} afin qu'ils prennent désormais cette conversion en charge. Je vous demande donc explicitement : voulez-vous bien que je change le modèle {{pron}} par Utilisateur:Darkdadaah/Modèle:pron (et {{phon}} par un équivalent) ? Le changement sera un peu lourd à répercuter, mais on aura alors un modèle plus léger et mieux adapté. - Dakdada(discuter)22 novembre 2008 à 20:08 (UTC)[répondre]
Cela fonctionne chez moi. Pas de souci pour faire la modification du modèle. Par contre ton autre exemple de gadget ne fonctionne pas chez moi. Koxinga22 novembre 2008 à 21:03 (UTC)[répondre]
Ceci dit, rien n'empêche ton code de fonctionner aussi en recherchant via les fonctions du DOM les éléments de classe "API" et ceux de classes "API X-SAMPA". Si le gadget est en place, on devrait même ne plus avoir à changer la classe "API X-SAMPA" (les deux ensembles) en "API" seulement. Il suffirait que le modèle ne génère plus QUE la classe "API" (puisque déjà la classe X-SAMPA indiquée par le modèle dans le span interne est redondante, celle-ci ne contenant que de l'API).
Comme dit plus haut (je crois), je pense qu'on peut facilement se passer du redoublement de la prononciation, et utiliser en effet simplement une classe unique API (ou pron-API), convertie ou non en X-SAMPA selon l'activation du gadget. - Dakdada(discuter)26 novembre 2008 à 15:47 (UTC)[répondre]
Note: ton code est trop lent, car il parcourt la liste de tous les spans (il peut y en avoir beaucoup dans une page):
// Parcours de toutes les prononciations d'une page et conversion de chacunefunctionpronpage(){for(vari=0;pron=document.getElementsByTagName("span")[i];i++){if(pron.className=="API"){pron.className="X-SAMPA";pron.title="prononciation X-SAMPA";pron.innerHTML=APIversXSAMPA(pron.innerHTML);}}}
Il vaut mieux rechercher les éléments par nom de classe "API" (on peut éventuellement vérifier que c'est bien un "span" ou "SPAN").
C'est ce que je veux faire, mais il n'y a pas de fonction getElementByClass par défaut (je crois que je les ai vues sur Wikipédia, je vais voir si je peux les piquer). - Dakdada(discuter)26 novembre 2008 à 15:47 (UTC)[répondre]
Ton test (pron.className == "API") ne marche que s'il n'y a qu'une seule classe (API), alors qu'avec l'autre méthode tu détectes tous les éléments possédant la classe "API" :
// Parcours de toutes les prononciations d'une page et conversion de chacunefunctionpronpage(){for(vari=0;pronAPI=document.getElementsByClassName("API")[i];i++){varpronMixte=pron.parentNode;if(pronMixte.className="pron-API-SAMPA"&&pronAPI.className="API X-SAMPA"){/* insère un label avant l'API (optionnel) pour l'afffichage mixte */varlabel=document.createElement("span");label.className="pron-API-label"label.innerHTML="API ";/* on pourrait aussi ajouter un lien ici de type <a href="http://..."></a> */pronMixte.insertBefore(pronAPI,label);/* change la classe du span API X-SAMPA en une classe unique API */pronAPI.className="API";/* insère un séparateur pour l'affichage mixte */varpronSeparateur=document.createElement("span");pronSeparateur.className="pron-mixte"pronSeparateur.innerHTML=", ";pronMixte.insertAfter(pronAPI,pronSeparateur);/* insère un label avant le X-SAMPA (optionnel) pour l'afffichage mixte */varlabel=document.createElement("span");label.className="pron-XSAMPA-label"label.innerHTML="X-SAMPA ";/* on pourrait aussi ajouter un lien ici de type <a href="http://..."></a> */pronMixte.insertAfter(pronSeparateur,label);/* insère un span pour la prononciation X-SAMPA */varpronSAMPA=document.createElement("span");pronXSAMPA.className="X-SAMPA";pronXSAMPA.title="prononciation X-SAMPA";pronXSAMPA.innerHTML=APIversXSAMPA(pronAPI.innerHTML);pronMixte.insertAfter(label,pronXSAMPA);}}}
Laisser les utilisateurs choisir quelle prononciation ils veulent comme documenté. Les utilisateurs peuvent aussi grace à ce code ajouter une fonction javascript pour basculer l'affichage avec l'un ou l'autre ou les deux (cela ne changera pas les classes et objets générés, mais basculera seulement le style "display:none"/"display:inline" pour les éléments appropriés.
Ce code pourrait être là par défaut (sans avoir à utiliser un gadget), les utilisateurs se contentant d'éditer leur propre feuille de style CSS pour faire la bascule. verdy_p26 novembre 2008 à 13:56 (UTC)[répondre]
Ah bah non : l'intérêt de tout ça c'est qu'on a pas besoin de mettre les mains dans le cambouis, juste à cocher une case (pense aux utilisateurs qui ne sont pas informaticiens...). En outre, pourquoi charger par défaut un gadget qui ne serait en définitive utilisé que par peu de personnes (et qui peuvent le charger avec un clic) ?
Il faut rester simple : à mon avis, on peut se contenter d'une classe pron-API dans un span, que la fonction recherche avec getElementByClass (une fois activée) et remplace par la classe pron-X-SAMPA en convertissant le texte à l'intérieur au passage. - Dakdada(discuter)26 novembre 2008 à 15:47 (UTC)[répondre]
Soit! dans ce cas considère au moins la méthode de parcours (recherche par nom de classe et non par nom d'élément "span" : c'est une des causes principales de lenteur du script (particulièrement sous IE dont le moteur de script est assez lent). D'autant que cela corrige le test de valeur de la classe (puisque tu ignores le fait que l'attribut className d'un élément peut contenir plusieurs noms de classes séparés par une espace, la raison pour laquelle le script actuel ne marche pas. Ceci dit, on pourrait changer le modèle pron pour qu'il ne génère qu'un seul nom de classe "API" au lieu de "API X-SAMPA" pour le span interne.
Yep merci pour ces conseils, je pense qu'on peut en effet enlever l'imbrication des deux spans, et ne garder que la classe API, en utilisant bien sûr la méthode de parcours que tu proposes. Y'a plus qu'à... oh un lien rouge - Dakdada(discuter)27 novembre 2008 à 09:05 (UTC)[répondre]
J'ai mis à jour le gadget qui utilise désormais la fonction getElementsByClassName (trouvée dans wikibits.js), et remplace la classe API par la classe X-SAMPA en conservant les autres classes éventuelles (non destructeur). Je pense qu'il est donc temps de changer les modèles {{pron}} et {{phon}}. - Dakdada(discuter)3 décembre 2008 à 20:40 (UTC)[répondre]
Voilà c'est fait. Tout semble normal, et il ne semble pas y avoir une grosse surcharge (la queue est passée de 4000 à 8000, mais ça me semble raisonnable…). Si vous rencontrez un quelconque problème, n'hésitez pas à m'en faire part. - Dakdada(discuter)3 décembre 2008 à 21:42 (UTC)[répondre]
Je viens de tomber sur des pages de chiffres. Par exemple, à Catégorie:Noms communs en français, on trouve en tête de catégorie les pages 06, 09, 15, 21, etc. Elles sont à peu près copiées sur six, neuf, quinze, vingt-et-un, etc. Or, un chiffre comme 15 n’est pas particulièrement français : c’est la représentation chiffrée en caractères latins du nombre quinze. J’ai créé un {{-chif-}} qui suit {{caractère}} dans ses grandes lignes, ce qui donne des pages comme 94 et 9, mais ce n’est pas complètement satisfaisant.
Certains des sens sont quand même spécifique au français non ? Ceux relatifs au département par exemple. Dans ce cas, il faut ajouter une section français en plus. rrKoxinga22 novembre 2008 à 12:19 (UTC)[répondre]
Je dirais que les nombres écrits en chiffres ne sont pas des mots, et ne devraient donc pas être présents, sauf cas particuliers comme 06, ou les numéros de départements quand ils sont précédés de l'article défini, même si c'est vrai qu'on pourrait tous les considérer comme des noms communs, par exemple dans "le 2, le 4, le 6, le 8, le 10, le 12" (tirage du loto). Lmaltier22 novembre 2008 à 21:15 (UTC)[répondre]
Non, les numéros de départements ne sont pas spécifiques au français, ils sont spécifiques à la France. En résumé, je trouve qu'ils n'ont rien à faire ici. --Szyx22 novembre 2008 à 21:41 (UTC)[répondre]
Proposition : Changer les règles d’inclusion du Wiktionnaire afin d’exclure les expressions chiffrées (par ex. « 99, 69, 1000, 1,000 ») ou mathématiques (« 1+1, 3×3 »), hormis les caractères individuels (« 0..9 ») et certains cas attestés (« 4×4 »).
Il faudrait préciser la proposition (en particulier le "certains cas attestés"). Je suis Pour exclure les nombres écrits en chiffres, quand ils n'ont pas de signification particulière autre que de représenter le nombre, même quand ils sont précédés de l'article (par exemple : que quelqu'un dise le 49 lors d'un tirage du loto ne suffit pas). Mais je suis Contre les exclure quand ils sont bien attestés utilisés avec l'article et avec un sens bien particulier, qu'on ne peut pas forcément deviner : par exemple : un 06 (même si je ne connaissais pas cet emploi, spécifique à la France) ou le 93 pour le département (emploi en tant que nom propre, également spécifique à la France, et qui plus est souvent prononcé de façon particulière). Mais il faut veiller à toujours mettre des attestations, et à ne pas généraliser hâtivement : je ne suis pas sûr qu'on puisse appeler la Seine-Maritime le 76, et le fait que 76 soit son code départemental ne suffit pas à justifier l'inclusion ici. De la même façon, les codes postaux n'ont rien à faire ici (sauf éventuellement emplois particuliers, mais je ne crois pas qu'il y en ait) Lmaltier25 novembre 2008 à 10:13 (UTC)[répondre]
Ca se dit dans tous les départements. Au moins ceux où j'ai vécus et où je vais encore assez souvent : 35, 59, 75, 92, 44, 85, 22, 56, 79, 17... La prononciation chiffre par chiffre est une mode francilienne qui s'étend aux départements possédants des banlieues urbaines et peut aussi disparaître aussi vite (ce n'est guère répandu, et pas d'usage systématique dans le langage des djeun's même quand ils parlent entre eux. Le nom du département et la prononciation du normale du nombre reste bien plus fréquents).
Pour J'avais déjà vu ça il y a un moment. Ces nombres (de simples numéros d'ordre) ne sont pas des noms, mais ils sont utilisés en apocope (en omettant d'indiquer "département" avant). On peut faire de telles apocopes pour tous les nombres et avec tous les sens omis possibles, suivant le contexte. Et aussi dans ce cas, on peut aussi bien prononcer le nombre normal que l'épeler chiffre par chiffre (comme dans "j'habite dans le 93" = "dans le neuf-trois"). Ce n'est pas propre aux départements, et cela s'étend aussi aux nombres ordinaux (arrondissements de Paris par exemple, ou siècle...).
En revanche, il n'est pas inutile d'avoir des articles montrant comment on écrit ou prononce les éléments de nombres (0 à 16, 20, 30, 40, 50, 60, 70, 80, 90, 100, 1000, 1000000) en français ou d'autres langues, mais ils devraient plutôt être dans des sous-catégories à part et pas classés dans l'index principal de chaque langue.. (plutôt dans "Nombres en français", etc...) verdy_p26 novembre 2008 à 14:07 (UTC)[répondre]
Bah c'est Utilisateur:KoxingaBot (hum, tu as voté pour lui, tu te souviens ?), qui attend justement d'avoir des règles cohérentes pour passer à l'action. Il est capable de trier les traductions, équilibrer les colonnes, passer en trad+ et trad-, traiter à part les langues n'ayant pas de wiki. S'il le faut, je peux l'adapter, par exemple s'il faut essayer de détecter les mots liés sans utiliser le modèle {{trad}}.Koxinga23 novembre 2008 à 23:29 (UTC)[répondre]
Pour le modèle de tableau à part : il serait souhaitable d'avoir une boite déroulante identifiable, ce qui permettrait par exemple de les dérouler, enrouler voire cacher via les préférences, ce qui permettra aux lecteurs de personnaliser l'affichage. - Dakdada(discuter)24 novembre 2008 à 09:13 (UTC)[répondre]
Oui, il faudrait un modèle dédié de boite déroulante pour pouvoir le paramétrer indépendamment. Comme par exemple qu'elle soit automatiquement déroulée en dessous d'une certaine taille, et enroulée au dessus. --Szyx24 novembre 2008 à 22:23 (UTC)[répondre]
Les boîtes déroulantes devraient toutes être déroulée par défaut, pour les visiteurs anonymes (et toujours déroulées à l'impression). Si des utilisateurs veulent des boîtes réduites à l'écran, ce devrait être dans leurs préférences (une case à cocher dans les Gadgets pour modifier la feuille de style CSS générale). verdy_p26 novembre 2008 à 16:55 (UTC)[répondre]
Tout à fait d'accord : c'est mieux de dérouler par défaut. Avec les ascenseurs, ce n'est pas un problème, surtout quand on met les traductions à peu près à la fin. Et ce n'est pas plus long à charger (peut-être même moins long). Lmaltier13 décembre 2008 à 17:06 (UTC)[répondre]
Statistique Canada nous autoriserait-elle à utiliser ses glossaires ?[modifier le wikicode]
Je me demandais s'il serait réalise de demander officiellement le droit de reproduire le contenu de ces glossaires du gouvernement canadien.
Leurs conditions générales [6] stipulent « La reproduction, à des fins de redistribution commerciales, de l’information gratuite présente sur le site de Statistique Canada est interdite, en tout ou en partie, sauf avec la permission écrite de l'administrateur du droit d'auteur de Statistique Canada. », avec un lien vers le formulaire, ce qui est plutôt encourageant.
Il faudrait pour bien faire passer par OTRS (je n'ai guère d'idée comment cela fonctionne, mais les deux contributeurs mentionnés sur cette page pourraient nous aider).
Très peu probable, cela reviendrait à leur demander de changer de licence. Car s'ils "nous" donnent l'autorisation, la GFDL fait que plus personne n'aura besoin d'autorisation. En l'état leur licence est tout simplement incompatible avec la GFDL. --Markadet∇∆∇∆25 novembre 2008 à 00:14 (UTC)[répondre]
« La GFDL fait que plus personne n'aura besoin d'autorisation » : exact, bonne remarque. Par contre elle oblige à jamais à les citer comme auteurs.
Mon idée était néanmoins que ces glossaires ne sont qu'une annexe de ce qu'ils veulent réellement protéger : leurs données statistiques. Pas grave. --Szyx25 novembre 2008 à 15:55 (UTC)[répondre]
L'exclusion de l'usage dans un produit commercial rend cette autorisation totalement incompatible avec la GFDL qui interdit de telles exclusions.
Donc le seul moyen serait de leur demander une licence compatible avec la GFDL, signée et validée par eux, précisant le type de données qu'on est autorisé à copier et diffuser librement (ils pourraient exclure par exemple toute reproduction de leurs statistiques, ou fournir ou approuver un fichier filtré contenant les données autorisées à un usage libre).
Mais pour le faire, il vaut mieux que ce soit par un contact local au Canada qui sait comment ils procèdent et travaillent, et qui peut négocier et travailler avec eux pour valider les données autorisées à une utilisation libérée des droits exclusifs de publication (et sans contrainte de dénomination ni de lien en retour, ni contrainte interdisant les modifications, ni contrainte de noms de domaine pour un site Internet, ni de contrainte concernant le type de support: livres, CD/DVD, accès via un réseau privé, miroirs..., ni de contrainte relative à la mention ou la déclaration préalable envers eux d'un responsable de la publication.
En revanche on peut s'engager à les mentionner comme sources pour les données originales conservées dans nos historiques (si possibles importées par un Bot pour limiter les risques d'erreur, comme on l'a fait pour l'import du DAF), ce qui n'exclue pas non plus l'ajout d'autres sources ou auteurs puisque toutes les modifications/suppression/éclatements/fusions/corrections ou autres réorganisations de la structure des pages et données doivent rester possibles. verdy_p26 novembre 2008 à 17:07 (UTC)[répondre]
En gros ça dit que les langues les plus connues par le plus d'inscrits ont des moyennes plus basses que celles pour lesquelles ne participent réellement que quelques utilisateurs ou administrateurs qui font le gros du travail presque tous seuls. Ca ne me surprend pas.
Cependant l'anglais fait exception par rapport à l'espagnol: peu d'éditions car peu de corrections à faire (le gros des données provient du Wiktionnaire anglais où les éditions sont très nombreuses et faites par énormément de monde (donc le nombre d'articles ou d'édition par utilisateur est faible), et le plus gros du travail n'est pas fait ici.
Le cas de l'ido est emblématique d'une langue supportée réellement par un seul utilisateur (Fafnir) qui fait presque tout avec un Bot d'importation depuis une source déjà corrigée (il reste à savoir la validité en terme de droit de tels imports en masse), mais ne met en fait aucune définition en langue ido (il fait essentiellement un lexique croisé de traductions). Reste à savoir l'utilité du Wiktionnaire ido: est-ce vraiment un dictionnaire ? L'utilisateur connait-il vraiment cette langue ou n'invente-t-il pas lui-même une terminologie basée sur une maitrise uniquement de la phonétique et l'orthographe générale, en adaptant des mots d'autres langues (visiblement il connait bien l'anglais et surtout le russe, la terminologie s'en ressent et suit trop le lexique russe/slave, plus que ce qu'ont voulu les créateurs ou promoteurs de l'ido, dont la base latine est bien plus importante que ce que suggère le Wiktionnaire ido actuel...)
Le cas du français donne un chiffre surprenamment élevé pour les articles par admin : seraient-ils les seuls à faire le gros du travail? Est-ce que parmi les admins on compte aussi les Bots d'importation (du DAF, des gentilés, des flexions de mots, etc.) ? Ceci dit, notre Wiktionnaire a pu bénéficier de sources de qualité pour créer une grande partie de nos articles, et d'une automatisation très poussée pour créer les flexions, gentilés, annexes de conjugaisons, etc... Ce qui a limité le nombre d'éditions nécessaires dans nos articles. verdy_p26 novembre 2008 à 17:16 (UTC)[répondre]
J'ai compris ça comme le rapport : nombre d'articles/nombre d'articles, ça me parait plus cohérent. Par contre pour le nombre d'éditions par inscrits, je pense qu'il faudrait pouvoir distinguer les éditions des bots, je suis sûr que ça changerais pas mal de choses : on serait alors selon moi du même ordre de grandeur que l'anglais et l'espagnol (entre les deux). - Dakdada(discuter)26 novembre 2008 à 17:45 (UTC)[répondre]
Je ne cherchais pas à tirer de conclusion, c'est yi: avec ses 50 administrateurs qui m'avait fait rire (seul en: en a plus).
Néanmoins, on peut retenir que parmi les « gros » Wiktionnaires fr: a peu d'inscrits (10 fois moins que en:), rapporté à son volume. Il est évident que la part des bots est non négligeable (mais je n'oublie pas les contributeurs sous IP dont certains sont prolifiques). --Szyx26 novembre 2008 à 18:59 (UTC)[répondre]
)
, 
, 
, 
. Toutes en CAPITALES, pour éviter les conflits avec les codes de langues, ainsi que 
. I think you may be interested in choosing this as a new favicon, since it matches the French Wiktionary logo.
. Je pense que vous pourriez être intéressé dans le choix d’une nouvelle favicon, car il correspond au logo du Wiktionnaire francophone.
Pour. verdy_p 10 novembre 2008 à 12:12 (UTC)
a voté. VIGNERON * discut. 12 novembre 2008 à 16:45 (UTC)
.)
Avis aux amateurs ! --Szyx 19 novembre 2008 à 22:38 (UTC)
Neutre, et pour les symboles comme ' ou ’ ? plutôt 
Contre VIGNERON * discut. 25 novembre 2008 à 08:27 (UTC)
--Szyx 28 novembre 2008 à 21:53 (UTC)
