Bonjour, vous êtes venu ici pour chercher la signification du mot Wiktionnaire:Wikidémie/mars 2013. Dans DICTIOUS, vous trouverez non seulement toutes les significations du dictionnaire pour le mot Wiktionnaire:Wikidémie/mars 2013, mais vous apprendrez également son étymologie, ses caractéristiques et comment dire Wiktionnaire:Wikidémie/mars 2013 au singulier et au pluriel. Tout ce que vous devez savoir sur le mot Wiktionnaire:Wikidémie/mars 2013 est ici. La définition du mot Wiktionnaire:Wikidémie/mars 2013 vous aidera à être plus précis et correct lorsque vous parlerez ou écrirez vos textes. Connaître la définition deWiktionnaire:Wikidémie/mars 2013, ainsi que celles d'autres mots, enrichit votre vocabulaire et vous fournit des ressources linguistiques plus nombreuses et de meilleure qualité.
C'est dans le cadre d'une révision globale du contenu de cette catégorie que je viens ici solliciter vos avis. J'ai en effet pu remarquer certaines incohérences qu'il serait souhaitable de corriger/réviser. Les sections qui suivent mêlent propositions et remarques, sur lesquelles vous êtes cordialement invités à donner votre avis.
Afin d'étudier la légitimité de cette catégorie, il serait souhaitable que le dictionnaire contienne l'entrée verbe applicatif, ou alors le sens qu'on donne à l'adjectif applicatif lorsqu'il qualifie un verbe. Quelqu'un en connait-il le sens ?
L’applicatif est une opération sur la valence verbale (comme le passif, l’anti-passif, le causatif, le moyen) qui promeut un oblique au statut d’objet ou introduit un nouvel élément en tant qu’objet, le rôle sémantique du sujet restant inchangé. Voilà pour une définition selon l’approche typologique fonctionnelle. Maintenant si on traduit ça avec les termes utilisés par la grammaire classique ou par la grammaire générative transformationnelle : c’est une voix qui transforme le complément circonstanciel non obligatoire en complément d’objet obligatoire ou ajoute un complément d’objet sans pour autant modifier le statut du sujet. (je ne suis pas sûr d’être clair, j’vais aller compléter sur la page du mot)
Traditionnellement, on considère qu’il n’y a pas ça en français parce qu’il n’y a pas de modification du verbe lorsque ça se produit, donc ça ne se voit pas très bien. Dans d’autres langues, on rajoute des affixes au verbe ou aux éléments de la phrase.Je ne connais pas le lingala mais cette catégorie peut exister dans cette langue car la forme de base de ce groupe de verbe est à l’applicatif. Peut-être. A confirmer. Eölen (discuter)1 mars 2013 à 23:52 (UTC)
C’est pas évident à expliquer. Voir l’exemple -ela#ln : kokáta (« couper ») devient kokátela (« couper pour quelqu’un ») à l’applicatif. Parfois, le changement sémantique est un peu moins évident : koúma (« tarder ») devient koúmela (« durer »). On retrouve ce type de verbe dans d’autres langues bantoues comme le swahili. --Moyogo(discuter)2 mars 2013 à 10:07 (UTC)
Merci, c’est très intéressant. Donc dans la Catégorie:Verbes applicatifs on trouve les verbes incluant ce suffixe, rendu par V + pour/par. A mon avis, on peut donc garder, mais il serait intéressant de compléter la définition d’applicatif par une phrase d’exemple/explication tirée d’une grammaire lingala (ou autre langue bantoue). Car je ne suis pas sûr que ce soit clair pour tout le monde. Eölen (discuter)2 mars 2013 à 12:31 (UTC)
Merci Mogoyo pour l’exemple. Il me semble que la notion est maintenant clairement défini, c’est bien ! Merci donc aussi à Automatik d’avoir posé la question initialement ! Eölen (discuter)3 mars 2013 à 14:41 (UTC)
On met tout ça dans les dérivés, même si certains grammairiens font de savantes distinctions entre les deux. Mettre dans les dérivés est forcément bon, puisque ça en dérive bien. Et il faudrait rajouter le sens à faible (la définition peut se contenter de renvoyer à verbe faible, si on n'arrive pas à faire mieux ; mais il est possible de faire mieux)). Lmaltier (discussion) 1 mars 2013 à 06:55 (UTC)
La question était juste de savoir si on peut considérer un mot comme un dérivé d'un autre même s'ils n'ont aucun lien étymologique ou sémantique. J'ai donc vu les avis de Vive et Lmaltier et ai ajouté verbe faible dans les dérivés de faible. Et comme j'avais oublié verbe fort, alors je le fais aussi. Merci du rappel. Automatik (discussion) 1 mars 2013 à 17:03 (UTC)
Je ne comprends pas : « … même s'ils n'ont aucun lien étymologique ou sémantique ». Verbe faible est bien sûr composé de verbe et de faible, avec leurs sens. — TAKASUGI Shinji (d) 4 mars 2013 à 15:01 (UTC)
Les 3 verbes recensés par cette catégorie ne s'utilisent pas uniquement à la voix passive. (ex: beurrer : Il beurre sa tartine de miel.)
A-t-elle un sens ? Je propose sa suppression.
Quant à la catégorie Catégorie:Verbes passifs en lingala, je suppose qu'elle justifie la catégorie parente (est-ce la seule langue qui la justifie selon vous ?)
J'ai l'impression que cette catégorie correspond à l'existence d'un participe passé adjectivé. Mais je pense qu'elle n'a effectivement pas de sens. Lmaltier (discussion) 1 mars 2013 à 06:57 (UTC)
Cette catégorie est créée par le modèle {{passif}}, qui ne devrait s'utiliser en fait que sur la ligne de forme des langues pour lesquelles c'est pertinent (pas le cas du français). Dans les trois pages, ce modèle est utilisé sur des lignes de définitions, ce qui est mal. Il faudrait remplacer le modèle par {{emploi|passif}}, par exemple. — Dakdada1 mars 2013 à 16:43 (UTC)
Ces trois verbe ne sont même pas passifs… À quoi sert cette catégorie ? Les voix de abréger, être abrégé et s’abréger sont respectivement active, passive et réfléchie (pronominale). Supprimer. — TAKASUGI Shinji (d) 2 mars 2013 à 03:56 (UTC)
Il fallait faire les deux, je propose donc à la suppression immédiate cette catégorie erronée, en renvoyant à cette discussion. Il reste donc une catégorie pour le lingala, à traiter à part éventuellement. Automatik (discussion) 14 avril 2013 à 13:48 (UTC)
Cette catégorie étant vide, la trouvez-vous pertinente ?
Wikipédia présente un article sur les noms verbaux, Nom verbal, et si vous trouvez cela pertinent, on pourra créer Catégorie:Noms verbaux en français (voir Wikipédia pour les entrées qu'elle pourrait contenir).
Ce serait le regroupement des noms directement dérivés d'un verbe ? Je ne vois pas son intérêt mais, si on l'avait, il faudrait un nom plus clair. Mais c'est un nom qui peut très bien s'appliquer à certaines langues, en raison de leurs traditions grammaticales. Lmaltier (discussion) 1 mars 2013 à 07:03 (UTC)
Apparemment en français ce sont les noms qui sont dérivés d’un verbe (l’intérêt est donc purement étymologique) mais en japonais c’est l’inverse ! Ce sont les noms qui peuvent donner un verbe en する donc ça n’a totalement rien à voir. V!v£ l@ Rosière/Murmurer…/1 mars 2013 à 07:29 (UTC)
L’article de Wikipédia ressemble fort à un TI (travail inédit). --GaAs 1 mars 2013 à 13:56 (UTC) L’article en anglais définit ça comme des « formes impersonnelles de verbes utilisées comme nom », donc pas des dérivés. --GaAs1 mars 2013 à 14:02 (UTC)
La catégorie n’est jamais utile s’il n’y a personne qui ajoute des mots. Est-ce qu’il y a quelqu’un qui s’intéresse à la maintenance de ces catégories ? Sinon je voudrais plutôt les supprimer. Il y a beaucoup de noms verbaux dans toutes les langues, comme movement (← move + -ment), 動き, ugoki (← 動く, ugoku + -i) et 움직임, umjigim (← 움직이다, umjigida + -ㅁ, -m). — TAKASUGI Shinji (d) 10 mars 2013 à 03:01 (UTC)
Je pense que, pour qu'un verbe soit réciproque ou réfléchi, il faut qu'il soit nécessairement pronominal, et je proposerai qu'on fasse de ces catégories des sous-catégories de Catégorie:Verbes pronominaux. Qu'en pensez-vous ?
Attends, ce déplacement est trop vite et probablement faux. Par exemple, l’anglais n’a pas de verbe pronominal. Et qu’est-ce précisément que le verbe réciproque ? Si c’est un verbe d’une action mutuelle, il n’est pas forcément pronominal dans une autre langue. En fait, ces deux catégories ne pourront pas être maintenables et utiles sans définition précise. Le Wiktionnaire anglais utilise le terme reflexive verb pour les verbes pronominaux. — TAKASUGI Shinji (d) 4 mars 2013 à 13:55 (UTC)
Peux-tu corriger mon erreur s'il te plaît ? J'ai encore à apprendre en anglais. Et dans les autres langues aussi puisque tu en parles. Automatik (discussion) 4 mars 2013 à 22:44 (UTC)
Si on prendre le verbe demander comme exemple, dans une autre langue, le verbe réciproque se traduit par « se demander » dans le sens « se demander l’un à l’autre » et le verbe réflexif se traduit par « se demander » dans le sens « se demander à soi-même ; se poser une question ». En français les verbes pronominaux peuvent avoir un sens réciproque ou réflexif, dans d’autre langues ces sens ont des verbes que leurs sont propres. --Moyogo(discuter)10 mars 2013 à 09:46 (UTC)
L’un est un site allemand : Medical Dictionary (http://www.dict.md/). Présence de pub, aucune mention de la licence ni du Wiktionnaire. Indique qu’il tire ses sources (entre autre) de FreeDict et openthesaurus mais omet les projets Wiktionnaires (que je suppose faire partie des "entres autres" lors de la traduction google). Je ne comprends pas l’allemand mais FreeDict utilise les fichiers .xml . Par conséquent je suppose qu’il utilise ceux du Wiktionnaire mais j’ai pas réussi à en trouver la preuve. Que ce passe-t-il si un site miroir pompe indirectement le Wiktionnaire, doit-il aussi indiqué la, licence, les sources et tralala ?
L’autre est serbe je crois : Stonito (http://stonito.com/). Aucune mention du Wiktionnaire, aucune mention de la licence mais au vu de l’omniprésence des promotions pour ses produits je suppose que c'est la licence capitaliste qui prime et la version du dictionnaire offline est payante (sachant que cette version est basée, en partie au moins, sur le Wiktionnaire). Pareil j’ai pas trop cherché. Est-ce normal ? On fait quoi ? V!v£ l@ Rosière/Murmurer…/1 mars 2013 à 07:22 (UTC)
Je ne trouve pas d'exemple flagrant pour le premier, et le site du second m'est inaccessible. Pour le principe, tout usage des données du Wiktionnaire est autorisé (même commercial), à condition de citer correctement la licence et l'origine des données. Ne pas oublier également que certains articles du Wiktionnaire ont été rédigés à partir de certaines sources qui ont pu être utilisées indépendamment par ces autres sites (le DAF8 par exemple). — Dakdada1 mars 2013 à 09:48 (UTC)
Pour le premier site j’avais un exemple probant mais étrangement il a disparu. J’avais utilisé Souillon, tu pues de la caquette ! pour vérifier le sens 3 de caquette et ces deux sites reprenaient exactement la définition et l’exemple du Wiktionnaire. (HS : D’ailleurs on est les seuls à indiquer ce sens et je n’ai pas trouvé d’attestation sur internet.) V!v£ l@ Rosière/Murmurer…/1 mars 2013 à 17:46 (UTC)
Pour le premier, il y a des définitions reprises mot pour mot (ex: maladie). Quant au second il semble y avoir un virus, en tous cas il est bloqué par mon anti-virus. UnsuiDiscuter3 mars 2013 à 15:11 (UTC)
Ce doit être surement via une bannière publicitaire car ni mon navigateur, ni mon antivirus ne détecte quoi que ce soit et vu que j’ai toujours AdBlock plus d’activé ça fait beaucoup d’ennui en moins. V!v£ l@ Rosière/Murmurer…/4 mars 2013 à 13:00 (UTC)
Merci. À ajouter ici. Puis cliquer en bas sur "Mettre à jour la liste". Stephane8888✍6 mars 2013 à 20:11 (UTC) P.S.: je n’ai vu le lien donné par Dak qu’après coup.
Création catégorie pour verbe italien
Certains verbes italiens ont une conjugaison régulière avec une prononciation irrégulière : voir la note dans modèle {{it-note/pron1}}. Faut-il créer une catégorie pour lister les verbes concernés (certains d'ailleurs ont une « prononciation régulière » et une « prononciation irrégulière » voir constatare) ? — message non signé de Borda (d · c) du 1 mars 2013 à 15:34
Si cette catégorie est créée et que toutes les annexes qui contiennent le modèle {{it-note/pron1}} sont concernées par cette catégorie, elles pourront être catégorisées automatiquement aussi. Automatik (discussion) 1 mars 2013 à 16:28 (UTC)
Oui voilà, le modèle peut distribuer tous les verbes utilisant le modèle {{it-note/pron1}} dans la catégorie. Si tu confirmes que toutes les pages contenant ce modèle méritent d'être dans la catégorie que tu demandes, alors je peux le faire. Voici les pages concernées : Spécial:Pages liées/Modèle:it-note/pron1. Bien entendu, je ne te demande pas de les vérifier tous . Une vue d'ensemble devrait te donner une idée assez juste de la question. je ne m'y connais pas en italien, c'est pour cela que je prends la précaution de te le demander.
A ma connaissance, tous les verbes utilisant ce modèle sont à classer dans cette catégorie, par contre certains verbes ont une prononciation irrégulière mais l'irrégularité est différente. Ils peuvent être gérés manuellement. Je vous laisse choisir le nom de la catégorie. 6 mars 2013 à 17:50 (UTC)Borda (discussion)
Ce nom de catégorie convient-il : Catégorie:Verbes réguliers ayant une prononciation irrégulière en italien ? En fait je crois m'être trompé pour la catégorisation automatique. Ce sont des pages d'annexes qui contiennent la note, et on va préférer peut-être catégoriser les pages des verbes eux-mêmes plutôt que les annexes non ? J'essaierai de générer une liste de ces pages prochainement. En attendant tous les avis sur la question sont accueillis à bras ouverts. Automatik (discussion) 6 mars 2013 à 18:21 (UTC)
Il y a aussi des verbes irréguliers avec une prononciation irrégulière. Voir certificare. Donc la bonne catégorie serait plus simplement verbe à prononciation irrégulière. Borda (discussion) 20 mars 2013 à 11:02 (UTC)
Entendu, si tu penses que cette catégorie présente un intérêt réel, dis-le, et je m’en occuperai ensuite sous peu. Je préfère créer si c’est sûr qu’il y a un sens. Cordialement, Automatik (discussion) 14 avril 2013 à 16:44 (UTC)
Une des discussions tenues lors de la rencontre de mercredi portait sur l’affichage des conventions internationales et des caractères. Ils sont actuellement présentés avec un bandeau identique à celui des langues, ce qui est parfois trompeur. Le français étant toujours en haut de la page, sauf dans ces deux cas. Quelques exemples : a, ua, age, Col
De la discussion a émergé deux propositions :
Faire un bandeau plus sobre, grisé, sans bordure pour les conventions internationales et caractères, éventuellement même seulement un cadre, les informations étant rarement longues
Rendre plus visible le bandeau français, par un fond coloré ou des étoiles scintillantes et des effets pyrotechniques (à préciser)
Le bandeau grisé me paraît une bonne idée. Une version expérimentale du gadget peut permettre de voir s'il est envisageable d'adopter la solution 2 ou pas. Il est plus facile de peser le pour et le contre ainsi. mais je n'ai pas les compétences Automatik (discussion) 2 mars 2013 à 20:37 (UTC)
D'un point de vue technique ce n'est pas aussi simple que ça en a l'air, car ce qui est stylisé c'est le titre de niveau 2 (h2 ou ==) et non le modèle à l'intérieur ({{langue}}). C'est possible de le faire avec une ligne de javascript, par contre. — Dakdada2 mars 2013 à 21:57 (UTC)
Attention, c’est « ǃxóõ » et non « !xóõ », avec la lettre clic rétroflexe ‹ ǃ › et non le signe de ponctuation point d’exclamation ‹ ! ›. Sinon autant écrire « |xam » et « ||xegwi » ou « ‖xegwi ».
Si c'est pas !xóõ la langue, alors il faudrait peut-être renommer la page (pour la redirection, est-ce correct de la laisser ?). De même changer ce qui est marqué dans la liste de langues. Si j'ai compris, ces trois langues vont en tout dernier dans une liste de traductions ? Automatik (discussion) 3 mars 2013 à 12:26 (UTC)
Pour l’ordre, difficile à dire, en général elles sont mises de côté. Pour la définition de rétroflexe, j’ai complété, en espérant que ce soit plus clair maintenant. Eölen (discuter)3 mars 2013 à 14:37 (UTC)
Je viens de renommer toutes les catégories « !xóõ » en « ǃxóõ ». Normalement il n’en reste plus. J’ai également modifié les articles ǃxóõ et ǃqhàa. Peut-être qu’on pourrait faire une redirection de l’article avec le point d’exclamation vers le clic rétroflexe ; les Anglais font comme ça.
En ce qui concerne la question initiale, pour éviter de se poser trop de questions, j’ai tout mis à la lettre X. Je pense que c’est là que chercherons plus naturellement les utilisateurs. Et ça évite de faire des ces langues un cas trop spécial. Pamputt3 mars 2013 à 16:34 (UTC)
Merci ; tu les classes comme on classerait xoo, xam, et xeg donc ? Vu que personne ne tapera jamais un clic rétroflexe sur son clavier, la redirection peut être intéressante en fait. Automatik (discussion) 3 mars 2013 à 16:46 (UTC)
Ouais, c’est ça, je les classes comme xoo, xam, et xegwi. Pour la redirection, je pense que je vais effectivement faire comme ça. Je regarde ça un peu plus tard si personne n’y a touché. Pamputt3 mars 2013 à 16:50 (UTC)
Sens figurés
Bonjour,
Lorsqu'on utilise le modèle {{figuré|fr}} pour définir un mot, ça catégorise la page dans Catégorie:Métaphores en français. Or certains sens figurés peuvent être le résultat d'une métonymie, et non d'une métaphore. En tout cas, c'est ce que dit le Petit Larousse 2000.
Alors, que faire ? Catégoriser dans Catégorie:Termes figurés en français, ou (re)créer le modèle {métaphore} qui a été redirigé vers {figuré} ? Et cela, sachant que {métonymie} existe déjà, et mène bateau tout seul. Ceux qui n'y comprennent rien aux modèles peuvent bien évidemment aussi donner leur avis. Automatik (discussion) 3 mars 2013 à 17:13 (UTC)
Effectivement il faudrait intervenir pour distinguer les deux tropes depuis leurs modèles. Je ne pense pas que certains aient employé {{figuré}} au lieu de {{métonymie}}, mais ne pouvant pas l’affirmer avec certitude la catégorie que tu proposes me semble la meilleure alternative. JackPotte ($♠) 3 mars 2013 à 17:38 (UTC)
Berrichon
Salut à tous
Lmaltier a créé des verbes tirés de cet ouvrage en ajoutant une précision Centre de la France. C’est peu clair car en fait il s’agit de mots du Berry. Et surtout ce n’est pas du français même pas du français régional, mais du dialecte berrichon et nivernais. Qu’en faire? Les laisser dans français et créer un modèle {{berrichon}}? Ou créer un code pour le berrichon - et donc sa catégorie:langue. Il y a bien le normand, déjà ici, non? Dhegiha (discussion) 3 mars 2013 à 21:11 (UTC)
J'ai peut-être été imprudent, mais le plus souvent, les citations utilisant les mots sont très clairement du français (La Fontaine, Furetière, etc.) ou du moyen français. C'est ce qui me fait dire que, dans l'esprit de l'auteur, ce qu'il traitait, c'était du français régional. Lmaltier (discussion) 5 mars 2013 à 08:37 (UTC)
Non, il décrit bien un dialecte. Voir page XII la description des conjugaisons. Ce qu’il fait c’est mettre les mots berrichons en rapport avec des citations anciennes de vieux ou moyen français. Le mots allochon est cité avec alloichons (1468), allumelle avec alemèle (Rutebeuf). Les conjugaisons du verbe aller ne laissent aucun doute : j’vas/j’allons/je vons, etc… Dhegiha (discussion) 5 mars 2013 à 10:34 (UTC)
L'impression très nette que j'ai, c'est qu'il cherche à décrire le français régional, qu'on peut considérer un dialecte du français. Les exemples et les citations qui utilisent les mots sont presque toujours très reconnaissables comme du français. Et ce sont bien des citations qui utilisent les mots. Lmaltier (discussion) 6 mars 2013 à 08:03 (UTC)
Bon. Comme d’habitude, j’ai tort, tu as raison. Ne tenons pas compte de Gallica qui classe l’ouvrage dans français (langue) - dialectes ou de ce compte-rendu qui écrit clairement tout mot qui brigue l’honneur de faire partie du glossaire doit être vraiment en usage dans le patois, et ne pas l’être dans la langue française représentée par l’Académie. Allez, je renonce et je vais faire autre chose. Laissons donc des mots de dialecte berrichon dans la cat:français Dhegiha (discussion) 6 mars 2013 à 08:27 (UTC)
Quand on parle de dialecte, c'est du français. Quand on parle de langue (et Wikipédia parle du berrichon comme d'une langue), ce n'est pas du français. Je veux bien que le berrichon soit une langue séparée, je ne suis pas spécialiste, et de toute façon la distinction entre dialecte et langue est assez floue. http://llmap.org/languages/fra-ber.html indique le berrichon comme un dialecte du français, effectivement avec le code fra-ber, et donc pas comme une langue séparée, ce qui justifierait sa présence dans la catégorie français, au même titre que le français québécois. C'est peut-être une discussion à avoir, est-ce qu'il faut traiter le berrichon comme une langue séparée ? Mais je redis que les exemples de l'ouvrage sont presque toujours reconnaissables comme du français, et que les mots du dictionnaire sont utilisés par des auteurs qui écrivaient en français, comme La Fontaine, si on en croit les citations. C'est ce qui me fait dire que dans l'esprit de l'auteur, c'était du français régional. Et cette impression est confirmée par la phrase tout mot qui brigue l’honneur de faire partie du glossaire doit être vraiment en usage dans le patois, et ne pas l’être dans la langue française représentée par l’Académie. Cela veut simplement dire qu'il exclut de son glossaire les mots français normaux, non spécifiques à la région. Allez donc voir les citations, et aussi les exemples inventés... Est-ce que ce n'est pas du français ? Lmaltier (discussion) 6 mars 2013 à 11:15 (UTC)
Euh, c’est quoi la différence entre dialecte du français et français régional ? (ce qui semble être le sujet de cette section alors que j’ai toujours cru que c’était des synonymes).
Après, est-ce une langue à part ou le dialecte d’une autre, je serais bien en peine de le dire. La distinction entre dialecte et langues est souvent subjective (et certains parlers sont parfois plus ou moins les deux à la fois). Pour prendre des exemples assez similaires, le picard et le normand sont deux dialectes de la « langue d’oïl » mais le premier est beaucoup plus souvent reconnu comme une langue que le second. Dans son rapport ministériel Les Langues de France, Cerquiglini ne liste pas le berrichon comme une des 75 langues parlées en France. Cdlt, VIGNERON * discut.8 mars 2013 à 18:57 (UTC)
Sauf que le Breton est une langue celtique bien à part qui n’a rien à voir avec le français. La grammaire est totalement différente et le lexique aussi, aucun liens avec les cas mentionnés ci-dessus. V!v£ l@ Rosière/Murmurer…/3 mai 2013 à 09:14 (UTC)
Cela signifie qu'il faudrait mettre une ligne d'« intro » * {{pron|pø.t‿ɛtʁ|fr}} avant de présenter les 2 fichiers audio, qui pourtant ont une prononciation différente, et donc pas définition ne reprennent pas tous deux la prononciation mise en ligne d’intro. Parfois même la prononciation n'est pas reprise .
Quelqu'un saurait-il expliquer pourquoi l'aide est faite ainsi ?
J'ajoute toujours au moins « standard » quand il y a une prononciation comme ça. Pas sûr que le « phonologie » soit utile, par contre (il fait peur). — Dakdada4 mars 2013 à 21:29 (UTC)
Quand il y a deux prononciations standards alternatives (ex: Royaume-Uni/USA → voir faulty), on met laquelle en ligne d'intro si il existe une prononciation régionale audio qui ne réalise qu'une seule des deux prononciations phonologiques standards (logique) : on reprend les deux dans la même ligne (faulty), dans deux lignes différentes (avec une sans info prononciation régionale qui en dépend), ou on reprend seule la prononciation concernée ? Automatik (discussion) 4 mars 2013 à 21:41 (UTC)
Je préfère une par ligne, c'est plus facile à discerner. Du coup la prononciation audio devient une sous-liste logique de la région concernée. — Dakdada4 mars 2013 à 21:48 (UTC)
J’en ai profité ensuite pour créer {{catlangue}} qui affiche un texte spécifiquement pour la partie -voir- des pages définissant des langues, permettant un renvoi vers la catégorie contenant les mots de la-dite langue. Voir l’exemple sur ayoreo. Ce modèle catégorise au passage dans Catégorie:Langues en français (sauf erreur de ma part dans l’écriture du modèle). Qu’en dites-vous ? Des remarques ? Eölen (discuter)4 mars 2013 à 15:53 (UTC)
OK pour moi. {{Catégorie langue}} serait plus parlant mais bon les deux sont possibles. Vu son utilisation, on peut aussi envisager de mettre le nom de la page comme paramètre par défaut (un truc du genre ] ) si ça en vaut le coup. UnsuiDiscuter5 mars 2013 à 11:17 (UTC)
Ah oui, c’est une super idée ! Je ne comprends pas très bien la syntaxe proposée mais ça marcherait pour la plupart des pages de langues, mais pas toutes, notamment parce que les langues ont souvent plusieurs noms. Si quelqu’un peut s’en occuper, pourquoi pas. Et pour le nom plus long, je comprends l’intérêt d’un modèle transparent. Ce sera un peu plus long à taper mais pourquoi pas. Eölen (discuter)5 mars 2013 à 12:18 (UTC)
Il permet d’avoir un texte affiché différent du nom de la catégorie, pour apporter une éventuelle précision (géographique, typographique, linguistique, etc.) par exemple 1 749 entrées en mongol (en cyrillique) dans le Wiktionnaire ::j’ai la flemme de chercher un exemple plus pertinent. De toute façon, ça ne gène pas de le laisser. UnsuiDiscuter6 mars 2013 à 09:46 (UTC)
Cela dit, de manière générale, qu'est-ce qui différencie ces deux espaces de noms ? Je me suis posé la question après avoir vu ces pages par exemple : Aide:Gadgets et Wiktionnaire:Gadgets (la première renvoie à la seconde pour une aide « plus technique »).
De manière générale, quels critères font qu'une page doit être dans l'espace Wiktionnaire et non Aide, et vice-versa ?
PS : J'ai consulté cette page avant de poser cette question.
Je me suis toujours demandé pourquoi de l’aide était présente dans l’espace Wiktionnaire, plutôt réservé aux prises de décision. Mais Wikipédia a le même problème (en plus d’être trop longue). JackPotte ($♠) 4 mars 2013 à 22:23 (UTC)
Il peut y avoir plusieurs niveaux d’aide sur un même sujet. J’utilise toujours Aide: pour le niveau « pour les nuls ». Pour le niveau « pour les spécialistes » (genre « comment créer un gadget »), j’avoue être plus hésitant, Wiktionnaire:, étant défini comme l’espace pour le fonctionnement interne du site, peut se défendre. --GaAs5 mars 2013 à 13:44 (UTC)
J'ai cru que c'était le contraire, quelqu'un sur Wikipédia m'avait d'ailleurs dit que l'espace Wikipédia (pour un sujet donné) va plus parler du côté philoshique de la chose (l'idée qu'il y a dedans), alors que l'espace Aide donnera une aide technique. Mais c'est vrai que rien ne semble arrêté là-dessus, cela dit, ce serait bien de tracer un chemin à suivre un jour ou l'autre. Automatik (discussion) 5 mars 2013 à 18:55 (UTC)
Barre d'outils
Dans le but d'améliorer la modification des pages, je voudrais savoir :
Utilisez-vous la barre d'outils Vector (au dessus de la zone d'édition) ?
En particulier, utilisez-vous la barre d'outils caractères spéciaux ?
Utilisez-vous les boîte à outils sous la zone de modification ?
En particulier, utilisez-vous les caractères spéciaux (menu déroulant) ?
Je me demande s'il ne serait pas plus judicieux de déplacer les outils en dessous (en les nettoyant au passage) en les intégrant proprement à la barre Vector. Il y a beaucoup de doublons, et en particulier les caractères spéciaux.
Je pense par exemple qu'on peut faire les choses suivantes :
Dans la barre Vector, ajouter un menu « Caractères courants » (différent de l'exhaustif mais lourd « Caractères spéciaux »), qui intégrerait les « caractères spéciaux » de la boîte à outils (À, apostrophe, cédilles, etc.), ainsi que les caractères API dans un ordre pertinent (ce qui n'est pas le cas dans la section « Caractères spéciaux »).
Remplacer le menu « Aide », qui ne contient pas beaucoup d'infos utiles, par des informations pertinentes sur la rédaction des articles.
Dans la même veine, on pourra ajouter les différents modèles les plus courants (les modèles de la ligne de forme, les modèles de ligne de définition, etc.).
L'interface en sera plus avenante et plus utile, et, si on la complète avec le gadget de GaAs, on devrait pouvoir grandement faciliter la rédaction des articles. — Dakdada5 mars 2013 à 14:44 (UTC)
Utilisez-vous la barre d'outils Vector (au dessus de la zone d'édition) ? Oui (en fait surtout la partie que j’ai personnalisée, avec l’API et des truc comme :{hors sujet}, voir Utilisateur:ArséniureDeGallium/vector.js).
En particulier, utilisez-vous la barre d'outils caractères spéciaux ? Non, c’est mal organisé pour y chercher.
Utilisez-vous les boîte à outils sous la zone de modification ? Très peu sauf {subst:s-ucf} et ci-dessous.
En particulier, utilisez-vous les caractères spéciaux (menu déroulant) ? Oui, mieux organisé que le truc de vector.
Pour « le gadget de GaAs », j’espère un jour pouvoir le mettre pour tout le monde par défaut, mais c’est une autre question. --GaAs5 mars 2013 à 15:23 (UTC)
Ce qui serait top méga cool, ce serait d’avoir un bouton qui ouvrirait une giga liste d’options dans laquelle on pourrait cocher juste celles qu’on veut avoir, afin que chaque utilisateur puisse personnaliser sa barre d’outils selon l’usage qu’il en fait.
Techniquement, le paramétrage pourrait être mémorisé automatiquement dans le vector.js de l’utilisateur.
Hmmm oui, c'est faisable, mais c'est encore pas mal de boulot. Par contre, si on se concentre pour avoir une interface par défaut (ne serait-ce que pour les IP ou les nouveaux utilisateurs), alors on peut se lancer sans l'aspect personnalisation. — Dakdada5 mars 2013 à 19:28 (UTC)
Si on part du principe que la 4G n’est pas très répandue et que la version mobile ne permet pas de modifier le site, je suggère d’attribuer une priorité basse à ce projet. JackPotte ($♠) 5 mars 2013 à 19:30 (UTC)
Ma proposition ci-dessus vise justement à ne pas pénaliser ceux qui n’ont pas une bonne bande passante. --GaAs5 mars 2013 à 22:56 (UTC)
Je n’utilise pas Vector car je n’y ai pas trouvé "mes" boutons (apostrophe, « ») facile d’accès. Je suis sous Monobook. Stephane8888✍6 mars 2013 à 19:33 (UTC)
@Stephane : serais-tu prêt à utiliser la barre Vector si j'y incorporais proprement ces boutons ? — Dakdada7 mars 2013 à 08:51 (UTC)
Oui, autant que j’utilise une configuration assez proche de celle par défaut (Vector donc). @GaAs : Un clic c’est rapide. Stephane8888✍7 mars 2013 à 13:37 (UTC)
Pas quand tu es en train de taper du texte au clavier, ça t’oblige à changer deux fois la position de tes mains. --GaAs7 mars 2013 à 13:56 (UTC)
Je rappelle que ce que je voudrais c'est un menu qui soit accessible même aux anonymes, donc Specialchars n'est pas applicable. Par ailleurs, j'ai rajouté un menu avec des caractères courants et les caractères API du français. Mais je me suis contenté de mettre les caractères vraiment spéciaux, donc 1) qu'on a du mal à trouver avec un clavier Windows 2) pas des caractères que personne n'utilise comme ¶. À votre avis 1) est-ce utile de mettre les lettres françaises accentuées même accessibles au clavier français normal, et 2) quels autres caractères vraiment utiles devrais-je ajouter au tableau actuel ? (Pour rappel, vous pouvez tester la barre sous Vector avec le gadget Wiktoolbar). — Dakdada7 mars 2013 à 14:44 (UTC)
Personnellement j’ai désactivé l’horreur bleu déroulant que j’exècre pour me faire une liste perso de boutons. Sinon pour les accents français ça peut être utile pour ceux qui contribueraient depuis un clavier étranger sans accents, mais bon ils sont plutôt marginaux. Mais le fait est que pour le moment il ne peuvent pas réellement contribuer, si on ajoute ces boutons alors ils le pourront, peut-être alors verrons nous apparaître ces contributeurs particuliers. V!v£ l@ Rosière/Murmurer…/7 mars 2013 à 17:03 (UTC)
Est-ce à la suite de cette discussion qu’il n’y a plus d’outils sous EditTools en mode édition ? Plus moyen de générer facilement ], {{}}, etc. Urhixidur (discussion) 6 avril 2013 à 14:07 (UTC)
Un point de traduction : actuellement, pour afficher les images en vignette on utilise « thumb ». Mais il est tout à fait possible d'utiliser « vignette » à la place. De même pour tous les autres paramètres, comme upright=redresse. Pensez-vous qu'il soit judicieux de remplacer systématiquement ces termes en leur équivalent français ? PS : en fait tous les termes anglais ont une traduction utilisable : DEFAULTSORT=CLEFDETRI etc. Voir . — Dakdada5 mars 2013 à 14:58 (UTC)
Mouaif. Pour vignette, OK, c’est compréhensible, et même certainement plus que thumb pour un non-anglophone (surtout quand notre article ne dit rien de plus que « pouce »). Mais redresse, c’est totalement incompréhensible en français, alors je suis totalement contre. --GaAs5 mars 2013 à 19:02 (UTC)
On pourrait remplacer upright par ratio, non ? Ça me paraît coller au truc et surtout c’est plus compréhensible que upright qui est tout aussi incompréhensible. V!v£ l@ Rosière/Murmurer…/7 mars 2013 à 17:06 (UTC)
Ce statut sera attribué automatiquement par moi à tout utilisateur ayant posé au moins 454 questions pertinentes et !☢♳?⚡☠ sur la Wikidémie. Il ne sera pas possible de le refuser.
Dès que qqun fera une réponse dans cette section, je ferai la demande de création du groupe sur bugzilla. Ou, d’ailleurs, même si personne ne répond.
Le statut sera attribué d’office à Automatik (d · c · b). À titre honoraire, il n’en a fait que 453.
Depuis le temps que je suis là, je dois bien avoir dépassé les 454 questions . Ah pardon, tu as dit « pertinentes » ? J'ai rien dit. — Dakdada5 mars 2013 à 19:25 (UTC)
Actuellement, l’article acrobate sort n°1 sur google.fr quand on cherche ce mot (y compris avec 2 "c", cf la pdd de l’article). En n°2, c’est le site site d’Adobe.--GaAs6 mars 2013 à 14:36 (UTC)
C’est cool, mais en même temps ce l’est moins quand on pense aux sens omis ou les articles un peu fouillions qui vont être projeté en premier résultat. Tiens je suis choquée google ne trouve aucune occurrence pour être fouillion, ce qui nous rappelle le problème de comment attester le langage oral. V!v£ l@ Rosière/Murmurer…/7 mars 2013 à 17:22 (UTC)
La 9e édition du Dictionnaire de l'Académie française semble en désaccord avec notre article ci-joint, qui indique, dans la section Adjectif, que « Ci-joint peut également avoir valeur d’adjectif quand il est placé devant un nom précédé d'un article d'un adjectif possessif, démonstratif ou numéral ».
Selon cette édition du Dictionnaire de l'AF, ci-joint serait une locution adjectivale (et non, comme indiqué sur le Wiktionnaire, un adjectif) qui s'accorderait en genre et en nombre lorsqu'elle suit le nom auquel elle se rapporte, mais resterait invariable lorsqu'elle le précède).
Ne conviendrait-il pas que notre article fasse état de ces divergences, en les sourçant (onglet « JOINT, adj. »), et source également au passage les affirmations actuelles de notre article ? Hégésippe | ±Θ± 7 mars 2013 à 18:30 (UTC) — Et merci au passage à CAO'H pour avoir très involontairement, dans une source extérieure, soulevé ce point/pinaillage intéressant . Hégésippe | ±Θ±7 mars 2013 à 18:34 (UTC)
D’après ce que j’ai pu voir, on met plutôt cette section juste après les traductions (c’est-à-dire que c’est la dernière sous-section d’une section de type de nom).
À priori dans la section Type de mot déjà ; et vu qu’un faux-ami est un mot d’une autre langue, après les traductions me semble aussi l’endroit idoine. Chris06✍10 mars 2013 à 23:25 (UTC)
Ça y est, j’ai osé, la nouvelle version est en ligne. Il y a encore des tas de problèmes, je sais en particulier, le Wiktionnaire n’a pas d’article bêta-testeur, honte à lui. Je remercie chaleureusement Xic667 de m’avoir aidé à faire en sorte qu’il n’y ait pas plus de bourdes. --GaAs8 mars 2013 à 21:57 (UTC)
Voir l’image ci-contre. --GaAs9 mars 2013 à 01:52 (UTC) NB : la page d’aide n’est pas à jour, mais je le ferai dès que je serai sûr qu’il n’y a pas besoin de tout réverter.
Question à cent sous : une fois ça un peu plus stabilisé, seriez vous favorable à ce qu’il soit activé par défaut pour tout le monde, y compris les IP ? --GaAs9 mars 2013 à 02:02 (UTC)
Oui, je pensais à ça aussi. Àma, c’est surtout une question de temps de chargement, et encore seulement de temps en temps car le navigateur garde ça en cache (j’en sais qqch). Le temps d’exécution est nul tant que tu ne cliques pas sur le bouton.
Actuellement, le programme principal fait 22639 octets, /fr.js 7062, /es.js 5753, /en.js 4275, /eo.js 3908, /it.js 6494. C’est la taille des pages éditables, mais je suppose que le code subit une minification (voir Minification (programming) sur l’encyclopédie Wikipédia (en anglais) ) avant d’être fourni aux clients par le serveur. --GaAs9 mars 2013 à 18:39 (UTC)
Je serais favorable à une activation par défaut. Chez moi, les temps de chargement sont toujours extrêmement longs, mais pas à cause du poids de la page : le coupable est le script de chargement du bandeau des annonces (siteNotice). Si je désactive javascript, le chargement est presque instantané. Autrement dit : pour améliorer le confort utilisateur, pas la peine de le priver de scripts utiles, mieux vaut optimiser (en les rendant plus « nice ») les scripts qui font des chargements externes. Ah, j’oubliais de dire : ton gadget (je suis encore sur l’ancienne version) est vraiment super. Souvent, je n’aurais pas le courage de créer les pages s’il n’était pas là. --Eiku (d) 12 mars 2013 à 16:37 (UTC)
Il me semble qu’il faudrait en parler, parce que si ce modèle n’est pas d’usage, son existence est logique si on regarde tous les modèles existant. Tellement logique que des scripts comme MediaWiki:Gadget-CreerNouveauMot.js considèrent qu’il faut mettre -loc- devant le nom d’un modèle dès que le mot comporte un espace.
Quel sens linguistique ça a ? Automatik (discussion) 9 mars 2013 à 21:07 (UTC) Après réflexion, c’était mon intervention qui n’avait pas réellement de sens. Par cohérence avec l’existant (qu’on n’a pas décidé de mettre en PàS), cette section était même justifiée àma. Automatik (discussion) 30 mai 2013 à 23:04 (UTC)
Bon, vous cassez pas, je vais ajouter les qques lignes de javascript nécessaires, j’avais juste la flemme. --GaAs9 mars 2013 à 22:28 (UTC)
Non, parce qu’on ne dit pas locution nominale propre dans la grammaire française traditionnelle. Que ce soit effectivement un nom commun ou un nom propre, on l’appelle simplement locution nominale. Voilà un résultat de Google : . — TAKASUGI Shinji (d) 10 mars 2013 à 02:03 (UTC)
Effectivement, on ne dit jamais locution nominale propre. Et, pour moi, on ne dit non plus jamais (ou presque jamais) locution nominale en parlant d'un nom propre. Je serais favorable à supprimer tous les modèles -loc- (comme sur en.wikt), mais ils sont quand même acceptables, sauf pour les noms propres à mon avis. On ne dit jamais que New York est une locution nominale. Le modèle -loc-nom-pr- existait auparavant, et a été supprimé à juste titre. Lmaltier (discussion) 12 mars 2013 à 06:59 (UTC)
Je me demande s'il ne va pas devenir impossible de faire des gadgets qui puissent être stables et utilisables pour la grande quantité des navigateurs en circulation.
Aux origines étaient Internet Explorer (Windows), puis Safari (Apple). Vinrent ensuite Firefox, Opéra, Chrome... pour les ordinateurs de bureau ou portables. Ça devenait déjà compliqué.
Maintenant les gens se sont détournés vers les mobiles (smartphone, tablettes) où l'on trouve des navigateurs attitrés en grand nombre sous iOS, sous Androïd... .
Comment pouvoir proposer à chaque internaute susceptible de devenir contributeur sur le Wiktionnaire des gadgets qui fonctionnent quel que soit le navigateur utilisé ?
Doit-on privilégier des navigateurs et lesquels ?
Ne doit-on pas informer les nouveaux contributeurs et notamment ceux qui s'inscrivent que les gadgets (comme la création d'articles) fonctionnent avec tel et tel navigateurs et pas d'autres?
À terme, si l'on multiplie les gadgets fonctionnant pour une partie seulement de la population internaute mobile ou pas, ne va-t-on pas tarir le recrutement de nouveaux contributeurs ? -- Béotien lambda☏11 mars 2013 à 10:01 (UTC)
Normalement, je teste mes bidules sur IE8 et 9, FF, Opera et Chrome dernières versions. Sur PC Windows seulement, je n’ai pas de Mac, ni de tablette, ni de smartphone. --GaAs11 mars 2013 à 10:39 (UTC)
D’ailleurs, même si ça fonctionne, Gadget-CreerNouveauMot sur un écran de smartphone, ça doit être très difficile à utiliser. Àma il en faudrait une version spéciale, avec bcp plus d’onglets chacun bcp plus petit. Le gestionnaire de gadget sait-il fournir 2 versions d’un même gadget selon qu’on passe par le site mobile ou par le site standard ? Ou peut-on réaliser ce comportement dans le javascript ? --GaAs11 mars 2013 à 10:51 (UTC)
La version mobile ne permet toujours pas de modifier le site . Je peux tester la version normale sur mobile, mais parfois on ne voit pas ce qu'on écrit, je vous ferai un screenshot à l’occasion. JackPotte ($♠) 11 mars 2013 à 11:45 (UTC)
Sur mon téléphone (sous Bada, avec Dolphin), la taille des zones de saisie est limitée à un peu moins de 32 Ko : au delà, ça tronque (c’est un peu embêtant parce que ça prévient pas et c’est pas documenté du tout, je m’en suis aperçu par l’expérience). Mais patience, je suis sûr que dans pas trop longtemps, on pourra faire des modifs presque confortablement avec un mobile correct. --Eiku (d) 11 mars 2013 à 21:09 (UTC)
Réduction (drastique) de la liste des gadgets
Selon moi, la liste des gadgets a depuis longtemps dépassé la longueur où un utilisateur normalement constitué lit la page jusqu’au bout. Je propose donc de virer des gadgets tous ceux qui ne sont destinés qu’à 2 ou 3 utilisateurs qui ont créé le gadget juste pour eux, genre (au hasard) Interwikis en français, Afficher l'ancre du titre, ou encore Flèche vers le haut , etc.
En l’absence de protestations véhémentes, je me propose de faire un gros ménage là-dedans. Bien évidemment, je ne supprimerai aucune des pages de javascript concernées, je vais juste les faire disparaitre de ce qui est proposé dans les préférences.
Si il y a un moyen de reprendre les codes dans notre common.js, je veux bien. Ça permettra de mettre en valeur le travail réalisé pour créer ces gadgets si quelques rares utilisateurs les utilisent plutôt qu'aucun. En fait je dis ça, mais je ne t'en voudrais évidemment pas si tu n'expliques pas comment les réutiliser. Ils sont peu utiles et il vaut mieux déjà penser au peuple en lui offrant une interface claire. Automatik (discussion) 11 mars 2013 à 21:57 (UTC)
Je ne suis pas très chaud (même très froid) pour cela : il ne faut pas augmenter le temps de chargement des pages du Wiktionnaire. D’ailleurs, j’envisage aussi un gros ménage sur Mediawiki:Common.js (mais plus tard). --GaAs11 mars 2013 à 22:28 (UTC)
Perso, j’utilise beaucoup la Flèche vers le haut mais si je peux la reprendre dans mon common.js, il n’y a pas de problème. UnsuiDiscuter11 mars 2013 à 22:40 (UTC)
Ce ne serait pas des gadgets du coup, donc ça ne servirait à rien. Je vais me répéter : la meilleur solution c'est d'améliorer la mise en page, pas d'enlever les outils qui « prennent de la place ». — Dakdada12 mars 2013 à 14:11 (UTC)
Dans le glossaire grammatical, il est dit qu'un mot est invariable s'il ne se met ni au pluriel ni au féminin ou si son orthographe est toujours la même. Cependant, dans la documentation du modèle {{invariable}}, il est dit qu'un mot est invariable s'il ne varie jamais en genre ni en nombre.
Donc gaz est grammaticalement parlant invariable selon la première définition, mais ne l'est pas selon la deuxième (le mot varie en nombre : un gaz, des gaz).
Quelle définition suivre ? essayez de ne pas trop vous faire influencer par l'exemple, il est juste là pour clarifier mon propos, mais ma question est générale Automatik (discussion) 12 mars 2013 à 00:45 (UTC)
Quand on dit qu'un mot est invariable, ça veut dire que sa forme écrite est invariable. C'est logique : c'est en général la forme écrite, et uniquement la forme écrite, qui varie quand on met un mot au féminin ou au pluriel. Le mot varier ne peut vouloir dire que ça dans ce cas, car rien d'autre ne varie (certes, il peut éventuellement servir aussi pour dire que la prononciation varie, mais on n'utilise clairement pas invariable pour dire que la prononciation ne change pas). D'où le mot invariable : in- + varier + -able : qui ne peut pas varier. C'est comme ça qu'il faut comprendre qu'un mot invariable ne varie jamais en genre ni en nombre : ça veut dire que sa forme ne varie pas quand il change d'utilisation du point de vue genre ou nombre (mais c'est vrai que ce n'est pas très clair, et que la formulation est à améliorer). Lmaltier (discussion) 12 mars 2013 à 06:54 (UTC)
Il me semble que le problème vient du fait que le Wiktionnaire souhaite distinguer les causes « grammaticales » d’invariabilité (numéral, nom propre, etc., voir banque de dépannage linguistique) des causes purement orthographiques ou incluant d’autres considérations d’usage (mots se terminant en s, x, z ayant leur singulier et pluriel identiques, certains mots se terminant en e ou avec certaines particularités ayant leur masculin et féminin identiques), avec les mentions singulier et pluriel identiques et masculin et féminin identiques. Ceci semble défendable, puisque la cause orthographique joue soit sur le genre, soit sur le nombre, et n’est donc pas en soi une « véritable » cause d’invariabilité (gaz n’est que masculin, donc l’invariabilité en nombre due à l’orthographe implique de fait l’invariabilité totale). Maintenant, on ne peut nier que gaz est invariable… Les dictionnaires usuels le notent d’ailleurs ainsi. Donc la définition du glossaire grammatical est juste, et il faudrait peut-être un peu clarifier la documentation du modèle {{invariable}} pour être plus clair sur les conditions d’utilisation (restreintes à une cause grammaticale), car la fin de phrase « qui ne varient donc ni en nombre ni en genre » me semble-t-il sème le doute. Chris06✍12 mars 2013 à 13:36 (UTC)
Tu as raison. Nous utilisons, sans règle explicitement écrite, {{sp}} pour les mots se terminant en s, x ou z, {{mf}} pour les mots se terminant en e et {{invar}} pour les autres mots invariables comme les sigles et certains noms de couleur. — TAKASUGI Shinji (d) 13 mars 2013 à 00:43 (UTC)
Oui, ce sont des modèles qui n'ont rien à voir avec le sens du modèle invar, on ne peut pas les comparer. On peut utiliser les modèles mf et invar ensemble, ou les modèles sp et invar ensemble. Lmaltier (discussion) 13 mars 2013 à 21:20 (UTC)
Invariable implique singulier et pluriel identiques (et masculin et féminin identiques), disons donc qu’ils ont « à moitié à voir ». Tant et si bien que l’utilisation conjointe de {{invariable}} et {{sp}} (ou {{mf}}) est redondante, donc à mon avis à proscrire. Toute la question ici étant de savoir comment on lève la redondance, soit en indiquant uniquement {{sp}} (cause orthographique — gaz, sens, index, etc.) ou bien {{invariable}} (cause grammaticale — pater, marron, BD, pourquoi, ré, sept, etc.). Cliquer sur ces mots donne une bonne indication que c’est bien la façon de faire dans le Wiktionnaire. Chris06✍14 mars 2013 à 13:55 (UTC)
Indiquer {{sp}} pour gaz est bien plus informatif, puisque ça fait apparaitre qu’il y a bien un singulier et un pluriel (accidentellement écrits pareils), contrairement à pourquoi qui n’a ni l’un ni l’autre. --GaAs14 mars 2013 à 15:58 (UTC)
Non, invariable n'implique pas singulier et pluriel identiques (les adverbes sont invariables, par exemple). Cela veut uniquement dire que la forme du mot ne change jamais. Un nom peut être invariable parce qu'il ne peut pas être utilisé au pluriel, auquel cas il ne faut pas mettre sp, ou parce que le pluriel est identique au singulier, auquel cas on peut mettre sp. Il n'y a pas redondance. Lmaltier (discussion) 22 mars 2013 à 21:50 (UTC)
« Un nom peut être invariable parce qu'il ne peut pas être utilisé au pluriel » : quel nom (ou même adjectif) n’est pas utilisable au pluriel ? Tous ceux que je cite et qui sont reconnus invariables sont justement utilisables au pluriel, comme tous (ou quasiment, peut-être existe-t-il des cas particuliers) les noms ou adjectifs : des pater, des pantalons marron, des BD, des pourquoi et des comment, des ré dièses, il y a deux sept dans soixante-dix-sept, il n’y a pas deux France, etc. Je ne comprends pas ce que tu veux dire. Si on te suit, il n'y a plus rien d'invariable, hors les adverbes. Chris06✍23 mars 2013 à 23:13 (UTC)
Wikidata
Bonjour, comme vous le savez peut-être Wikidata a achevé sa première phase, à savoir la gestion des liens interwikis pour les articles Wikipédia. Une discussion a été entamée concernant l’apport de Wikidata aux Wiktionnaires. Ce n’est pas pour tout de suite mais plus tôt la communauté des Wiktionnaire sera tombée d’accord, plus tôt on pourra profiter de Wikidata. Vous êtes donc invité à donner votre avis ici (en anglais) et la page de discussion associée. Pamputt12 mars 2013 à 16:33 (UTC)
En fait si on pouvait avoir nous aussi une première phase de liens interlangues, ce serait déjà bien, car ce n'est franchement pas compliqué à faire. Le reste est beaucoup plus spéculatif. — Dakdada12 mars 2013 à 18:38 (UTC)
J'ai pu entendre que si le but était juste de lier des pages aux noms strictement identiques entre eux, il n'était pas nécessaire d'utiliser Wikidata pour cela. Apparemment la discussion sert à voir ce qu'il vaut mieux faire par rapport à ça aussi. Automatik (discussion) 12 mars 2013 à 18:50 (UTC)
Même si les pages sont identiques (ce qui n'est pas exactement le cas, par exemple à cause de l'apostrophe typographique), il faut que l'on sache de manière centralisée dans quels Wiktionnaires la page existe, donc Wikidata sera bien utile pour ça. Du coup, plus besoin de liens interlangues, ni des bots associés ! — Dakdada12 mars 2013 à 19:06 (UTC)
Tout à fait d’accord avec Dakdada. C’est facile à faire et c’est d’ailleurs pour ça que Wikipédia a commencé avec ça. Pamputt12 mars 2013 à 19:09 (UTC)
Personnellement je modifie fréquemment des liens interwiki pour le problème d’apostrophe sur le Wiktionnaire et aussi je copie fréquemment des liens interwiki sur le Wikipédia pour importer des traductions. Il est devenu difficle pour le faire sur le Wikipédia anglais à cause de Wikidata. Je voudrais maintenir des liens interwiki plutôt comme des textes simples dans une page. — TAKASUGI Shinji (d) 13 mars 2013 à 00:52 (UTC)
La phase 1 (lien interwiki) sera déjà un gros progrès.
Pour les phases suivantes (la phase 2 concernant plutôt les infoboxes, cela ne nous concerne a priori pas), il y a aurait des milliers de trucs à faire. Je jette une idée en l’air (qui a ma connaissance n’a pas été évoquée) : pour les citations et plus particulièrement les sources des citations, cela vous semblerait-il une bonne idée de mettre du Wikidata dedans (liens vers Wikipédia pour les auteurs, liens vers Wikisource pour l’ouvrage, etc. voir même si c’est possible, reprendre toute la citation automatiquement sur les Wikisources, un peu dans l’esprit de l’outil concordance du CNRTL : eg. dictionnaire mais avec le style de nos citations). Cdlt, VIGNERON * discut.13 mars 2013 à 10:24 (UTC)
J’ai jeté un oeil à la manière de gérer les liens interwiki et ça me semble très positif, la manière dont ça apparaît maintenant sur Wikipédia est un net progrès. Vivement que ce soit fait également pour les Wiktionnaires. Ce pourrait être une étape vers la fusion des Wiktionnaires (projet OmegaWiktionary). Eölen (discuter)13 mars 2013 à 14:14 (UTC)
C’est en effet très compliqué ! Si j’ai bien compris, la proposition Adopt OmegaWiki vise à intégrer OmegaWiki aux projets Wikimedia pour en faire une sorte de Wikidata orientée vers les définitions de mots, traductions et champs sémantiques. Dans cette logique, il pourrait absorber Wikispecies, ce qui ravirait sans doute notre collaborateur du midi. Je vois cependant pas mal de problèmes à tout ça ! Que ce soit Wikidata ou Omegawiki, le but est d’avoir un pivot central et d’organiser les mots dans les langues autour de ce pivot. Sauf qu’on ne parle pas de lieux, personnes ou choses réelles mais de concepts, donc je ne vois pas comment ça peut marcher. Un exemple simple : mind et spirit en anglais correspondent à esprit en français, sauf qu’il y a des traits sémantiques différents, et que les sens peuvent évoluer avec le temps (concept de valeur linguistique de Saussure). Donc…j’vois pas comment on peut faire fonctionner un étoilage sémantique…Et j’vois pas trop comment le Wiktionnaire français va évoluer au milieu de tout ça. Eölen (discuter)13 mars 2013 à 18:35 (UTC)
Le promoteur d'OmegaWiki parle même dans ses commentaires d'une tentative d'unifier les forces, ce qui est très très mauvais signe. OmlegaWiki est un échec total, et il y a de vraies raisons à ça (j'avais d'ailleurs essayé de soulever le problème chez eux, mais sans succès), alors que les wiktionnaires sont une réussite extraordinaire. Ne nous suicidons pas, tirons plutôt les leçons de l'échec d'OmegaWiki, par exemple le fait que c'est un projet qui exclut de fait les non-anglophones, et le fait que les tentatives d'éviter la duplication conduit à quelque chose d'absolument incompréhensible pour les lecteurs et les contributeurs potentiels, ce qui explique qu'il n'a quasiment aucun lecteur et aucun contributeur. Lmaltier (discussion) 13 mars 2013 à 21:09 (UTC)
Pour ce qui est de Wikidata, pas de problème si ça peut aider pour les liens interwikis. Mais Wikidata sera un projet monolingue, forcément, et si on déportait une partie des wiktionnaires sur Wikidata, ça risquerait de faire encore plus fuir certains contributeurs (au moins les non-anglophones, et sans doute d'autres). On n'en a déjà pas trop, des contributeurs... Ce serait courir un risque énorme, le risque qu'il nous arrive peu à peu ce qui est arrivé à OmegaWiki. Je suis pour éventuellement migrer sur Wikidata uniquement ce qui ne peut nécessiter aucune discussion de nature linguistique, et je ne vois pas bien ce qu'il y aurait, à part des choses réalisables automatiquement (et encore). Lmaltier (discussion) 13 mars 2013 à 21:15 (UTC)
Non Wikidata n’est pas monolingue (en tout cas je ne l’ai pas ressenti comme tel pour ce que j’y ai fait). Chacun peut contribuer dans son langue de manière presque transparente. En ce qui concerne l’apport de Wikidata aux Wiktionnaires, je pense qu’on est tous d’accord pour que la gestion des liens interwikis. Plus besoin de bots et la mise à disposition est beaucoup plus rapide. Au-delà, on pourrait recenser toutes les angrammes là-bas. Ça serait calculer par un robot une bonne fois pour toute et tous les Wiktionnaires pourraient en profiter. Je pense également qu’on pourrait lui faire gérer les prononciations comme c’est actuellement discuté là-bas. On ajoute la prononciation API du mot dans chaque langue où il existe et c’est automatiquement disponible pour tous les Wiktionnaires (on peut également ajouter des liens vers des prononciations audio sur Commons). Il y a cependant le problèmes des homographes non homophones. Pour les traductions ça se complique un peu plus mais je pense qu’on peut arriver à en tirer du positif également si c’est bien pensé à la base. Et ça se discute en ce moment. Pamputt13 mars 2013 à 21:33 (UTC)
C'est-à-dire ? Il est prévu en.wikidata.org, fr.wikidata.org, etc. ? Je ne comprends pas comment cela est possible si on veut une base de données unique, ce qui est le but du projet. Quand une discussion sur le projet Wikidata est en anglais (ou en wolof, japonais, ou une autre langue), et qu'on ne peut pas lire la langue de cette discussion, on en est forcément exclu. Il faut bien un endroit central pour prendre les décisions, non ? Donc dans une langue déterminée ? Un exemple : supposons qu'il est pris la décision de faire les anagrammes automatiquement sur Wikidata, que c'est implémenté, et que je veux juste faire remarquer qu'il ne faut pas tenir compte des affixes comme ça a été fait par erreur, et que je m'exprime en zazaki du Sud. Qui comprendra ma remarque, qui tiendra compte de ma remarque ? Un autre exemple de discussion possible : les langues à prendre en compte. en.wikt exclut certaines langues qui ont pourtant un code ISO, et je juge ça inacceptable. Il ne faudrait pas que l'existence de Wikidata nous oblige à appliquer des choix inacceptables. Ou encore une prononciation sur laquelle on n'est pas d'accord ? Comment le signaler, en quelle langue ? Et les prononciations nécessitent parfois une note explicative, à rédiger dans une langue donnée... Ce genre de discussion, on ne peut guère le faire que dans sa propre langue si on veut être convaincant. Tu dis que ça se discute en ce moment. Dans quelles langues ça se discute ? Je rappelle que les traductions de langue à langue ne sont en aucun cas une relation transitive, et que chaque couple de langues doit donc être traité de façon indépendante. Est-ce que quelqu'un l'a rappelé sur Wikidata comme je le rappelle ici ? Et si oui, dans quelles langues est-ce que ça a été rappelé ? Lmaltier (discussion) 13 mars 2013 à 22:08 (UTC)
Je parlais plutôt de l’utilisation du côté de l’utilisateur (pas du décideur). Cela dit, je suis entièrement d’accord avec toi que la nécessité de maitriser correctement une langue non maternelle pour prendre part aux décisions est un vrai problème. Il existe bien un bistro sur Wikidata mais c’est loin d’être suffisant. Pamputt15 mars 2013 à 20:24 (UTC)
Il y a toujours des relayeurs pour faire passer un message en anglais à l’ensemble de la communauté. Sauf en zazaoui du Sud, effectivement. (Mais ont-ils un wiki ?) Automatik (discussion) 16 mars 2013 à 19:30 (UTC)
Pour les traductions ça pourrait être utile pour les traductions de choses explicites et qui on peut de chance d’avoir de nuance (ex : voiture) par contre pour les mots plus abstraits ou figurés effectivement (ex : esprit), c’est plus problématique. V!v£ l@ Rosière/Murmurer…/24 mars 2013 à 14:48 (UTC)
Suite à une rupture de caténaire à Châtelet-les-Halles, cette section sera fortement perturbée pendant le reste de la semaine
Lorsque je l’ai créé, j’avais déjà l’intention de faire cela. J’y ai fait un peu de ménage avant. Les limitations en nombre de requêtes ne s’appliquent désormais qu’aux IP (enfin presque, vous n’avez droit qu’à 25000 requêtes).
Normalement, il est désormais activé par défaut, donc aussi pour les IP. C’est ce que je veux faire. Mais je ne suis pas sûr que ça marche (vous savez, les problèmes de cache…). --GaAs12 mars 2013 à 19:39 (UTC)
Je ne comprends pas du tout : qu'est-ce que c'est censé changer du point de vue interface ? C'est censé rajouter quelque chose quelque part ? Quoi ? Lmaltier (discussion) 13 mars 2013 à 21:30 (UTC)
Coquille
Le site Larousse.fr possède, peu après les articles vérifier et vérifieur, l’article vérine qui aurait grand besoin d’être vérifié. Pour ceux qui auraient la flemme de chercher la coquille : voir ici pour la solution.
Ne perdons pas de vue qu’« Un livre sans faute est une chimère » — (Georges-Adrien Crapelet).
Une page rassemblant ce genre de coquilles et erreurs d’ouvrages concurrents serait-elle utile sur Wiktionnaire ?
Oui, nous au moins, tout le monde le sait. Mais ne nous faut-il pas signaler ces coquilles à nos lecteurs, à nos contributeurs, à nos concurrents et à nos détracteurs ? Stephane8888✍12 mars 2013 à 21:55 (UTC)
Je pense en effet que ça peut avoir un intérêt. Reste à trouver la forme la plus adéquate (catégorie, annexe, …). Je pense qu’une annexe pourrait permettre cela. Pamputt13 mars 2013 à 14:52 (UTC)
Ça m’a l’air surtout d’être une manière de dire : « nous on l’a et pas eux » (enfin j’ai peut-être tort…), et je ne pense pas que ce soit dans l’esprit du projet ; à cela s’ajoute le fait, bien sûr, que chaque dictionnaire a sa particularité, et que si on opte pour une banque de mots gigantesque, les autres dictionnaires optent pour d’autres manière d’appréhender le contenu qu’ils offrent (soucis de synthétisation notamment), d’où le fait que je pense qu’il n’y a pas de comparaison possible. Automatik (discussion) 8 avril 2013 à 16:46 (UTC)
Bonjour à tous. Je suis actuellement « Wikimédien en résidence » à Doual'art (centre d'art contemporain de Douala, Cameroun) dans le cadre du projet WikiAfrica qui vise à accroître les contenus relatifs à l'Afrique sur les projets Wikimédia. Aujourd'hui, j'anime une formation sur le Wiktionnaire avec deux camerounais francophones et une anglophone qui contribuent sur des mots de leurs dialectes. Certains ont déjà commencé à les aider, n'hésitez pas à faire pareil ;-) (l'accueil ici est quand même nettement plus sympathique que chez vos voisins anglophones). Guillaume WA (discussion) 13 mars 2013 à 11:05 (UTC)
Bonjour, si besoin je serai sur WT:IRC aujourd'hui donc si vous avez des questions, n'hésitez pas. La richesse linguistique des pays d'Afrique est sous-représentée sur nos projets, ce genre d'initiative est donc fort bienvenu ! — Dakdada13 mars 2013 à 12:35 (UTC)
Salut, bravo pour votre initiative et merci d’avance pour les contributions au wiktionnaire. Bienvenue en tout cas. --145.226.30.4313 mars 2013 à 14:43 (UTC)
Bonjour, quel est l’intérêt de la catégorie Traductions en anglais simple ? Vu qu’on a déjà « Traductions en anglais », ça n’a absolument pas d’intérêt. Vous êtes d’accord ? La question plus général est de savoir ce qu’on fait du code wikimedia « simple ». Amha, il existe une WP dans un anglais simple, un wiktionnaire également mais ce n’est absolument pas une langue différente de l’anglais et ça n’a donc pas sa place ici. Pamputt13 mars 2013 à 13:31 (UTC)
Oui, je ne suis pas sûr que ce soit une langue malgré que Wikimedia ait décidé d'utiliser le code simple pour sa version en simple English. Automatik (discussion) 13 mars 2013 à 14:10 (UTC)
Question pertinente, car il y a eut plusieurs tentatives de simplifications de l'anglais. Et si on veut vraiment indiquer ces mots là dans le Wiktionnaire, il leur faudra un code en propre, et pas simple, qui ne renvoie pas à une langue en particulier mais à un style rédactionnel particulier, qui est celui que nous tâchons d’avoir dans le wiktionnaire de toute façon. Eölen (discuter)13 mars 2013 à 14:21 (UTC)
Pour répondre à Automatik, d’après se que j’ai compris la Wikipédia et le Wiktionnaire en « anglais simple » (code « simple ») permette d’écrire un anglais « de base ». Seul quelques centaines de mots sont utilisés pour tout décrire. plus d'info sur Anglais basic. Pamputt13 mars 2013 à 14:46 (UTC)
Oui, ce projet est destiné aux lecteurs qui n'ont pas de wiktionnaire dans leur langue (ou seulement un wiktionnaire rudimentaire) et parlent un peu anglais, mais mal. Ils n'ont jamais prétendu écrire dans une langue autre que l'anglais. La catégorie citée n'a donc aucun intérêt. Lmaltier (discussion) 13 mars 2013 à 20:58 (UTC)
Ok, je viens de supprimer les 6 traductions dans « cette langue » et supprimer cette catégorie par la même occasion. Pamputt13 mars 2013 à 21:08 (UTC)
Convert complex templates to Lua to make them faster and more powerful
(Please consider translating this message for the benefit of your fellow Wikimedians)
Greetings. As you might have seen on the Wikimedia tech blog or the tech ambassadors list, a new functionality called "Lua" is being enabled on all Wikimedia sites today. Lua is a scripting language that enables you to write faster and more powerful MediaWiki templates.
If you have questions about how to convert existing templates to Lua (or how to create new ones), we'll be holding two support sessions on IRC next week: one on Wednesday (for Oceania, Asia & America) and one on Friday (for Europe, Africa & America); see m:IRC office hours for the details. If you can't make it, you can also get help at mw:Talk:Lua scripting.
If you'd like to learn about this kind of events earlier in advance, consider becoming a Tech ambassador by subscribing to the mailing list. You will also be able to help your fellow Wikimedians have a voice in technical discussions and be notified of important decisions.
Salutations. Comme vous avez pu le voir sur le blog de Wikimedia tech, ou dans cette annonce des informaticiens techniques de Wikimedia, a nouvelle fonctionnalité appelée « Lua » est en train d'être installée sur tous les sites appartenant à la fondation Wikimedia aujourd'hui même. Lua est un langage de programmation dont la puissance expressive est bien plus forte que celle des modèles Mediawiki.
Si vous avez des questions sur la façon de convertir des modèles existants en Lua (ou comment en créer de nouveaux), nous nous tiendrons à votre écoute sur IRC la semaine prochaine : le mercredi (pour l'Océanie, l'Asie et l'Amérique) et le vendredi (pour l'Europe, l'Afrique et l'Amérique) ; voir m:IRC office hours pour plus de détails. Si ces horaires ne vous conviennent pas, vous pouvez aussi obtenir de l'aide sur : mw:Talk:Lua scripting.
Si vous voulez être prévenu de ce type d'évènements en avance, vous pouvez devenir un « Tech ambassador » en souscrivant à cette liste de diffusion. Vous aurez aussi la possibilité d'aider vos pairs wikimédiens à faire valoir leur voix dans les discussions techniques et serez notifiés des décisions importantes.
Traduit par un noob, ce message est susceptible d'être modifié dans le quart d'heure qui suit sa diffusion. Vous y êtes d'ailleurs cordialement invités à le faire.Automatik (discussion) 14 mars 2013 à 01:42 (UTC)
Bravo pour ton enthousiasme, mais je suis surpris que les numéros de sections similaires (num=) ne soient pas dynamiques. N’y a-t-il pas un moyen de la même façon que tu détectes le titre (mw.title.getCurrentTitle()), de retrouver les modules ou titres de sections précédents ? JackPotte ($♠) 13 mars 2013 à 21:08 (UTC)
Hélas non : les appels de modèles restent indépendants les uns les autres. Sinon on pourrait même faire ça avec les codes langues. — Dakdada13 mars 2013 à 21:15 (UTC)
Je suis tout à fait d'accord que c'est pas possible, mais ça laisse quand même des interrogations. Si on peut récupérer le titre (qui est une section de niveau 1), il devrait être à priori possible de récupérer aussi les sections de niveau 2, 3, etc. Mais enfin, c'est un raisonnement de novice, je reconnais. Automatik (discussion) 14 mars 2013 à 01:48 (UTC)
Le titre n'est pas une section de niveau 1 : c'est une propriété de la page qui ne fait pas partie du contenu (au même titre que l'espace de nommage, l'url complet etc.). À partir du moment où ce qu'on veut regarder est dans le contenu de la page, alors ce n'est pas possible. — Dakdada14 mars 2013 à 14:02 (UTC)
À propos, existe-t-il quelque part une page avec des modèles traditionnels et leur équivalent lua en vis-à-vis ? Ça pourrait être utile à tous ceux qui, comme moi, ont des notions de lua et souhaitent se faire une idée de la façon dont on crée / modifie des modèles sans y investir non plus trop de temps (étant donné qu’il est probable que je ne m’en serve jamais, tout comme je n’ai jamais osé apprendre à faire des modèles traditionnels ici). --Eiku (d) 15 mars 2013 à 17:17 (UTC)
A force de me référer au TLFi j’ai fini par plus ou moins décrypter ses abréviations. Mais je butte sur celle-ci : Fréq. abs. litt. avec un chiffre ensuite. Qu’est-ce que cela veut dire ? --Lyokoï (discussion) 13 mars 2013 à 22:49 (UTC)
You’ll find this useful for performing more complex tasks for which
templates are too complex or slow *—* common examples include numeric
computations, string manipulation and parsing, and decision trees. Even if
you don’t write templates, you’ll enjoy seeing pages load faster and with
more interesting ways to present information.
Background
MediaWiki developers introduced templates and parser
functions<https://www.mediawiki.orghttps://dictious.com/fr/Extension:ParserFunctions>years
ago to allow end-users of MediaWiki to replicate content easily and
build tools using basic logic. Along the way, we found that we were turning
wikitext into a limited programming language. Complex templates have caused
performance issues and bottlenecks, and it’s difficult for users to write
and understand templates. Therefore, the Lua scripting
project<https://www.mediawiki.orghttps://dictious.com/fr/Lua_scripting>aims to make it
possible for MediaWiki end-users to use a proper scripting
language that will be more powerful and efficient than ad-hoc, parser
functions-based logic. The example of Lua’s use in World of
Warcraft<http://www.wowwiki.com/Lua>is promising; even novices with no
programming experience have been able to
make large changes to their graphical experiences by quickly learning some
Lua.
Lua on your wiki
As of March 13th, you’ll be able to use Lua on your home wiki (if it’s not
already enabled). Lua code can be embedded into wiki templates by employing
the {{#invoke:}} parser function provided by the Scribunto MediaWiki
extension. The Lua source code is stored in pages called modules (e.g.,
Module:Bananas <https://en.wikipedia.orghttps://dictious.com/fr/Module:Bananas>). These
individual modules are then invoked on template pages. The example:
Template:Lua
hello world <https://en.wikipedia.orghttps://dictious.com/fr/Template:Lua_hello_world> uses
the code {{#invoke:Bananas|hello}} to print the text “Hello, world!”. So,
if you start seeing edits in the Module namespace, that’s what’s going on.
Getting started
To help you preview and test a converted template, try
Special:TemplateSandbox<https://www.mediawiki.orghttps://dictious.com/fr/Special:TemplateSandbox>on
your wiki. With it, you can preview a page using sandboxed versions of
templates and modules, allowing for easy testing before you make the
sandbox code live.
Je suis en plein chantier de Lua (cf WT:Questions techniques), et je m'attaque au problème des langues. Actuellement on a un modèle pour chaque langue ne comportant que son nom (et nommé avec son code). On en a donc des centaines, et c'est terriblement inefficace.
Avec Lua on peut mettre ces données de correspondance code -> langue dans une seule page (deux modules au total). Voir une première ébauche : Module:langues. Il est même possible d'utiliser la liste de noms de langues de Wikimédia, donc au final on n'aura qu'à lister les langues dont le nom ou le code diffère de celle de Wikimédia (ou qui n'y sont pas). Vous pouvez tester le module ici.
Cela permettra un gain de performance considérable, outre les petits avantages, dont le nettoyage de la liste des modèles sous les articles (1 modèle par langue, ça prend de la place quand il y a plein de traductions : ), et bien sûr l'utilisation aisée et propre des codes langues dans tous les modèles et modules. — Dakdada14 mars 2013 à 18:08 (UTC)
Pour être clair, le code tel qu'on l'écrit dans les articles ne changera pas (sauf si on veut simplifier certaines choses, comme par exemple faire les translittération automatiquement). — Dakdada14 mars 2013 à 20:26 (UTC)
Le Module:langues est désormais prêt à être utilisé dans les modules. Toutes les langues actuelles (=celles qui ont un modèle) sont désormais dans le tableau Module:langues/data. La fonction de base "get_nom" de ce module peut désormais être utilisée dans tout module qui le nécessiterait. Vous pouvez tester la récupération des noms de langue avec {{#invoke:langues|nom_langue|hbo}} ce qui donne « hébreu ancien ».
Je précise que j'ai protégé (contributeurs confirmés) les deux modules sus-cités (Module:langues) et Module:langues/data), pour éviter que n'importe qui puisse les modifier. Quand on aura décidé de les utiliser réellement dans les articles, il faudra probablement les protéger au niveau maximum (administrateur).
Le module pourra évoluer si on ajoute des données particulières aux langues, par exemple si on veut indiquer quels codes ne doivent pas être utilisés.
Ce serait bien également de rajouter le plus de langues possibles d'un coup le plus tôt possible, pour éviter d'avoir à retoucher la table trop souvent par la suite. — Dakdada19 mars 2013 à 22:48 (UTC)
J’ai réouvert ce vote que j’avais fermé faute de combattants il y a un mois, après 4 semaines et deux votes, mais pour pouvoir conclure il faudrait qu’il y ait plus de deux votants cette fois-ci. --GaAs15 mars 2013 à 12:48 (UTC)
Voulant vérifier le sens de compromis comme « mis en péril », « fichu » (du genre « avec la voiture en panne, ça me semble compromis »), je suis tombé dans la partie adjectif sur la seule signification « embarrassé dans des démêlés, dans des affaires ». Ça m'a étonné, j'ai même envisagé d'ajouter le sens que je cherchais, et j'ai mis un certain temps à me rendre compte qu'il se trouvait en fait en-dessous, dans « Forme de verbe », comme participe passé du verbe compromettre dont l'un des sens était celui que je cherchais.
Donc dans un premier temps je voulais juste souligner, à toutes fins utiles, que du point de vue de l'utilisateur ce n'est pas forcément évident de trouver ce qu'on cherche quand on s'intéresse à un mot qui est un participe passé mais qu'au premier abord on considère comme un adjectif (ce qui me semble être un schéma assez courant). Mais bon je ne sais pas forcément s'il vaudrait mieux dupliquer dans la partie adjectif la signification de participe passé... donc c'est juste une remarque comme ça.
Mais ensuite, je constate que la signification comme adjectif de compromis n'est finalement rien d'autre que le participe passé de compromettre au sens 1 (« exposer quelqu’un à se trouver dans quelque embarras en l’engageant dans des démêlés, dans des affaires »). D'où finalement ma question : qu'est-ce qu'on fait normalement dans ce cas ? Est-ce que la signification de compromis comme adjectif fait doublon avec le fait que ce soit un participe passé, et devrait être retirée, ou bien est-ce que c'est valable mais finalement ça pourrait aussi être le cas dans la signification que je recherchais à la base ?
La frontière est parfois floue entre les différents types de mot et leur utilisation (par exemple on utilise parfois les noms comme épithètes, sans pour autant que ça en fasse des adjectifs). De manière générale, si un sens peut s'utiliser couramment comme un adjectif, alors le plus simple est de l'ajouter à la section d'adjectif, sachant que la section sur le participe passé décrit une forme et non une définition. — Dakdada15 mars 2013 à 16:08 (UTC)
Si on trouve un exemple d’usage où ce n’est clairement pas une construction verbale, il ne faut pas hésiter.
Une question se pose dès lors : quand peut-on dire que l'entreprise est dans une situation irrémédiablement compromise ?
Pas évident d’en trouver dans des vraies phrases, mais ça se trouve particulièrement dans la finance. Je trouve par exemple garanties compromises nettes/brutes, dont le sens m’échappe.
C'est assez simple, même s'il y a des cas où on ne peut pas trancher en lisant une phrase : quand on pense à l'action du verbe en disant la phrase, c'est une forme verbale, quand on ne pense pas à l'action du verbe mais plutôt au résultat de cette action indépendamment de l'action du verbe (par exemple, sucré dans On m'a proposé du café sucré.), c'est un adjectif. Lmaltier (discussion) 15 mars 2013 à 17:43 (UTC)
Bonjour, certains d’entre vous ont peut-être déjà circuler sur ma page de traductions de « eau » (ne serait-ce que parce que certains m’aident à la remplir ). Pour le moment, je la laisse chez moi le temps que je vérifie l’ensemble des traductions que j’ai récupéré de en.wikt. Bref, le problème n’est pas là. Pour le voir, il faut que vous vous rendiez sur la page (attention ça peut être relativement long, le temps de charger les 110 ko). Lorsque vous y êtes, si vous descendez tout en bas (à partir de la lettre « V »), les traductions ne sont plus affichées mais on a à la place un « trad » et plus j’ajoute de traductions et plus ce problème « remonte ». Qu’est ce qui se passe ? C’est le serveur qui n’arrive pas à gérer l’appel à autant de modèles ? Comment corriger/contourner ce problème ? Je préfère en parler maintenant car le jour où je balancerai tout dans l’article eau, le problème risque d’être encore plus gros. Pamputt15 mars 2013 à 20:15 (UTC)
La page est dans la catégorie Pages contenant trop d'inclusions de modèles, qui est automatique (je ne sais d'ailleurs pas pourquoi la page associée à cette catégorie a été supprimée). L'explication est là : http://www.mediawiki.orghttps://dictious.com/fr/Help:Tracking_categories : après expansion des modèles, la page dépasse la taille maximale (a priori, de 2048 kilooctets). La solution serait peut-être de simplifier tous ces modèles pour qu'ils soient plus simples et génèrent moins de caractères. On peut peut-être gagner de façon très simple en supprimant des commentaires (?) ou des catégories (catégories de modèles dont l'utilité est très faible). Mais de façon générale, il faut veiller à ne pas compliquer les modèles. Lmaltier (discussion) 15 mars 2013 à 20:40 (UTC)
Je suis justement en train de travailler sur le Module:traduction qui pourrait simplifier ces modèles (on pourra discuter de la pertinence des catégories créées). Cependant j'ai bien peur que même avec des modèles plus simples on arrive rapidement à la limite. C'est un vrai mur technique qu'il faudra surpasser, pas seulement contourner. — Dakdada15 mars 2013 à 20:45 (UTC)
Je suis persuadé qu'on peut gagner nettement, et qu'on a encore un peu de marge si on simplifie : même si on indiquait 10000 traductions dans la page, et si chaque ligne de traduction comptait environ 100 caractères en moyenne (c'est déjà pas mal), il serait possible de donner ces traductions en 1000 K. Sinon, la seule solution serait sans doute de devoir accéder à des pages différentes de traductions par groupe de langues, ce qui n'est pas terrible pour les utilisateurs. Mais peut-être la limite effective actuelle est-elle inférieure à 2048 K ? C'est la limite par défaut, mais elle a peut-être été modifiée pour le Wiktionnaire, et on pourrait peut-être l'augmenter ? Mais même si on augmente la limite, il faut vraiment éviter les modèles gourmands, et très bien évaluer l'utilité des catégories avant de les rajouter. Lmaltier (discussion) 15 mars 2013 à 21:05 (UTC)
Pour être clair, en l'occurrence, la gourmandise des modèles est ici le texte qu'ils affichent, qu'importe la complexité du modèle lui-même. Cela dit, je pense que les catégories encombrent également le modèle, je serais donc favorable à leur suppression.
Autre détail : je suis en train de convertir les modèles {{trad}} et j'y ai trouvé un reste du temps où on affichait le code langue à la place des astérisques. Le code est toujours créé par les modèles, caché, mais affichable uniquement par une fonction javascript. Je propose d'enlever cette partie de code rapidement... — Dakdada15 mars 2013 à 21:13 (UTC)
Correction : mon affichage était justement personnalisé pour ces éléments... En gros on a le choix entre (*) et (en), le défaut étant le code langue. Le plus simple serait de n'en garder qu'un (voire de l'écrire autrement, de manière encore plus simple). — Dakdada15 mars 2013 à 21:52 (UTC)
Hmmm, je ne suis pas sûr d’avoir tout bien compris sur l’origine du problème mais la seule solution semble être de simplifier au maximum les modèle {{T}} et {{trad}} et compagnie. À voir donc avec les modules que développent actuellement Dakdada pour voir si ça permet d’améliorer significativement les choses. Parce que j’ai un autre problème avec cette page. Je n’arrive plus depuis peu (aujourd’hui ?) à modifier la page en entier. Si je veux ajouter une traduction, je dois systématiquement éditer une section sinon la page m’envoie systématiquement sur une erreur.J’imagine que l’origine du problème est la même. Idem lorsque j’enregistre une traduction, j’arrive presque tout le temps sur une page d’erreur. Et c’est lorsque je réactualise la page qu’il arrive finalement à enregistrer la page. Pour le moment ça ne dérange que moi mais si ça arrive dans une page d’un article, ce n’est pas acceptable. Pamputt15 mars 2013 à 21:58 (UTC)
Comme c'est l'heure à laquelle l'Amérique s'active, les serveurs sont débordés. Ils ont d'autant plus de mal avec les grosses pages comme celle-ci.
Bon... j'ai déchargé plusieurs choses (catégories de traduction, astérisques superflus, et autres fioritures) avec la version Lua des modèles T et trad, et il semble bien qu'on affiche alors >50% de texte en moins (1000B contre 2300B ici), sans compter la vitesse d'exécution probablement bien supérieure. — Dakdada15 mars 2013 à 22:46 (UTC)
Purée ! l’ouverture du « code source de la page » a provoqué un âcre dégagement de fumée de la part de mon ordinateur.
À la tienne GaAs ! On peut aussi utiliser les modèles temporaires T2 et trad2, avec on peut arriver à tout afficher (et encore, ce n'est pas totalement optimisé) : . — Dakdada18 mars 2013 à 18:17 (UTC)
Pages incluses dans la page d'accueil
Bonjour,
Savez-vous à quoi servent cette catégorie exactement : Catégorie:Composants de la page d’accueil ? À lister seulement les composants actuels, ou tous ceux actuels + passés qu’on pourrait reprendre + hypothétiques qui ne sont qu’à l’état de travaux personnels encore ?
Quant à cette page : Discussion Wiktionnaire:Page d’accueil/Entête, elle me paraît vieille, et j’ai l’impression que son contenu mériterait d’être mis à jour ; cette impression est-elle justifiée ? Auquel cas je m’en occuperai.
Scribunto a été lancé la semaine dernière et je commence à y voir clair dans ce qu'on peut faire avec (voir WT:Lua et WT:Questions techniques pour plus de détails). On devrait bientôt pouvoir proposer quelques points de nomenclature pour bien organiser nos modules, et on a déjà une petite liste de modules en construction.
Il reste cependant quelques questions en suspens. Je vous propose de faire une liste de questions ci-dessous, si vous en avez, par exemple si vous vous demandez si ça vaut le coup de convertir certains modèles, ou si vous avez des questions sur les performances. J'y répondrai directement si je peux, sinon je poserai ces questions directement lors d'une réunion IRC destinée justement à répondre aux questions sur Scribunto, vendredi prochain à 19h sur le canal #wikimedia-office de freenode (détails). J'ai commencé avec quelques questions plus ou moins techniques. — Dakdada17 mars 2013 à 18:51 (UTC)
Est-ce que changer un module utilisé dans beaucoup de pages aura des conséquences sur le rafraîchissement des pages ? (Exemple : ajouter une langue à Module:langues/data, sachant que ce module serait utilisé dans toutes les pages)
Y a-t-il un moyen d'utiliser les propriétés des caractères unicodes avec la bibiothèque mw.ustring ? (Exemple : trouver les accents : \p{Mark}, pour les enlever des clés de tri)
À défaut : une librairie universelle qui renvoie automatiquement les clés de tri selon les règles d'une langue donnée ? (Possible de faire ça avec Wikidata sinon ?)
Dans le même ordre d'idée : une fonction de tri qui respecte la langue donnée (table.sort) ?
Où peut-on trouver la liste des langues de mw.language.fetchLanguageName() ?
Peut-on introduire la possibilité sur certains modules sensibles de ne publier des modifications qu'après patrouillage (review) par d'autres contributeurs ?
Possibilité de donner une page de test par défaut pour un module/modèle donné ?
Utilisation du patron de conception "visiteur", qui permettrait de contrôler des bots écris dans d’autres langages via le Lua. JackPotte ($♠) 17 mars 2013 à 22:18 (UTC)
Je n'ai pas compris. C'est quoi un patron de conception visiteur, et qu'est-ce que les bots ont à voir là dedans ? — Dakdada18 mars 2013 à 14:44 (UTC)
L’important est « intégrant les bibliothèques spécifiques Wikimedia », l’utilité étant de pouvoir tester les codes sans polluer les historiques du Wiktionnaire. --GaAs19 mars 2013 à 10:25 (UTC)
Moi je pollue les pages sans vergogne . Tu pourrais trouver quelque chose dans mw:Extension:Scribunto. Si tu te fais un wiki perso, tu peux aussi importer l'extension Scribunto et t'amuser autant que tu veux (c'est ce que je faisais pour le javascript parce que le développement sur un wiki est vraiment nul, mais pour le lua c'est suffisamment bien fait pour être fait ici). — Dakdada19 mars 2013 à 23:05 (UTC)
Comment utiliser correctement la page Spécial:TemplateSandbox, censée servir à tester la conversion de modèles en modules avant publication ? Les champs à remplir sont un grand mystère (Automatik (d · c · b))
Ce n'est pas plus destiné à tester les modules Lua que les modèles normaux. Les modules Lua doivent être testés avec des pages de test dédiées. — Dakdada18 mars 2013 à 14:44 (UTC)
Comme ils disent, c'est pour tester et comparer un modèle déjà converti, donc on ce n'est pas utilisé pour le développement des modules. — Dakdada18 mars 2013 à 14:55 (UTC)
Ok, reste la question de à quoi sert cette usine à gaz si le modèle est déjà créé (quelle est la différence avec le bac à sable, par exemple). Automatik (discussion) 18 mars 2013 à 15:05 (UTC)
La différence c'est qu'on peut tester une série de modèles modifiés dans un article actuel. Par exemple, si je fais "Utilisateur:Darkdadaah/Modèle:voir" (et d'autres modèles clones de modèles actuels), je peux voir comment il remplace le vrai modèle {{voir}} dans un article quelconque actuel sans avoir à faire de copier-coller ou de remplacement. — Dakdada18 mars 2013 à 15:11 (UTC)
Je crois toucher le bout mais je n’arrive pas à comprendre ce qu’il faut mettre dans chaque différent champ. Pas grave si t’expliques pas, j’ai vraiment du mal à comprendre des fois Automatik (discussion) 18 mars 2013 à 15:20 (UTC)
Toutes les périodes géologiques sont des noms communs. Leur majuscule est une simple convention (obligatoire tout de même) afin de les différencier des adjectifs. --Lyokoï (discussion) 17 mars 2013 à 22:59 (UTC)
Pour ajouter à cela, mon Dictionnaire de géologie (la référence en la matière…) indique clairement que toutes les périodes géologiques sont des noms communs. --Lyokoï (discussion) 18 mars 2013 à 00:07 (UTC)
@Automatik, ton lien « CNRTL » c’est le TLFi. Le CNRTL n’est pas le nom d’un dictionnaire, mais celui de l’organisme qui s’occupe de mettre en ligne de TLFi et le DAF. --GaAs18 mars 2013 à 15:13 (UTC)
Les entrées en chinoix traditionnel ont le code langue {{zh}}, mais le code {{zh-Hant}} indique chinois traditionnel, et la catégorie Catégorie:chinois traditionnel indique en son en-tête que le code langue est zh-hant. On a donc trois codes différents pour le chinois traditionnel.
J’ai mis un lien dans la catégorie vers le modèle existant, pour les deux codes restants je dirais que l’un est plus précis que l’autre. JackPotte ($♠) 18 mars 2013 à 11:03 (UTC)
Selon vous, pour les adverbes, est-il utile de mettre sur la ligne de forme que le mot est invariable ou pas ? Tous les adverbes étant par définition invariables, n’est-ce pas redondant ? Il serait bien de prendre une position claire là-dessus, comme le font tous les dictionnaires. Merci d’avance pour vos réactions. Automatik (discussion) 18 mars 2013 à 14:38 (UTC)
En effet, il ne devrais pas y avoir de redirection… Surtout lorsque le Midi désigne clairement une région de la France (toponyme, majuscule, tout ça…). --Lyokoï (discussion) 18 mars 2013 à 22:07 (UTC)
Redirection à la c*** supprimée. Bon, maintenant ne reste plus qu’à créer une page pertinente. --GaAs18 mars 2013 à 23:08 (UTC)
Il faudrait peut-être penser à dire que '-o' latin chute en gallo-roman, et qu’il s'agit donc de recréations néologistiques. Xic66718 mars 2013 à 23:12 (UTC)
Parce que j’en ai vraiment marre du lua, du javascript, du css, et *du tout le reste, et qu’améliorer les articles du Wiktionnaire est la seule chose qui me donne une raison de vivre. --GaAs18 mars 2013 à 23:15 (UTC)
C’est drôle que tu prennes l’eau pour exemple, puisque justement, c’est un des projets en cours en ce moment ! Ainsi que d’autres. Ne t’en fais pas tant, il n’y a pas que la technique pour occuper nos journées ! Si tu as envie de t’évader un peu, tu peux jeter un oeil sur les projets de portails de Dhegiha pour faire de la mise en page, des propositions graphiques ou compléter les pages déjà liées. Sinon, plus localement, faire le tour des langues de France, en s’aidant des informations du site de la DGLFLF. Eölen (discuter)18 mars 2013 à 23:40 (UTC)
Ce n'est pas un suffixe Ce n'est pas parce qu'on change la dernière lettre d'un préfixe que ça s'appelle un suffixe (et inversement). — Dakdada19 mars 2013 à 10:12 (UTC)
Je me demande même si on peut réellement parler de suffixe pour certains autres cas au-dessus. Depuis quand les apocopes ont comme suffixe leur dernière lettre ? — Dakdada19 mars 2013 à 10:14 (UTC)
Pour ce dernier point, c’est écrit en note dans l’étymologie, mais il faudrait sans doute développer. Pour moi, le fait que le français ait tendance à apocoper les mots sur une syllabe se terminant en « o » n’est pas un hasard, et est bien lié au suffixe -o. --GaAs19 mars 2013 à 10:18 (UTC)
je ne peux qu'approuver le point de vue de Darkdadaah, je dois malheureusement dire que je suis tombé sur pas mal de pages qui laissent penser qu'on fait sur le wiktionnaire de toute fin de mot un suffixe potentiel, ce qui n'est pas juste. Voir par exemple -da, qui est à mon avis du grand n'importe quoi à peu près de A à Z. Xic66719 mars 2013 à 20:13 (UTC)
J’ai besoin de techniciens. Il y a un bug dans l’alphabet mongol. Si je rentre le mot ᠵᠢᠷᠭᠤᠭ᠋ᠠ où le dernier a (ᠠ) est séparé et devient (ᠠ) - en transcription : jirɣuɣ-a - la page à créer affiche automatiquement ᠵᠢᠷᠭᠤᠭ᠋ ᠠ. Il faut apparemment le séparateur unicode U+180E pour afficher ce a séparé. celui-ci semble donc ne pas fonctionner ici - où bien j’ai fait une erreur… Dhegiha (discussion) 19 mars 2013 à 09:19 (UTC)
En effet si on ne met qu’un seul séparateur le "a" change, c’est un peu le même genre de bug que quand on essaie de manipuler de l’alphabet arabe dans un module Lua… Il faut donc coller la chaine depuis un éditeur de texte pour obtenir le résultat escompté ᠵᠢᠷᠭᠤᠭ᠋ ᠠ. JackPotte ($♠) 19 mars 2013 à 11:17 (UTC)
Merci. Mais peux-tu me décrire plus précisément la marche à suivre. J’ai essayé le copié-collé depuis Word, sans changement. Dois-je laisser tomber U+180E? Ton « résultat escompté » affiche bien ᠠ et non(ᠠ). Dhegiha (discussion) 19 mars 2013 à 12:00 (UTC)
Ça semble bien être un bogue de Mediawiki. Google Chrome semble aussi normaliser ᠵᠢᠷᠭᠤᠭ᠋ᠠ par ᠵᠢᠷᠭᠤᠭ᠋ ᠠ. Firefox ne semble pas avoir se problème. --Moyogo(discuter)22 mars 2013 à 19:38 (UTC)
PàS qui trainent
Les PàS suivantes manquent cruellement de votants, et donc je n’ose pas les clore. Alors, si deux ou trois votants s’y ajoutaient, je me ferais un plaisir de les poubelliser (les PàS, pas forcément les articles, hein).
NB (ultimatum) : en l’absence d’activité sur ces PàS, je déciderai arbitrairement (par exemple avec une paire de dés) de supprimer ou de conserver ces pages, parce que un an sans décider est bien trop long. --GaAs19 mars 2013 à 19:48 (UTC)
Pardon ? Le bandeau indique bien que la présence de la page est discutée, alors où est le problème ? C'est bien mieux comme ça que de risquer de supprimer une page utile. Simplement, ce serait encore mieux, effectivement, qu'une décision collective claire et argumentée s'impose dans chaque cas, et ça exige effectivement plus de participants. Lmaltier (discussion) 19 mars 2013 à 22:26 (UTC)
Le bandeau indique clairement que ça fait plus d’un an que tu te désintéresses de ces pages. Alors assume. Ou va défendre ces pages, je me ferais un plaisir à les déclarer "conservées". Mais les garder ad vitam eternam comme "à supprimer peut-être", certainement pas. --GaAs19 mars 2013 à 22:29 (UTC)
Lumière sur
Une canadienne faisait remarquer sur OTRS aujourd'hui que l'article "lumière sur" en page d'accueil était le même ... depuis des mois. Ma fois, c'est fort vrai . Ptet qu'un ptit changement donnerait un ptit coup de fouet à la page d'accueil ? Anthere (discussion)
C’est vrai, mais pas tout à fait : la page d’accueil change toutes les semaines.
Ta copine, elle connait le bouton « modifier » ? Parce que si oui, elle est la bienvenue (et soit sure que je serai un amour de pédagogie avec elle).
Bé non. Ca n'avait pas l'air de changer ;) Ce n'est pas ma copine mais je vais me faire un plaisir de lui signaler ta proposition ;) Anthere (discussion)
Bon, les aminches, faut qu’on s’bouge le cul et qu’on remplace le bateau sur la pda, même Anthere a fini par remarquer qu’on était pas à la hauteur, fouchetremidouille ! --GaAs19 mars 2013 à 23:09 (UTC)
Arf j'ai la tête dans le Lua en ce moment, je vais peut-être faire un truc de ce genre pour me changer un peu les idées. — Dakdada19 mars 2013 à 23:14 (UTC)
Moi j’ai déjà pété les plombs. Je ne vois pas comment pouet poeut, d’ailleurs je ne sait même quelle sous-page de la pda est rhinocéros. Ou pas. --GaAs19 mars 2013 à 23:24 (UTC)
Si quelqu’un a besoin de repérer facilement quels modèles ou pages sont utilisés dans la page d’accueil sans avoir à chercher il y a Discussion Wiktionnaire:Page d’accueil/Entête qui au premier coup d’œil donne la réponse. J’ai pas réussi à centrer le tableau cela dit (class="wikitable centre" marche pas), vos compétences sont les bienvenues. Automatik (discussion) 19 mars 2013 à 23:29 (UTC)
Voilà. J'ai choisi le thème pour attirer les gens. Parce que les gens, ils aiment les chatons. Et s'ils n'aiment pas les chatons (nom 1), ils doivent aimer les chatons (nom 2). Et maintenant je sais pourquoi j'hésitais à me lancer : j'ai pris plus de temps à retoucher l'article chat qu'à écrire l'extrait (pas une mauvaise chose en soi, mais c'est chronophage). Merci d'ailleurs de me relire, pour les deux. — Dakdada20 mars 2013 à 22:32 (UTC)
Lien de traduction en rouge alors que l'article existe
Bonjour,
J'espère que je poste ceci au bon endroit. Si non, toutes mes excuses.
Si je les ai bien comprises, il ressort des pages d'aide :
Modèle:trad+
et Wiktionnaire:Liste de tous les modèles/Autres modèles#Liens particuliers
que lorsqu'on utilise :
{{trad+|en|mot}}
c'est un robot qui se charge de trouver la page correspondante.
Et que: "{{trad+}} est la variante de {{trad}} qui colore le lien en bleu pour indiquer que la page existe bien sur le Wiktionnaire cible."
Donc, je ne comprends pas pourquoi dans l'article:
sucer la pomme,
le lien suivant:
{{T|en}} : {{trad+|en|suck face}}
s'affiche en rouge, alors qu'il existe bien un article correspondant dans le Wiktionnaire anglais:
en:suck face
Ai-je compris quelque chose de travers ?
J'ai par ailleurs une autre question : est-il possible d'ajouter, comme sur wikipedia, des lien interlangues dans le cadre à gauche de la page ? Et si oui, comment (ou bien sur quelle page cela est-il expliqué) ? En effet, après avoir parcouru -très brièvement, il est vrai l'aide du wiktionnaire-, je n'ai pas trouvé d'instructions à ce sujet. Donc, toutes mes excuses si cette question se révèle être née d'une inattention de ma part.
(J’ai formaté ton message.) Le mot (suck face) est maintenant écrit en lettres rouges, parce que nous n’avons pas de page sur le Wiktionnaire français, mais le lien ((en)) est écrit en lettres bleu ciel parce qu’ils ont une page sur le Wiktionnaire anglais. — TAKASUGI Shinji (d) 21 mars 2013 à 01:32 (UTC)
On peut ajouter un lien interwiki à la fin d’une page par écrire ], xx étant un code de langue comme en pour l’anglais. En fait il y a plusieurs bots qui ajoutent des liens interwiki sur le Wiktionnaire, et on n’a donc pas besoin d’en ajouter manuellement. — TAKASUGI Shinji (d) 22 mars 2013 à 02:19 (UTC)
Tri des catégories
Si vous aussi vous en avez marre d'avoir à écrire des clés de tri juste pour voir les catégories rangées correctement, n'hésitez pas à venir voter pour le bug qui vient d'être réouvert :
Si un peu, ce serait tout de même plus sur d’avoir des mots de passes différents (mais moi-même, j’ai quasiment les mêmes sur ces trois sites). Cdlt, VIGNERON * discut.24 mars 2013 à 16:49 (UTC)
Acceptabilité des citations souffrant de fautes d'orthographe ou de grammaire.
Bonjour,
Je rebondis sur la discussion initiée il y a deux ans ici, dont la question initiale n’a pas eu de véritable réponse.
Or il serait intéressant d’arriver à un consensus pour pouvoir compléter la page d’aide sur les exemples qui ne dit mot sur la façon de choisir les citations.
J’aurais pour ma part deux remarques.
De façon générale, je trouve inapproprié voire imbécile sur un dictionnaire de langue d’utiliser une citation comportant une faute avérée (c.-à-d. qui n’est pas volontaire, ou qui ne soit pas une orthographe ou une tournure désuète) : quel dictionnaire aurait cette idée saugrenue ? Il ne me semble pas bon de montrer des fautes au lecteur quand on peut s’en passer ; de plus les citations sont choisies parce qu’elles illustrent le bon usage (ou un usage disons) de la langue, donc qu’elles soient exemptes de faute me semble la moindre des choses. Certains cas très exceptionnels (comme l’illustration d’un hapax ou d’un sens ou emploi spécifique rare) pourraient seuls le justifier, en informant cependant le lecteur de la teneur de la faute.
Il a été proposé d’utiliser le modèle {{SIC}}, ce qui serait certes la moindre des choses, mais :
si celui-ci informe le lecteur que la citation est ainsi écrite, il ne lui donne pas d’indication sur la forme qui aurait été correcte ;
réserver le modèle {{SIC}} à des cas où l’auteur commet volontairement une licence ou lorsqu’il est fait usage d’une graphie désuète me paraitrait plus intelligent et n’embrouillerait pas le lecteur, qui aujourd’hui ne sait trop à quel saint se vouer. Par exemple, dans l’article dès lors, la citation est la suivante : Le Grec a été dès-lors chéri par moi, respecté dans ses propriétés, dans tous ses droits ; aujourd’hui le lecteur ne sait pas s’il s’agit d’une faute d'orthographe ou d’une graphie ancienne.
Donc je proposerais d’insérer dans la page d’aide sur les exemples une règle indiquant que les citations choisies doivent être exemptes de faute d’orthographe ou de grammaire avérée (et alors éventuellement que toute exception devrait être justifiée sur la page de discussion de l’article sauf cas évident d’hapax, et également faire l’objet d’une note donnant l’orthographe correcte à la suite de l’exemple). Ce qui nous permettrait aussi de faire le ménage. Chris06✍22 mars 2013 à 15:36 (UTC)
Disons que si on peut remplacer par une citation sans faute, il faut le faire. Et c’est presque tjs le cas, les seules exceptions qu’on voit un peu souvent sont les mots de jargon qu’on ne trouve que dans les forums sur le web. --GaAs22 mars 2013 à 15:53 (UTC)
Oui, et pour les citations que nous n’arrivons pas à remplacer par des citations exemptes de fautes. Il est tout à fait possible de corriger la citation (faute grossière, faute d’accord) mais il est alors impératif de dire ce qui a été corrigé dans la citation. Voyez par exemple dans les articles : illimiter, rehennir, parisienner, "corrig%C3%A9+en" etc. Stephane8888✍22 mars 2013 à 20:40 (UTC)
Je suis d'accord avec tout ce qui a été dit. Je voudrais juste ajouter que ce qui compte avant tout, c'est l'utilisation du mot. Et quand on trouve des exemples prouvant clairement que le mot existe, est utilisé, mais que tous les exemples comportent des fautes, c'est bien de les mettre faute de mieux, éventuellement en corrigeant et en indiquant les corrections faites. Mais il est parfois difficile de savoir si l'auteur n'a pas choisi volontairement l'orthographe (on peut très bien dans ce cas le trahir en corrigeant). Cela ne doit donc être fait qu'avec prudence, et en dernier ressort. Lmaltier (discussion) 22 mars 2013 à 21:23 (UTC)
Merci de ces précisions et idées ; j’avais en tête le principe académique suivant lequel on ne devait au grand jamais toucher aux citations (sauf concernant les conventions typographiques), mais cette méthode de correction « in situ » me semble très acceptable du moment qu’on fait mention de la correction apportée. Peut-on donc être d’accord sur l’ajout des règles suivantes (dans les grandes idées en tout cas, tout ça peut être affiné par qui le jugera utile) dans l’aide ?
Un écrit ne devrait être cité que s’il est exempt de faute d’orthographe ou de grammaire qu’on peut suspecter de ne pas relever de la volonté ou des habitudes de l’auteur.
Dans le cas où le mot ou l’utilisation spécifique du mot qu’on souhaite illustrer est excessivement rare et que la seule citation disponible comporte une faute qui ne relève pas de façon certaine de la volonté de l’auteur, il est autorisé et conseillé de corriger directement la citation, sous réserve d'indiquer à sa suite (après l'indication de la source) la correction qui a été réalisée, de façon à ce que le texte original soit reconstituable.
Il est de façon générale encouragé et souhaitable de remplacer les citations avec faute par des citations sans faute.
Lorsqu’une citation avec faute est présente alors que l’usage particulier du mot est déjà correctement illustré par une ou des citations sans faute, il est possible de la supprimer. Chris06✍23 mars 2013 à 00:17 (UTC)
D’accord avec les points évoqués ci-dessus. PS: Je me suis permis de rajouter les guillemets dans le lien que tu as mis Stéphane, afin de cibler plus précisément les articles visés. J’espère ne pas avoir fait de bourde. (Stephane corrigé en Stéphane) Automatik (discussion) 24 mars 2013 à 00:47 (UTC)
J'ai modifié Aide:Exemples : j’ai inséré une nouvelle section « Règles concernant les citations », avec les sous-sections « Reproduction des citations » (ça manquait aussi) et « Choix des citations ». Chris06✍24 mars 2013 à 00:56 (UTC)
Ben c’est comme le Port-Salut… RTFM :-) Eh non ça y est, après quelque labeur, je n’ai plus de boulot depuis cet après-midi, j’ai atteint la fin de la liste ; à priori à peu près tous les emplois de sont maintenant conformes (à part deux dus à une récente opposition mais j’espère que ça va être bientôt réglé), et nous avons donc des (enfin, quelques au moins) citations un peu plus lisibles. Chris06✍2 juin 2013 à 20:19 (UTC)
La différence est que pour les liens en rouge, il est incorporé un « %C2%AD » après les deux premières lettres. Ça devrait être donc le code hexadécimal d'un trait d'union virtuel.
Pour les curieux qui voudraient plus d’infos : w:Trait d'union conditionnel (U00AD). Vu que ce caractère est par définition invisible, quelqu’un saurait effectuer une vérification qu’il n’existe aucun titre qui le contient ? (je pensais utiliser grep.php mais il ne comprend pas les entités HTML ou autres codages). Cdlt, VIGNERON * discut.24 mars 2013 à 16:45 (UTC)
Je viens de convertir un premier modèle en Lua : {{voir}} (module associé : Module:voir). L'affichage des pages est exactement le même qu'avec l'ancien modèle (par exemple : A), donc vous ne verrez aucune différence. Le nombre de paramètres n'est plus limité que par le nombre de paramètres qu'un modèle peut accepter (non pas que la limite de 100 ait jamais été atteinte, mais c'est toujours ça). Le code du modèle est bien plus simple (voir ), le module n'est pas compliqué du tout, et on a un léger gain de performance (certes négligeable à l'échelle d'une page). J'ai bien testé le module, mais si vous constatez quelque chose d'anormal, faites le moi savoir.
Ceci est le premier modèle converti, son impact n'est pas énorme, mais c'est une bonne démonstration. Je prévois de convertir les modèles de traduction dans un second temps, et là les performances seront bien plus importantes (car on utilise ces modèles lourds de nombreuses fois dans une page). La seule chose qu'il reste vraiment à faire pour cela est de remplir au mieux la table des langues de manière à ne pas avoir à y retoucher trop souvent par la suite.
Cela fait, je proposerai enfin la modification des titres de section, qui est mon but principal avec Lua. On aura alors enfin des sections modifiables (et des modèles plus lisibles et mieux organisés).
Il faudra aussi revoir nos modèles de conjugaison, d'accord et de déclinaison, mais j'ai quelques petites choses à finir avant de m'y mettre . — Dakdada23 mars 2013 à 19:46 (UTC)
Je dis peut-être une bêtise mais avec Lua, ne serait-il pas possible que le module:voir trouve tout seul tout ou partie des pages existantes ? (a minima les variations de casses) Certes, cela changerait un peu le comportement dans le main mais ce serait pour le mieux. Cdlt, VIGNERON * discut.24 mars 2013 à 12:27 (UTC)
Pour faire court, ce serait extrêmement inefficace. Pour faire ça il faudrait demander au wiki de trouver les articles qui se ressemblent typographiquement, et ça il ne sait pas faire. Rien que le fait de regarder les variations de casse est inefficace. Du coup il faudrait utiliser des bricolages et de nombreuses fonctions coûteuses, pour un résultat peu pertinent (quid des articles qui n'existent pas encore ?). — Dakdada24 mars 2013 à 14:11 (UTC)
Ok, j’imagine que ce n’est pas simple mais je n’imaginais pas aussi peu efficace (surtout que j’avais retenu que Lua était puissant pour la manipulation de chaîne de caractères, faisé-je fausse route ?).
De nombreuses fonctions coûteuses ? On ne peut pas s’en sortir avec 3-4 if ? Genre « si PAGENAME commence par une minuscule si imbriqué lcfirst(PAGENAME) existe alors l’ajouter au début de la liste à afficher sinonsi ucfirst(PAGENAME) existe alors l’ajouter au début de la liste » (je précise que je ne connais pas le Lua, je ne sais pas comment on peut y manipuler la casse et autre chose de ce genre). Sinon, plus loin, je me disais que l’on aurait au moins pu repérer les diacritiques non précombinés en Unicode (again, je ne connais pas Lua et ses conversions de codages ; au passage, je suis preneur d’un guide pour débutant).
Regarder si une page existe est une fonction coûteuse. La seule manière pour Lua de regarder si les variantes typographiques existent est de les regarder une à une, ce qui revient à dire qu'il faudrait tester l'existence de dizaines ou centaines d'articles, ce qui devient très coûteux à la longue. La meilleure chose à faire est donc de créer une liste nous-même et de l'écrire en dur dans les pages. Pour vous aider à faire cette liste automatiquement, je peux proposer d'utiliser un de mes outils : exemple des articles typographiquement similaire à « mere ». Si nécessaire je pourrais même faire un outil dédié à la création d'une liste à copier-coller dans {{voir}}... — Dakdada24 mars 2013 à 21:43 (UTC)
Ok, je comprends en partie et je te fais entièrement confiance. Dommage… Je ne connaissais pas ton outils, utile et très intéressant. Cdlt, VIGNERON * discut.25 mars 2013 à 07:53 (UTC)
L'arabe n'a pas vraiment de voyelle, donc c'est normal : c'est une translittération, pas une transcription (donc pas forcément prononçable). Concernant l'usage de transliterator : merci d'attendre avant de l'utiliser à grande échelle, il y a quelques optimisations et tests à faire. — Dakdada24 mars 2013 à 21:43 (UTC)
Voilà, j'ai au moins séparé la table des remplacements pour permettre sa mise en cache. Reste encore à commenter le code, faire des tests et vérifier s'il n'y a pas d'autres optimisations à faire. — Dakdada24 mars 2013 à 21:52 (UTC)
Si ça peut aider : plusieurs table de translittération. Sinon concernant les syllabaires japonais on dirait qu’il n’y pas de différence entre la transcription et la translittération et que ce soit principalement le système Hepburn qui est utilisé ; mais c’est à confirmer je demanderais à Shinji. PS : Ce serait mieux que le modèle se nomme translittération, non ? V!v£ l@ Rosière/Murmurer…/25 mars 2013 à 09:38 (UTC)
Je rejoins JackPotte sur la pertinence de la translittération des langues sémitiques. Concrètement :
À quoi sert en pratique une translittération ? Particulièrement, dans les langues sémitiques ?
Pourquoi opter pour une translittération, et pas une transcription phonétique ?
Je trouverais dommage que des transcriptions phonétiques déjà existantes pour des langues sémitiques (langues à consonnes) soient remplacées par des translittérations, ne donnant par définition aucune information sur la prononciation.
« À quoi sert une translittération ? » : à pouvoir transcrire un mot avec des lettres latines (dans notre cas), sinon pas vraiment grand chose d’autre. Pour la prononciation, c’est impossible à moins d’être demi expert en translitérations ou d’être un peu capable de lire le système d’écriture original. Le commun des mortels ne sait pas comment prononcer ś, š, ṣ, ş ou š́. Pour les autres, ça sert de raccourci.
De manière générale, la question des translitérations est assez difficile. Pour chaque langue, il peut y avoir plusieurs systèmes de translitération, il y a aussi des systèmes de translitération unifiée par système d’écriture, par exemple les translitérations ISO comme l’ISO 9 pour tout ce qui s’écrit en cyrillique, et de manière variable par langue ou par système d’écriture il y a les translitération de l’ALA-LC utilisés par les bibliothèques américaines et britanniques, les translitérations DIN utilisées en Allemagne dont certaines en France, les translitérations BGN/PCGN pour les noms géographiques utilisées aux États-Unis et au Royaume-Uni, les translitérations GENUNG pour les noms géographiques utilisées par l’ONU, etc.
La libraire logicielle ICU ou le CLDR fournissent certaines de ces translitérations ; ça serait plus pratique d’avoir une extension qui peut faire appel à ces données que de réinventer la roue dans un module Lua.
On ne sait pas quelles translitérations sont utilisées dans ce module. Sont-elles communes, sont-elles appropriées en français ? C’est bien beau, mais ça serait bien de savoir quelles translitérations sont données. --Moyogo(discuter)7 avril 2013 à 20:03 (UTC)
Je suis d’accord, il faudrait définir dans la doc. du module les sources des translittérations qu’on donne — à quelles normes réfèrent-elles ? —, cela permettrait une meilleure organisation des translittérations pour la suite (on n’aura pas à se demander « d’où vient cette translittération, au fait ? »). Mais alors se pose la question de la pertinence, dans certains cas, des translittérations.
Y a-t-il un exemple de cas où la translittération d’une langue sémitique est utile ?
Si on met la translittération automatiquement via le module Lua, que fait-on des transcriptions phonétiques déjà présentes ?
Le code du module dépasse du cadre et crée une barre de défilement horizontale ; est-ce dû à la largeur d’écran ?
Avant de déployer, je suis pour que la documentation éclaircisse sur les changements qui ont eu lieu. Par exemple pour les alphabets non latins qui comportent un tiret, sera-t-il remplacé par une espace (comme pour l’alphabet latin, ce qui dans ce cas est clair dans le code) ? Le modèle clé de tri pourra être utilisé sans paramètre du coup ? (Intéressant à savoir pour quand on formate des articles, autant faire cela aussi). Pour les langues que n’inclue pas le module, comment ça se passe ?
En réécrivant le module ça prendra moins de place en largeur ; pour l'instant le code est très inefficace (série de if et de or alors qu'une table de hachage serait plus adaptée, pas de données en cache, concaténation coûteuse, séparation des fonctions...). Module:transliterator est un bon modèle : je me pencherai dessus quand j'aurai le temps. Tant qu'on n'aura pas optimisé le module et fait une bonne batterie de test, il ne faut pas employer ce module. En outre, quid des règles par langue ? Enlever les accents ne donne pas forcément une clé de tri valide (cf l'ordre des accents en français). — Dakdada25 mars 2013 à 09:42 (UTC)
Formes de suffixes
Salut,
En, consultant l’article de qualité -oche, j’ai pu voir que le pluriel -oches était indiqué. Est-ce pertinent, pour tous les suffixes qui forment des noms ayant un pluriel différent du singulier, d’indiquer à chaque fois le suffixe au pluriel ? Comme -mère, -ible, etc. Il manque souvent, donc je préfère demander. Merci d’avance. Automatik (discussion) 24 mars 2013 à 02:06 (UTC)
Le pluriel est davantage celui du nom formé avec le suffixe que celui du suffixe en lui-même. À moins de trouver un nom formé avec le suffixe qui soit essentiellement utilisé au pluriel. Ceci dit, je trouve que c’est vulgariser utilement que de dire que le "pluriel" de -al est "-aux". Stephane8888✍24 mars 2013 à 17:29 (UTC)
Dans ce cas de -al, d'accord, ça a un sens. Mais dans le cas de -oche : le fait de mettre un s au pluriel n'est absolument pas lié au suffixe, c'est au mot complet qu'on rajoute le s, pas au suffixe. Lmaltier (discussion) 12 juin 2013 à 06:09 (UTC)
En lisant la page Convention:Typographie, je me rends compte qu’il n’est pas fait de distinction entre :
les règles typographiques qui relèvent de choix éditoriaux (utilisation de l’italique, du gras, utilisation de l’apostrophe courbe, etc.) et applicables partout ;
et les règles typographiques qui dépendent de la langue (type des guillemets, espacements autour des signes de ponctuation, écriture des nombres, utilisation des majuscules, etc.) et qui sont donc à mettre en application en fonction de la langue (c’est-à-dire surtout dans les exemples, pratiquement le seul endroit je pense où on peut rencontrer du texte construit qui n’est pas en français).
Pensez-vous que cette lacune mérite plutôt :
une simple modification des titres de section (un peu artificielle, mais rapide à faire), par exemple : « Espaces et signes de ponctuation en français », « Majuscules en français », etc. ; ou
un réagencement de l’article, qui présenterait alors les choix éditoriaux en premier, puis soit les conventions typographiques applicables au français à la suite, soit dans une autre page (typiquement : Wiktionnaire:Conventions typographiques en français). Cette dernière solution me semblerait assez propre.
Quelqu'un aurait le nom de la page qui définit tous les caractères spéciaux qui n’ont pas pu avoir une page spéciale pour des raisons techniques ? Automatik (discussion) 24 mars 2013 à 17:15 (UTC)
Suite à mes quelques déconvenues d’identification des langues, j’ai créé cette page pour permettre à chacun de venir expliquer comment identifier les langues des mots. J'ai mis une ébauche pour le français en insistant sur la particularité régionale du français. L’idéal serait que chaque langue (voire dialecte en sous-section) puissent avoir un petit guide d’authentification, surtout intéressant lorsque deux langues sont proches. Lorsque que nous estimerons la page suffisamment claire, je propose qu’on la lie à un certain nombre de pages d’aides. Donnez-moi vos avis ! --Lyokoï (discussion) 24 mars 2013 à 17:34 (UTC)
Très bonne initiative. Le seule bémol est le titre de l’aide qui n’est pas très explicite cependant je n’arrive pas à en trouver un plus convaincant pour autant. Peut-être Aide:Différentiation entre langues, parlers, dialectes ou tout simplement Aide:Langues, parlers, dialectes ? V!v£ l@ Rosière/Murmurer…/24 mars 2013 à 20:35 (UTC)
Ta deuxième proposition me plait pas mal. Et si je propose Aide:Quelles langues, parlers, dialectes et patois ?, c’est un peut trop long ? --Lyokoï (discussion) 24 mars 2013 à 20:40 (UTC)
Non, au contraire, c’est parfait car tout les termes susceptibles d’être utilisés pour rechercher cette aide sont présents (enfin il me semble). Donc j’approuve ta proposition de titre. V!v£ l@ Rosière/Murmurer…/24 mars 2013 à 20:54 (UTC)
Cette aide est une bonne idée àma. Elle est instructive et elle gagnerait à se compléter par tous les contributeurs qui ont des connaissances sur les distinctions entre langages qui peuvent à priori être confondus. Merci ; Automatik (discussion) 24 mars 2013 à 22:14 (UTC)
Très intéressant en effet. Le nouveau nom long me paraît adéquat, et elle viendra idéalement en complément de la page Annexe:Langues de France que je prépare - quand je l’aurai complété avec l’appui du site de la DGLFLF et que tous les liens seront bleus. Avis aux amateurs, j’voudrais d’abord finir les langues de Bolivie. Eölen (discuter)25 mars 2013 à 09:15 (UTC)
Et si je propose Aide:Quelles langues, parlers, dialectes et patois ?Lyokoï
J’ai été absente un certains temps et j’ai failli passer à côté de cette annonce Tri des catégories. Il me semble bon d’organiser une page simple listant les bugsbogues notifiés sur bugzilla impactant le Wiktionnaire. La page pourrait être présentée un peu comme Wiktionnaire:Annonces. Ainsi si touttous les utilisateurs actifs du Wiktionnaire avaient un compte sur bugzilla on pourraient coordonner nos votes et posséder un groupe de pression efficace. Et puis en cas d’absence ça permettrait de voir quel nouveau bugbogue a été notifié en un coup d’œil et de voter. Qu’en pensez-vous ? V!v£ l@ Rosière/Murmurer…/24 mars 2013 à 20:54 (UTC)
Le littré a-t-il été importé tout entier dans le wiktionnaire?
Salut, je pensais que le littré, entre autres dictionnaires du domaine public, avait été ingéré par le wiktionnaire. Or sur la page muni je ne vois aucune étymologie, tandis que sensagent en propose une dans la section Le Littré (1880). Alors, quand est-il ? --Psychoslave (discussion) 26 mars 2013 à 09:41 (UTC)
Je ne crois pas qu'on ait importé systématiquement le Littré (bien que certaines pages ont bien été créées automatiquement). En outre, On n'utilise pas les étymologies du Littré, car elles sont globalement de mauvaise qualité.
Cela dit, ce serait bien d'avoir une page listant les imports massifs qu'on a fait sur le Wiktionnaire, à commencer par le DAF8. Beaucoup d'articles ont été créés par bot, pas forcément en mentionnant la source, et pas forcément en en informant correctement la communauté (du coup certains articles créés ainsi sont passés à la suppression). — Dakdada26 mars 2013 à 10:26 (UTC)
Bon bah je remet ça sur le tapis suite à cette question d’un anonyme qui montre qu’il est nécessaire de trouver une solution. Premièrement beaucoup ici font encore la confusion entre découpage syllabique phonétique et orthographique donc faites attention même si parfois les deux découpes se superposent ce n’est pas toujours le cas (ex : contre as-tre ; contre an-cien-ne). Secondement, hormis pour les habitués du Wiktionnaire et les initiés en linguistique, souvenez-vous que les symboles de l’API restent juste des symboles louches et illisibles entre barres obliques sur la ligne de forme pour le commun des mortels. Par conséquent c’est inutile d’y renvoyer un quelconque lecteur pour ces deux raisons : 1/ ce n’est pas forcément ce qu’il cherche, 2/ il y a très peu de chance qu’il comprenne quoi que ce soit au schmilblick. Que fait-on ? Comment intégrer cette information ? Béo avait déjà fait une tentative, Moyogo avait lancé Wiktionnaire:Césure pour qu’on puisse y réfléchir ; Dakadada avait aussi proposé quelque chose pour régler le problème. Discussions précédentes sur le sujet : juin 2006, mai 2007, juin 2010 , juillet 2010, août 2012 (partie 1) (août 2012 (partie 2) Et oui ça fait bien 7 ans qu’on ne sait pas quoi faire.
Après avoir exposé le soucis voici ce que j’en pense. Est-ce utile ? Indubitablement oui, la preuve on nous le demande encore en 2013. Est-ce que ça fera doublon avec la découpe de {pron} ? Non puisque la syllabation phonétique et orthographique sont deux choses bien différentes (malgré les apparences). Doit-on créer une section rien que pour ça ? Bof, j’ai une préférence pour la proposition de Dadkdada de faire une section regroupant en vrac les "informations à problème". Si on n’arrive à dégager une tendance comme pour les verbes pronominaux ce sera déjà bien. À vous les studios. V!v£ l@ Rosière/Murmurer…/26 mars 2013 à 13:18 (UTC)
Je croyais que {{-césure-}} était employé (comme sur la version en italien) mais apparemment non. Je n’ai rien contre mais ne compte pas m’y investir faute de priorité. JackPotte ($♠) 26 mars 2013 à 14:34 (UTC)
Bah en fait non car, à ma connaissance, ce n’est explicité nulle part (pas de décision clair, ni de convention sur la méthode de traitement) ; et personne ne souhaitent créer une situation similaire au verbe pronominaux. C’est-à-dire une foultitude de traitement tous différent qui poseront problèmes lorsque quelqu’un souhaitera formater (absence de modèle référent). Au moins si on décide d’une convention commune une bonne fois pour toute et qu’on le cri haut et fort ici on pourra l’appliquer sans que ça ne pose problème (peu de chance de voir des guerres d’éditions). Après c’est pareil, j’ai juste une préférence si la communauté préfère créer une section à part, ça me va aussi. V!v£ l@ Rosière/Murmurer…/26 mars 2013 à 15:55 (UTC)
Pour reprendre ma proposition, on peut très bien imaginer une section Miscellanées (à défaut d'un meilleur titre) contenant les anagrammes, césure, anciennes écritures (chacun tenant dans une liste à puce succincte), et tout ce qui concerne essentiellement l'écriture d'un mot. Ce serait donc une section de niveau 3, qui suivrait directement la section de prononciation. — Dakdada26 mars 2013 à 16:59 (UTC)
Hyper-pas-prioritaire (càd à remettre au prochain siècle) en ce qui me concerne. Quand vous aurez fait toutes les conjugaisons, j’accepterai d’en reparler. --GaAs26 mars 2013 à 22:43 (UTC)
Digression sur l’appellation « syllabation orthographique »
Je m’étonne qu’on parle de syllabation « orthographique », ce qui est assez trompeur (et qui amène Eiku ici et surement d’autres à conjecturer qu’elle ne sert qu’à la coupure des mots) ; la syllabation dont on parle ici de la sorte :
est celle utilisée pour compter les pieds d’un vers (sauf pour la dernière syllabe…),
correspond à la syllabation « phonétique » (c’est d’après moi redondant pour une syllabation) dans le sud de la France (où l’on n’apprend fort logiquement à l’école que cette syllabation).
Ces deux utilisations montrent qu’elle est bien phonétique, comme toute syllabation. La différence entre les deux provient uniquement de l’amuïssement du e en français standard, qui effectivement fait que la langue parlée ne correspond plus (ou correspond moins disons) à l’orthographe (et qui accessoirement fait qu’on voit pas mal de fautes de la sorte : « Or à partir de toute quantité supérieure ou égal » car il n’y a plus de différence de prononciation entre égal et égale, mais là c’est ma fierté occitane qui parle ). Trouver un autre qualificatif devrait pouvoir se faire ; je pense que « classique » pourrait être adapté, par exemple. Chris06✍27 mars 2013 à 00:58 (UTC)
Oui mais il me semble que la discussion porte sur la césure qui est forcément orthographique. Quelque soit le nom qu’on lui donne, ce découpage est actuellement absent du wiktionaire. UnsuiDiscuter27 mars 2013 à 08:58 (UTC)
Puisqu’en effet le sujet est la « césure », parlons-en ! Outre le fait que cela s’appelle en bon français typographique « coupure des mots » ou « division des mots » en fin de ligne, je ne saisis pas l’intérêt de préciser les coupures possibles dans un mot, cela pour deux raisons :
la première est que cela ne serait pas suffisant pour exécuter correctement la coupure des mots : comment couper semble-t-il ? Comment savoir que même si le Wiktionnaire dit que confettis peut se couper, et bien on ne peut en fait pas si c’est le dernier mot d’une page impaire ? La coupure de mots est définie par un ensemble de règles et la connaissance de la syllabation, donc faire comme si chaque mot portait en soi l’information de la coupure me parait un peu tiré par les cheveux (cependant, on a déjà les anagrammes qui suivent la même logique : information non linguistique résultant de l’application d’une règle) ;
la deuxième est que la coupure des mots est affaire de typographe, et en cela, je me pose la question de l'intérêt de cette information (comme pour les anagrammes) : les compositeurs n’ont heureusement pas besoin du Wiktionnaire, et la connaissance de la coupure des mots est bien sûr inutile lorsqu’on rédige un texte électronique : les éditeurs s’en chargent automatiquement, pour ceux qui le font. Resterait… l’écriture manuscrite, et encore, pour ceux qui veulent un bord droit impeccable. Ça me parait un peu court. L'écriture étant normalement un processus fluide dans lequel on pense plus à ce que l’on doit dire, j’ai du mal à imaginer quelqu'un qui se retrouve bloqué par une coupure de mot, et qui, arrêtant son élan, se connecte au Wiktionnaire ; d’autant que la césure est une fois de plus question de règles : soit on ne les connait pas et alors on n’en fait pas quand on écrit, soit on les connait et on peut en faire (enfin, on peut aussi en faire sans connaitre les règles bien entendu !). Chris06✍27 mars 2013 à 22:42 (UTC)
Créer une annexe expliquant comment deviner la césure pour chaque mot, au lieu de surcharger la totalité des articles d’une section de plus. Automatik (discussion) 28 mars 2013 à 00:09 (UTC)
Une annexe sur le sujet est la bien venue. Le mot césure, polysémique, me gêne. Même Césure typographique ne me paraît pas clair. Ne peut-on pas parler de "Coupure typographique" ou "Coupure des mots" ? Le modèle {{-césure-}}, et son affichage, sont de ce point de vue à revoir. Ce genre d’information est utile à ceux qui écrivent une lettre manuscrite sérieuse (lettre de motivation…) et qui ne veulent ni faire un pâté en fin de ligne, ni tronquer le mot d’une façon inappropriée. Stephane8888✍28 mars 2013 à 14:17 (UTC)
Je me suis permis à l’instant d’amender le modèle en remplaçant son titre « Coupure de mot » par « Coupures du mot », qui me semble personnellement plus logique quand il s’agit de donner la ou les coupures possibles (voire tolérées ou interdites) du mot-vedette. Sinon l’annexe semble attrayante en effet. Chris06✍28 mars 2013 à 21:37 (UTC)
Oui, il vaut mieux ne rien mettre si on ne sait pas. Mais il ne faut pas enlever les informations des contributeurs. --GaAsMaltier26 mars 2013 à 22:33 (UTC)
Vu qu’on parle de bouc estain (qui était le seul mot de la catégorie), j’en profite pour poser une question. Ce mot est actuellement indiqué comme étant du moyen français. Or la seule « vieille » citation provient d’un monsieur du 18e siècle ce qui signifie donc qu’il s’agit de français « moderne » et pas de moyen français. Par ailleurs, la définition actuelle : « Variante ancienne de bouquetin » semble aller dans ce sens. Je suis donc pour modifier en français « moderne » en utilisant {{archaïque}}. Vous êtes du même avis ? Pamputt27 mars 2013 à 19:34 (UTC)
Mea culpa, je suis responsable de cette erreur ; effectivement, cela ne semble pas être du moyen français. D’ailleurs, le même jour, j’ai crée dimenche en tant que français alors qu’il s’agit sans doute de moyen français voir d’ancien français (et au passage, je dénonce aussi Actarus et GaAs qui avait participé à une discussion pré-création sans voir l’erreur). Cdlt, VIGNERON * discut.27 mars 2013 à 21:00 (UTC)
importer une liste d'article depuis son pc
Bonjour, j'ai récupéré une liste de mots (une centaine environ, avec définition, etc.) dans un fichier texte et j’aimerais les intégrer dans le WT. Je dois faire comment ? Je mets tout en forme dans un csv ? J'ai trouvé une page d’aide pour intégrer des fichiers (vidéos, audio, etc) mais rien pour créer plusieurs articles… Ah, je précise que j’aimerais bien pouvoir le faire moi-même, s'il faut coder notamment, je veux pouvoir le refaire à l’avenir. --Lyokoï (discussion) 26 mars 2013 à 21:35 (UTC)
@Lyokoï : tu n'as pas besoin de connaître python pour utiliser ce script. Tu dois juste savoir utiliser correctement la ligne de commande. — Dakdada26 mars 2013 à 23:14 (UTC)
Tu as récupéré ces définitions depuis quel source ? Tu le sais en fait peut-être déjà, mais il ne faut pas ajouter de contenu qui contreviendrais au droit d’auteur, donc ta source doit être compatible avec les licences du wiktionnaire. --Psychoslave (discussion) 27 mars 2013 à 07:32 (UTC)
Je suis intéressé vu que j’ai un bot (hors wiki) qui me crée des pages de flexions pour deux langues dans un fichier texte. Pourriez-vous détailler ce que vous entendez par "Tu dois juste savoir utiliser correctement la ligne de commande" ? UnsuiDiscuter27 mars 2013 à 09:27 (UTC)
Le script python s'utilise dans un terminal, donc sans interface graphique (comme c'est le cas pour AWB par exemple). Il faut donc que tu connaisses les bases de l'utilisation d'une ligne de commande pour lancer la commande (> python pagefromfile.py et la liste des arguments). Tout dépend ensuite si tu es sous Windows, Linux ou autre chose. — Dakdada27 mars 2013 à 10:02 (UTC)
Je vois. Donc je dois créer un tel script sur mon pc qui devra créer automatiquement les pages (à l’exécution de la commande)? ou je dois envoyer un xml ? --Lyokoï (discussion) 27 mars 2013 à 10:31 (UTC)
Ah ok, Donc, sous windows, en mode commande DOS après avoir installé Python & PyWikipedia ? (désolé du mix de préoccupations avec Lyokoï88 mais l’objectif est le même ) UnsuiDiscuter27 mars 2013 à 10:39 (UTC)
Pour donner un exemple concret (c’est le seul script que j’utilise de pywikipedia à part login.py), faut que tu crées un fichier xml formaté d’une certaine manière, puis tu tapes la commande suivante
voir pagefromfile.py pour comprendre les options. Et le fichier xml, ressemble en gros à ça (partie du fichier que j’avais utilisé pour créé les pages de flexions en espéranto)
Je viens d’avoir confirmation qu’on peut effectivement utiliser le contenu de ce dictionnaire espéranto-français. Je vous copie ci-dessous la réponse de Xavier Godivier à mon message lui demandant si le dictionnaire qu’ils proposent pouvaient être utilisé dans le wiktionnaire.
Bonjour,
vous pouvez utiliser le lexique sans problème pour le wiktionnaire. Je viens d'ajouter la mention de licence CC0 sur le site,
cordialement,
Xavier
Je peux essayer de regarder ça. Par contre, je n’ai pas trouvé la mention CC0. Si elle y est alors c’est parfait sinon on ne peut rien faire, à moi qu’il ait envoyé une copie de son mail à [email protected] d’après cette page. J’avais fait un import de ce genre pour des mots en népalais il y a quelque temps. Donc ça serait parfait si l’auteur pouvait nous fournir un fichier avec un plus la nature du mot (nom, adjectif, verbe, …) sinon il va falloir tous les indiquer à la main. Pamputt27 mars 2013 à 17:25 (UTC)
Bien que n’étant pas juriste, il me semble que c’est le droit des bases de données qui s’appliquent ici. Pamputt28 mars 2013 à 06:56 (UTC)
Exact, si on utilise que la liste de mots et pas les définitions ni la mise en forme de la liste, c’est purement une question de base de données. --GaAs28 mars 2013 à 11:12 (UTC)
J'ai questionné mon professeur de droit sur la question. Il ne devrait pas y avoir de problème d’import de cette liste s’il est fait de la mention Issu de l’import de la liste présente sur "site Internet". Donc si quelqu’un veut se lancer. --Lyokoï (discussion) 10 avril 2013 à 12:14 (UTC)
Onglet citation
Bonjour,
J’aimerais revenir (encore) sur l’opportunité de la mise en place d’un onglet citation comme sur la version anglophone du Wiktionnaire. Pour l’historique des conversations depuis 2008 : Wiktionnaire:Wikidémie/Onglet citation.
On commence à avoir pas mal de dictionnaires sur les Wikisources et un utilisateur est même en train de réfléchir à des pages par lemmes : s:Utilisateur:Pibewiki/Dictionnaires/Lemmes/angoisse. Ce genre de page n’étant pas exactement à sa place sur la Wikisource, je me suis dit que cela pourrait être utile au Wiktionnaire. Sachant qu’avec un peu de réflexion et de concertation, ce devrait même pouvoir être plus ou moins automatisé (enfin je l’imagine vu que les entrées de dictionnaires sont habituellement balisé sur la Wikisource et qu’il existe des outils de transclusions inter-projets).
Wikiquote serait très intéressant mais il n’y a ni page par mot, ni même vraiment de balisage par mot (q:Angoisse est d’un bloc et je ne sais pas si on pourrait faire une transclusion fine). Mais je me trompe peut-être, je connais moins bien ce projet.
A mon avis, Wikiquote recueille des citations comme des phrases célèbres, des aphorismes et des points de vue d’auteur sur telle ou telle chose ou concept : Ce peuvent être des définitions, mais pas au sens lexicographique.
Les pages par lemmes, qui compilent les définitions de dictionnaires, seraient précieuses pour les contributeurs du Wiktionnaire, et pour ses lecteurs aussi évidemment. Ce genre de fonctionnalité d’affichage a, je pense, sa place sur Wiktionnaire… sur un espace de nommage dédié (présenté sous forme d’onglet) avec un intitulé du genre "Compilation" ou "Autres dicos".
Au sujet d’un onglet Citations : je pense qu’on a déjà l’espace de nommage "Annexe:" qu’il suffit d’utiliser : ex. : Annexe:chat. Présenté sous forme d’un onglet "Annexe". Quant au contenu, je suis pour le laisser libre car il est difficile de prévoir ce qui sera pertinent d’y afficher. (de même qu’il serait contreproductif d’établir un format précis pour une page de thésaurus) Exemple : La page de discussion de au temps pour moi liste un grand nombre de citations historiques, à caractère étymologique, mais pour d’autres articles ce seront des citations attestant l’existence du mot, ou détaillant la chronologie de ses acceptions, etc. On pourrait aussi y publier d’autres types d’informations : fréquence d’emploi, vis à vis d’une variante, etc. Stephane8888✍27 mars 2013 à 20:50 (UTC)
J’avais oublié l’existence de l’espace de nom Annexe: (d’ailleurs, on y faisant un tour, on tombe sur des vieilleries : Annexe:Alphabets et son doublon Annexe:Alphabets du monde ou le grec Annexe:Παράρτημα:Προφορά/ελληνικά). Ce pourrait être le bon endroit effectivement. Si on pouvait l’afficher automatiquement en onglet cela pourrait être bien. Après, il faudra voir la technique et réfléchir à l’organisation précise mais je pense que cela pourrait fonctionner. La question est donc est-ce que vous trouvez ça utile et opportun ?
Oui c’est utile, car aujourd’hui à défaut d’avoir une visibilité personne ne crée de contenu (sauf en page de discussion des articles, mais ce n’est pas pareil). Sur une page d’annexe, c’est un contenu que chacun peut améliorer, comme dans l’espace principal. Je suis donc Pour avoir par défaut un onglet "annexe" pointant sur la page Annexe:mot. Cet onglet trouverait sa place entre l’onglet "discussion" et l’onglet "modifier". Stephane8888✍27 mars 2013 à 22:52 (UTC)
C’est une excellente idée, mais je pencherais carrément pour un espace à part car c’est bien particulier. Sinon évidement ce serait bien que l’espace Annexe: et Thésaurus: soient facilement accessible via les onglets. V!v£ l@ Rosière/Murmurer…/28 mars 2013 à 00:57 (UTC)
Donc si je résume, sur le fond tout le monde est pour ou plutôt pour et il faut donc discuter de la forme et de l’organisation. Demande-t-on la création d’un nouvel espace de nom ? (et si oui, comment le nommer ? Citation: comme sur en.wikt ?). Pour les onglets vers tout les espaces de noms, si on ajoute trois onglets dans l’interface cela va faire beaucoup (surtout sur des écrans de petites tailles comme les mobiles). Ce que l’on pourrait mettre en place c’est juste un onglet vers Annexe: et que sur la page Annexe: on place des liens vers les autres espaces (Thésaurus: et Citation: si celui-ci est crée), fausse bonne idée ou pas ? Il faudrait aussi voir les contenus à reprendre sur Wikisource et lister quels ouvrages seraient intéressants/utiles (et si un technicien peut voir comment on peut faire une transclusion inter-projet ; sur les wikisources, il existe les modèles Iwpage qui sont basés sur du Javascript ; en natif Mediawiki, il existe aussi mw:Manual:$wgEnableScaryTranscluding qui semble plus propre mais que je ne maîtrise absolument pas…). Cdlt, VIGNERON * discut.31 mars 2013 à 09:23 (UTC)
T’as solution est bonne. J’avais mal compris la proposition. Je croyais que Vigneron voulait importer toutes les définitions de tout les dictionnaires de Wikisource concernant le mot vedette. V!v£ l@ Rosière/Murmurer…/2 avril 2013 à 22:43 (UTC)
Tu m’avais plutôt bien compris ; après « tous les dictionnaires de Wikisource » c’est encore assez limité (on travaille justement à mettre de l’ordre dans nos dictionnaires sur Wikisource) et il est me semble évidemment logique de faire une sélection. Par contre, plutôt qu’un import je voudrais faire une transclusion (cela évite de recopier inutilement).
La solution que j’imagine est de prendre la page Annexe:au temps pour moi (qui me semble très bien aussi) et d’y ajouter une section en bas : « Définition dans d’autres dictionnaires » où l’on transclurais du contenu de Wikisource (typiquement tout ou partie de ce que l’on retrouve sur s:Utilisateur:Pibewiki/Dictionnaires/Lemmes/angoisse ; plutôt en partie car en l’occurrence certaines entrées ne concernent pas le mot angoisse…).
Transcluons ! Pour l’endroit, "Annexe:mot" peut convenir. Mais si cette transclusion concerne rapidement beaucoup d’articles, il serait préférable d’avoir d’emblée un espace de nommage dédié (du genre "Compilation:"). Stephane8888✍4 avril 2013 à 18:32 (UTC)
À bah voilà j’avais bien compris au final. Dans ce cas oui pour la transclusion ; si vous faites déjà ce genre de pages effectivement ce n’est pas la peine de recopier. Donc oui pour l’Annexe: de façon provisoire et puis un espace à part ensuite quand ce sera plus étoffé par contre Compilation ça me semble plutôt obscure comme nom d’espace mais bon on aura le temps d’y réfléchir. V!v£ l@ Rosière/Murmurer…/5 avril 2013 à 22:46 (UTC)
Les modèles -syn-, -voc-, -drv-, -trad- et -hypo- devraient afficher par défaut des boîtes enroulées.
En effet, les traductions du mot chat dans toutes les langues n'est pas l'information la plus attendue des lecteurs. Au contraire, ils peuvent vouloir rechercher les autres sens du mot chat.
NB : j'imagine que vous voulez parler des sections elles-mêmes et pas des modèles des titres de section. Mais je ne suis pas bien sûr de comprendre ce que vous voulez dire.
Peut-être dans cette idée, il a été proposé il y a quelques temps de réunir ces informations non pas par sections (toutes subdivisées en autant de sens à décrire) mais d'abord par les sens à décrire (subdivisés ensuite en autant autant de parties descriptives pour lister les synonymes etc.). — Dakdada27 mars 2013 à 10:09 (UTC)
"devraient afficher par défaut des boîtes enroulées" : on ne rajoute pas de l’information dans les articles pour le cacher aux lecteurs. En revanche, donner la possibilité aux lecteurs de cacher un type d’information : pourquoi pas. Stephane8888✍27 mars 2013 à 12:08 (UTC)
La traduction d'un mot dans toutes les langues, certes indispensable, n'intéresse pas a priori le lecteur que je suis. (Si j'ai besoin de cette information, je vais par défaut sur d'autres sites comme wordreference.) Pourquoi devoir parcourir une longue page pour trouver finalement les définitions du mot chat ? Conclusion : ne trouvant pas facilement l'information sur votre site, j'ai été voir ailleurs.
Je peux fort bien enrouler ces boîtes mais je devrai le faire systématiquement, à chaque nouvelle page chargée. Dans le cas inverse, si ces boîtes sont enroulées par défaut, les lecteurs intéressés par ces traductions peuvent fort bien les dérouler. Elles resteraient alors facilement accessibles.
Cordialement,
Vous savez, vous pouvez créer un compte utilisateur sur le wiktionnaire et ainsi utiliser un petit gadget qui enroule automatiquement les boites ! ^^ --Lyokoï (discussion) 27 mars 2013 à 17:18 (UTC)
Sur en.wikt ils ont, je crois, un gadget activé par défaut qui permet de fermer et ouvrir toutes les boîtes d'une page, et de garder les préférences lors de la navigation. On devrait en faire de même. — Dakdada27 mars 2013 à 17:22 (UTC)
De l’avis de Dakdada. Si c’est facile à mettre en place et que ça marche pour les IPs alors on fonce. Mais je suis pour que tout soit affiché par défaut. Après si un lecteur ne veut pas voir les traductions alors il cliquera sur le bouton « Cacher les traductions » et comme ça sera sauvegardé, il ne sera plus « embêter » par ça mais par défaut on doit tout afficher car on ne sait pas a priori ce qui intéresse le lecteur. Pour la sauvegarde du choix, à voir comment ça marche dans la pratique pour les IPs car il faut que le choix soit « oublié » en particulier pour les IPs dynamiques. Pamputt27 mars 2013 à 17:30 (UTC)
La création d'un bouton est intéressante, pourvu que ce "gadget" soit visible. Un lecteur devrait comprendre le fonctionnement de ce site sans avoir à lire des interminables pages d'aide. Trop de fonctionnalités sur les wiki sont pensées pour le bon usage des utilisateurs inscrits et sans tenir compte des besoins des non inscrits, qui sont les véritables lecteurs. Le message de User:Lyokoï ci-dessus en est un exemple. On convient que les inscrits aient des fonctionnalités pour mieux gérer le site (suivi des modifications et autre) mais pas pour mieux le consulter.
Je ne souhaite pas pour l'heure m'inscrire.
Cordialement,
Vous pouvez vous faire une idée de l’« utilisabilité » du bouton en consultant un article sur le Wiktionnaire anglophone avec l’article chat par exemple. Il faut cliquer sur « Show translations » (ou autre) dans la colonne de gauche. Pamputt27 mars 2013 à 17:57 (UTC)
Le problème, c'est qu'on ne sait pas ce qui intéresse les lecteurs qui affichent une page, chacun peut avoir un besoin différent. Mais la table des matières permet d'aller tout de suite où on veut, donc pas de problème. Et si ça ne suffit pas, on peut très facilement sauter les tables de traductions grâce aux ascenseurs (j'imagine que presque tous les lecteurs en bénéficient...) Je parle d'expérience : il n'y a rien de plus exaspérant que d'avoir à cliquer sur des tas de boutons pour aller chercher tous les renseignements qu'on désire, et en plus c'est souvent pour constater après avoir cliqué que les renseignements qu'on cherche sont absents (c'est la spécialité de certains sites mal conçus). Un autre avantage d'afficher par défaut, c'est que les lecteurs se rendent mieux compte de tous les renseignements disponibles. Lmaltier (discussion) 27 mars 2013 à 21:03 (UTC)
Je précise que je comprends très bien la critique dans le cas de la page chat. Mais c'est un cas tout à fait exceptionnel (c'est rare qu'une page ait des sections nom1, nom 2, nom 3), il ne faut pas se baser là-dessus pour définir une politique générale. Lmaltier (discussion) 27 mars 2013 à 21:06 (UTC)
Je ne suis pas forcément d’accord avec tout ce que dit Lmaltier. On ne sait pas exactement ce que le lecteur veut, évidemment. Mais on sait globalement ce qu’il attend. Trouver les informations les plus basiques, d’abord. Et en tant que contributeurs (chevronnés ou non), on a tendance à penser qu’il n’y a pas de problème, ces informations sont accessibles et sont de toute façon présentes dans la page. Ce raisonnement manque d'ouverture face aux IPs qui réalisent l’essentiel des visites du site (et puis on le sait bien, les contributeurs ne contribuent pas pour contribuer, mais pour présenter un contenu accessible et ergonomique). C’est aux « IPs » qu’on doit 55 000 visites par heures (). Il n’est pas courant de voir une table des matières dans une page web, il ne faut pas s’attendre àmha que les IPs manient la table sans aucun complexe. Quand on arrive sur une page avec une table à gauche et rien à droite, on est bouleversé en tant que lecteur. Quand on voit ensuite que seuls les sens de l’adjectif sont définis pour un mot, et pas le nom qu’on cherchait (qui est en fait plus bas), puis qu’on voit une table de traductions, on est encore choqué. Les articles les plus consultés sont les entrées sur les mots les plus courants ; ces articles-là présentent assez souvent une table de traduction, plusieurs sens, et parfois plusieurs types de mot. Seuls des lecteurs habitués peuvent comprendre le fonctionnement et la structure (pas continûment homogène) d’une page du Wiktionnaire. Or les lecteurs habitués ne représentent pas la majorité des lecteurs. C’est dommage de laisser trois fois plus de place aux informations secondaires (traductions, voc. apparenté, pron. API) qu’aux informations primaires (définitions, orthographe(s)) alors que ces dernières ne sont pas mises en valeur particulièrement. La seule manière dans ce cas-là est donc de rendre discrète l’information secondaire. Je suis persuadé que le cas du lecteur qui vient poster ici n’est pas isolé (en témoigne le fait qu’il est rare qu’un lecteur donne son avis ici).
La solution d’utiliser des cookies pour laisser au lecteur la possibilité de dérouler ou enrouler par défaut les boîtes est sûrement la meilleure actuellement àma. Automatik (discussion) 27 mars 2013 à 22:07 (UTC)
C’est compliqué de faire plaisir à tout le monde… Un système à onglet (comme même le CNRTL le fait !) serait sans doute pas mal, mais tant que Mediawiki ne les gère pas en natif c’est impraticable dans les articles.
En ce qui concerne les boites (de traduction et les autres), je rappelle qu’il est possible de les fermer par défaut au cas par cas avec la syntaxe {{trad-début|close=1}}. Cela pourrait peut-être se faire pour les pages très longues. --GaAs27 mars 2013 à 22:35 (UTC)
Les onglets, c'est ce à quoi je faisais allusion. Si on a un onglet pour les traductions, un pour les synonymes, etc, c'est vraiment exaspérant. Si le CNRTL les utilise, c'est quand ? Seulement pour les mots différents écrits pareil ? Ce serait une utilisation intelligente des onglets. La proposition de GaAs (fermeture par défaut des cas particuliers seulement) me semble intéressante. Et que les utilisateurs puissent choisir de cacher les traductions par défaut est aussi intéressant, à condition que ce soit un choix explicite de leur part. L'idéal serait que les choix disponibles soient proposés à la création du compte, mais je ne pense pas que ce soit possible actuellement avec le logiciel. Lmaltier (discussion) 28 mars 2013 à 07:06 (UTC)
Le choix à l’inscription est intéressant mais ce n’est pas une solution à notre problème, ce dont tu parles concerne les inscrits. La plupart des lecteurs ne seront jamais inscrits, c’est à eux qu’il faut proposer une solution, pas à la minorité d’inscrit. PS : Et demander à un lecteur de créer un compte n’est pas une solution. V!v£ l@ Rosière/Murmurer…/28 mars 2013 à 18:27 (UTC)
Ceux qui ne sont pas inscrits, c'est normal qu'ils aient les choix par défaut. Et ne rien cacher, c'est le choix par défaut logique dans presque tous les cas, puisqu'on ne sait pas quels renseignements ils cherchent, ni ce qu'ils préfèrent comme présentation, et qu'ils ne peuvent pas le dire. Lmaltier (discussion) 29 mars 2013 à 21:25 (UTC)
Le CNRTL utilise effectivement des onglets pour « pour les mots différents écrits pareil » (voir justement chat). --GaAs28 mars 2013 à 11:07 (UTC)
Oui, à garder en tête ! Ce serait certainement plus pratique et agréable qu’aujourd'hui (car le sommaire ne marche qu'une fois au début, dès qu'on clique dessus, on descend dans la page et il n’est de fait plus accessible) : un onglet par (langue, mot différent) ; en plus, on n’aurait plus à distinguer les mots dans l’étymologie (et dans une moindre mesure dans les prononciations), ce qui n’est pas forcément terrible. Chris06✍28 mars 2013 à 21:56 (UTC)
Je voudrais quand même rappeler qu'avoir les mots de toutes les langues dans la même page, c'est très précieux pour ceux qui veulent comparer les sens entre langues, ou qui ne sont pas certains de la langue du mot. Lmaltier (discussion) 29 mars 2013 à 21:25 (UTC)
Le choix à l’inscription
J’ai le sentiment que je pourrais écrire du javascript pour le faire. Mais pour tout vous dire, j’en ai vraiment marre qu’on soit obligés de javascripter pour faire bouger les choses. --GaAs28 mars 2013 à 21:45 (UTC)
Question débutant
Quelqu'un peut-il m'aider à créer une page brouillon dans mon espace utilisateur pour m'entrainer, si cela existe comme sur Wikipédia ? (Je connais l'existence du Bac à Sable mais je souhaite une page plus perso, qui ne sera pas éffacée ou indéxée). Merci infiniment. — Ludopedia(Talk)28 mars 2013 à 04:42 (UTC)
Je n’ai pas cherché à voir si le mot était utilisé en français, mais je partage l’indignation du conseil de la langue suédoise : faisons connaître notre mécontentement contre la tentative de Google de contrôler le langage (...). Je suggère de créer l’article ogooglebar rien que pour faire un pied de nez à gougueule (mais on peut indiquer que Google est une marque déposée, ça ne me gène pas). --GaAs28 mars 2013 à 11:02 (UTC)
Ça me fait chier de le dire mais, hélas, il reste les meilleurs pour les recherches liés au Wiktionnaire ; sinon ça ferait belle lurette que j’aurais abandonné leur produits. V!v£ l@ Rosière/Murmurer…/28 mars 2013 à 18:34 (UTC)
Mais non, je n’en vois qu'une. La solution dépend des limites qu'on fixe au modèle :
si l’on ne permet que d’avoir le siècle en fin de la chaine de caractère passée en paramètre ('Milieu du XX', 'Deuxième moitié du XIX', et jamais : 'Milieu du XIX et après'), il suffit de rajouter $ à l’expression régulière : '+$' ;
si c’est la fête du slip par contre et qu’on autorise des caractères après, il faut caractériser plus finement l’occurrence du siècle dans la chaine : « suite d’un ou plusieurs caractères séparée du reste éventuel du texte à gauche et à droite par un espace ou une ponctuation » (la ponctuation, c’est pour chercher la petite bête), ce qui donne 4 combinaisons à tester (en s’arrêtant dès qu'on en trouve une), par ordre de probabilité supposée : '^+$', '+$', '^+', '+'. Je suggèrerais également de laisser tomber LCDM, sachant que le quarantième siècle n’est pas pour demain, et ça aiderait pour les perfs, d’où plutôt les quatre tests suivants : '^+$', '+$', '^+', '+'. Attention aux indices i et j si tu utilises find, ils devront être modifiés suivant le pattern (pour tenir compte de l’espace avant ou après, suivant les cas) : le mieux est peut-être du coup d'utiliser match avec capture : exemple pour le quatrième pattern : d,s,f = mw.ustring.match(txt, '(.*)(+)(.*)'), et plus qu’à faire : d..siecle(s)..f si j’ai bien compris la syntaxe. Chris06✍28 mars 2013 à 23:46 (UTC)
Malheureusement ton truc avec match ne fonctionne pas, et je n’ai pas réussi à le faire fonctionner dans tous les cas. Mais j’ai trouvé une astuce qui m’évite de tester tous les cas et ça donne :
{{siècle|Milieu du VXI, peut-être}} --> (Milieu du VXIe siècle, peut-être)
{{siècle|VXI}} --> (VXIe siècle)
{{siècle|VXI av. J.-C.}} --> (VXIe siècle av. J.-C.)
Bien joué ! J’avais en effet deux cas inutiles (puisque une majuscule termine rarement un mot !), et ta super astuce ramène à un. Chris06✍29 mars 2013 à 22:37 (UTC)
D'habitude on écrit XIIe (ou Ier), pas juste XII (ou I). {{siècle|XVIe siècle}} devrait donc marcher... et ça permettrait de ne pas confondre avec les majuscules normales. — Dakdada4 avril 2013 à 18:08 (UTC)
Parce qu'il était limité techniquement. Avec Lua on pourra écrire plus naturellement (tout en gardant l'ancien comportement). — Dakdada4 avril 2013 à 19:15 (UTC)
Catégories cachées
Bonjour. Il me semble avoir vu une fois un moyen pour pouvoir afficher les catégories cachées en bas de page (par défaut). Ça vous dit quelque chose ? Merci d’avance. Automatik (discussion) 31 mars 2013 à 14:37 (UTC)
Par ailleurs, je tiens à dire qu’en français il existe plusieurs anglais : celui d’Angleterre, d’Écosse, des États-Unis… JackPotte ($♠) 31 mars 2013 à 22:45 (UTC)
Jackpotte, tu dis vraiment les anglais d’Angleterre, d’Écosse, des États-Unis. Pour ma part, je dirais l’anglais d’Angleterre, d’Écosse, des États-Unis. 82.227.182.2081 avril 2013 à 22:53 (UTC)