Bonjour, vous êtes venu ici pour chercher la signification du mot Wiktionnaire:Wikidémie/décembre 2008. Dans DICTIOUS, vous trouverez non seulement toutes les significations du dictionnaire pour le mot Wiktionnaire:Wikidémie/décembre 2008, mais vous apprendrez également son étymologie, ses caractéristiques et comment dire Wiktionnaire:Wikidémie/décembre 2008 au singulier et au pluriel. Tout ce que vous devez savoir sur le mot Wiktionnaire:Wikidémie/décembre 2008 est ici. La définition du mot Wiktionnaire:Wikidémie/décembre 2008 vous aidera à être plus précis et correct lorsque vous parlerez ou écrirez vos textes. Connaître la définition deWiktionnaire:Wikidémie/décembre 2008, ainsi que celles d'autres mots, enrichit votre vocabulaire et vous fournit des ressources linguistiques plus nombreuses et de meilleure qualité.
Le classement par ordre phonétique inverse dans les pages dédiées aux rimes impose d'établir l'ordre général des phonèmes pour le Wiktionnaire. J'ai tenté une proposition de classement général des phonèmes : → voir ici. Merci de vos réactions. En prenant le temps de la réflexion. Stéphane8888discuter2 décembre 2008 à 00:15 (UTC)
J'ai regardé ce que donnait les boites à gauche pour ces 4 wiktionarys avec l'interface paramétrée en anglais (dans les préférences) pour les 4. Je ne vois aucune corrélation avec le résultat obtenu. En particulier de: (qui fonctionne) et fr: (qui ne fonctionne pas) ont leur boite "search" en haut et des menus pas traduits. --Szyx2 décembre 2008 à 21:10 (UTC)
Désolé je me suis trompé de lien (je testais celui de Wikipédia).
J'ai une explication à l'absence de la boîte de recherche sur ce site : il ne connait visiblement pas l'URL indiquée Special:Recherche pour la soumission du formulaire de recherche (même si le formulaire HTML est identifié par un id="searchForm" conforme), et il semble n'accepter que Special:Search (le seul pour lequel il propose sa propre version du formulaire de recherche). Le site supprime tous les autres formulaires (tout comme il supprime aussi tout l'enrichissement CSS et Javascript présent dans les pages, et scinde également tous les tableaux en transformant chaque cellule en paragraphes...). verdy_p4 décembre 2008 à 07:39 (UTC)
Pourtant sur le Wiktionnaire allemand, il détecte bien "Spezial:Suche". Il semblerait que sur le wiktionnaire français il s'attend à trouver Spécial:Recherche et non Special:Recherche. Ici, sur le Wiktionnaire français, on a oublié de paramétrer le nom d'espace "Special:" traduit en "Spécial:" (alors que les deux peuvent coexister) : un seul marche, celui en anglais, alors que sur Wikipédia on a bien ce nom traduit... verdy_p4 décembre 2008 à 07:44 (UTC)
A noter : la ressource MediaWiki:Nstab-special contient une traduction erronée "Spéciale" au lieu de "Spécial" (modifiée par quelqu'un depuis l'import initial en anglais par MediaWikiBot), cela peut expliquer éventuellement les choses si cela ne correspond pas au paramétrage des noms d'espace utilisés ici... verdy_p4 décembre 2008 à 07:50 (UTC)
Autre note : la Wikipédia francophone ne traduit pas non plus l'espace "Special:" en "Spécial:" (voir la même ressource w:MediaWiki:Nstab-special sur Wikipédia) ; elle le faisait auparavant mais cela a été effacé pour je ne sais quelle raison, au lieu d'en faire le nom principal (en gardant le nom anglais en synonyme) dans le paramétrage.
Il semble donc bien que le site 7val.com s'attend à trouver le nom d'espace indiqué dans la ressource MediaWiki:Nstab-special, et rien d'autre.
Aussi je propose qu'on ajoute le nom français "Spécial" en tête dans le paramétrage du Wiktionnaire (en gardant le synonyme anglais "Special" en seconde position), et qu'on modifie la ressource MediaWiki:Nstab-special pour qu'elle indique bien le nom principal en français de l'espace. La même chose serait à faire sur Wikipédia (je suppose que si la ressource traduite a été supprimée de Wikipédia, c'est parce que le paramétrage en français des espaces principaux n'avait pas été fait). verdy_p4 décembre 2008 à 07:55 (UTC)
J'ai essayé de changer MediaWiki:Nstab-special, mais sans effet. D'ailleurs, sur le wiktionnaire allemand, MediaWiki:Nstab-special vaut Spezialseite, et non Spezial. Je suppose donc que Spéciale est correct, et que c'est ailleurs qu'il faut agir. Est-ce qu'il y a une documentation là-dessus quelque part ? Lmaltier4 décembre 2008 à 08:04 (UTC)
Peut-être est-ce tout simplement parce que le Spécial est désormais possible (de même que Média qui remplace Media, et Fichier qui remplace Image). C'est tout récent apparemment. - Dakdada(discuter)15 décembre 2008 à 15:23 (UTC)
Mon bot ajoute des ttbc dans les traductions sous le signe {{trad-trier}}, donc ajoute pas mal de pages dans les catégories correspondantes. De plus, je pense qu'il va falloir qu'on s'attaque un jour à toutes les traductions qui ne sont pas séparées par sens et donc qu'il y aura énormément de pages dans ces catégories.
Est-ce qu'il y a des raisons pour ne pas utiliser les codes de langue dans {{ttbc}} ? Si non, est-ce qu'il y a des gens qui s'opposent à ce que je renomme toutes les catégories ?
J'ai vu ça... Si j'ai uniformisé le code des sous-catégories par langue ce n'est pas pour imposer le nom (par code) c'est pour ne pas avoir à toucher sans arrêt leur code Wiki avec du copier-coller (puisque le code qu'elles affichent est celui inclus depuis de la catégorie mère). Rien n'interdit que ce code inclus utilise le nom complet de langue et non le code. Je peux le faire facilement si tu veux (pas besoin d'un bot, cela se fait facilement à la main) en recréant les catégories avec le nom complet (puisqu'on ne peut pas les renommer simplement). Tu noteras que les catégories par code sont très faciles à créer et qu'elles affichent toutes le nom réel de la langue tel qu'il est généré par le modèle de code. Cela facilitera la création des catégories aevc le nom complet.
Je suis aussi d'avis que le nom complet de la langue serait plus utile (quitte à afficher le code dans le texte de la catégorie). verdy_p6 décembre 2008 à 17:42 (UTC)
Note j'ai commencé le renommage des catégories, mais je prépare un script pour le faire sans trop d'erreurs. Certaines langues sont déjà faites manuellement. Cependant j'ai trouvé plein de catégories redirigées que j'ai annotées pour les repérer.
Les catégories redirigées sont en principe maintenant toutes dans la catégorie:Catégorie redirigée (il reste à savoir lesquelles doivent être conservées, mais il vaut mieux savoir où elles sont et les signaler aux utilisateurs s'ils continuent à y stocker des pages). Note: la bannière de suivi des catégories redirigées autodétecte celles qui ne sont pas vides et celles dont la redirection sible est cassée. Un bot Pywikipedia standard (juste un peu adapté pour traduire les messages en français) sait déjà faire automatiquement le travail de repérage des redirections non annotées ou cassées, mais je vais soumettre à leurs auteurs des corrections car il y a un problème sur certaines fonctions de locale (bogue mineur : formatage des dates dans les messages postés sur les pages de discussion des pages protégées non modifiables par Bot) ce qui l'empêche encore de déplacer les pages encore contenues dans des catégories redirigées. verdy_p7 décembre 2008 à 04:32 (UTC)
Besoin d'un coup de main pour une bricole de monobook
Salut,
Je voudrais changer la couleur du fond des pages en fonction de la présence d'un argument dans un modèle, {{kbbi3}} en l'occurence, j'ai trouvé un bout de code pour changer le fond, ça marche, je voudrais maintenant le lié à la présence d'un argument dans le modèle, {{kbbi3|nocat=oui}} par exemple, qui peut m'aider ??? merci d'avance Serpicozaure(discuter)6 décembre 2008 à 11:41 (UTC)
Le code dans monobook n'a accès qu'à la page générée, pas au code wiki, donc ne pourra pas détecter ton modèle. C'est pour faire quoi ? Si tu veux savoir dans quelles pages il y a cela, le plus facile est de faire un petit programme qui recherche sur un dump XML. Je te montre comment faire si tu veux, c'est très simple. Koxinga6 décembre 2008 à 13:09 (UTC)
Je ne comprend pas bien l'intérêt. Il y a eu un message sur la wikidémie en parlant (ici), mais je n'ai pas vraiment vu de débat à ce sujet et je ne suis pas convaincu du tout. Pour un contributeur, c'est plutôt effrayant de tomber sur des modèles écrits en grec, alors que je ne vois pas le problème pour un bot de faire des remplacements automatisés de texte. Est-ce que ces modèles sont encore utilisés ? Est-ce que ça ne serait pas mieux de s'en débarrasser progressivement ? Koxinga6 décembre 2008 à 21:00 (UTC)
Il faut clairement tous les modifier. Je n'avais pas vu qu'il y avait même des modèles de section (antonymes etc.).
Pour les modèles d'accord, il faudrait les remplacer par quelque chose de compréhensible, en utilisant des noms normalisés, par exemple {{el-nom-m1}} (=déclinaison des noms masculin de groupe 1), etc. en essayant de ne pas utiliser de caractères grecs, sauf éventuellement dans certains cas spéciaux, tout ça étant à résumer dans la page Wiktionnaire:Liste de tous les modèles/Grec. - Dakdada(discuter)6 décembre 2008 à 23:08 (UTC)
Sections communes aux mots à deux orthographes
Il n'y a aucune raison pour que diner et dîner aient des traductions différentes. Cependant, au gré des contributions, il y a soit divergence des contenus soit duplication des efforts. Est-ce qu'on peut en rediriger l'un vers l'autre ou il y a des considérations de neutralité entre les deux orthographes qui nous empêchent de privilégier un des deux articles ? Koxinga7 décembre 2008 à 19:17 (UTC)
Les conventions actuelles sont exposées dans cette page : Convention:Variation orthographique. En bref, il faudrait prendre un des deux articles comme page principal (je dirais dîner), et mettre tout le contenu (autre que les flexions, anagrammes et autres liés à la graphie) dans cette page.
Mais le choix de l'article principal n'est pas forcément simple. En l'occurrence, l'orthographe dîner me semble la plus courante et devrait donc être la principale. Si on hésite entre une graphie traditionnelle et la nouvelle graphie proposée, je pense qu'il vaut mieux rester sur l'ortho traditionnelle. - Dakdada(discuter)7 décembre 2008 à 19:29 (UTC)
Problème: seule l'orthographe diner est correcte en anglais. Hors si on met un seul article, avec une redirection vers dîner, cette orthographe sera incorrecte pour la section en anglais.
Les graphies identiques alternatives ne sont équivalentes qu'en français, mais pas s'uil y a d'autres langues dans la page. Dans ce cas, il faut bien deux articles.
On peut envisager cependant d'inclure la section française dans une sous-page "/fr", et dans laquelle on utilise {{PAGENAME}} sur la ligne de forme au lieu de mettre l'orthographe en dur. Le problème étant que la ligne de forme ou la définition devrait aussi indiquer si c'est l'orthographe traditionnelle ou l'orthographe révisée de 1990. Dans la sous-page il faudrait alors un paramètre pour la partie variable contenant l'indication du type d'orthographe utilisé, et aussi l'autre orthographe si elle doit être mentionnée dans la sous-section "variantes orthographiques"... C'est bien compliqué, et de plus les sous-pages ne fonctionnent pas dans l'espace de noms principal (articles). verdy_p8 décembre 2008 à 18:11 (UTC)
Dakdada ne proposait pas une redirection, mais simplement une section Français réduite pour diner. Personnellement, je suis d'accord avec lui, et c'est la solution la plus simple, mais répéter l'information ne me gêne pas outre-mesure, surtout quand il est difficile de choisir une orthographe principale. Lmaltier8 décembre 2008 à 18:33 (UTC)
À ce sujet, on stocke actuellement les modèles "voir" communs utilisés en début de page dans une pseudo-sous-page "/voir". Ce n'est pas correct car cela donne un nouvel article qui apparait dans la liste des pages de l'espace principal (par exemple avec Special:Random).
Ne peut-on pas envisager la mise en place d'un espace de noms spécifique pour stocker les véritables sous-pages relatives à un article de l'espace principal? Par exemple la pseudo-sous-page a/voir deviendrait sous-page:a/voir (et dans ce cas plus besoin non plus de la Catégorie:Sous-pages).
Note : j'expérimente actuellement les {{métadonnées}} pour gérer le tri spécifique des catégories en espéranto (substitution dans la clé de tri des accents circonflexes par des "x"), en coréen (substitution des syllabes précomposées en "jamos de compatibilité" non précomposés en syllabes), en chinois (clés de tri par radical/nombre de traits ou en pinyin), en japonais (substitution des caractères hiragana et kanji en hiragana uniquement)...
J'envisage donc aussi que la page principale dans cet espace de nom contienne des métadonnées qui sont aussi une sous-page de l'article de l'espace de noms principal (c'est-à-dire sous-page:a/:data au lieu de a/:data au sujet de la page a).
La même solution fonctionnerait aussi pour les sous-pages /voir, par exemple sous-page:a/voir au lieu de :a/voir (et avec donc la possibilité de lier cette page à l'article principal a avec un lien sans avoir à fournir un paramètre dans la sous-page.
La solution fonctionne déjà sur quelques pages de test que j'ai pu faire, mais butte justement sur l'absence de support correct des sous-pages pour l'espace de noms principal.
Ces métadonnées seraient aussi accessibles directement depuis l'article principal qui les référence, simplement en ajoutant {{métadonnées}} en bas de la page (ce modèle se placerait à côté de l'actuelle {{clé de tri}}. Et il sera même possible de supprimer totalement l'appel de {{clé de tri}} dans l'article (ou dans n'importe quel autre page d'un autre espace de noms) pour mettre la clé de tri par défaut de la page avec les autres méta-données, qui seraient de plus maintenant visibles dans la sous-page de métadonnées sans avoir à regarder le code source Wiki de la page.
L'intérêt d'avoir un autre espace de noms est que les "pseudo-modèles" {{BASEPAGENAME}}, {{SUBPAGENAME}} fonctionneraient directement depuis les sous-pages créées dans cet espace dédié, sans avoir à leur passer explicitement en paramètre le nom de la page de base dans l'espace principal lorsqu'on souhaite les inclure dans un article de l'espace principal...
Le but de ces métadonnées est de ne plus encombrer les articles de paramètres inutiles et répétés pour les appels de modèles de forme, de nature grammaticale, ou de terminologie, puisqu'on n'aurait à passer que le code langue de la section correspondante, les autres données partagées pouvant être récupérées par les modèles utilisés directement dans les métadonnées associées à la page courante.
Et ces métadonnées ne sont pas réellement des modèles même si elles doivent être utilisées pour être inclues comme des modèles (je n'ai pas envie de surcharger l'espace des modèles avec des métadonnées de l'espace principal), et contiennent essentiellement un "switch" sur le type de métadonnées demandé (précisé dans le premier paramètre dont la valeur est le nom de la variable de métadonnée à récupérer).
Ces métadonnées ne sont pas faites pour stocker du texte directement visible dans les articles mais de petites valeurs très courtes utilisées par nos modèles utilitaires. Les métadonnées seraient remplies essentiellement par des robots indexeurs qui savent calculer les clés de tri correctement (pour les écritures complexes comme les sinogrammes Han ou Kanji, l'hangûl du coréen, et même pour le cas spécial de l'espéranto), sans avoir à analyser le code wiki trop complexe de nos articles (ce qui produit de complexités énormes dans les expressions régulières et est source de certaines erreurs commises par les Bots).
La syntaxe voulue pour les métadonnées (que j'ai déjà expérimentées et qui fonctionnent déjà pour les métadonnées des modèles par exemple car l'espace "modèle:" supporte les sous-pages) est alors aussi dépouillée que possible, avec une seule variable par ligne dans un format très lisible déjà expliqué dans {{métadonnées}}, ce qui permet aussi de les modifier à la main facilement. Aucun autre code wiki complexe ne devrait y figurer qu'un seul switch (le reste est à faire dans les modèles utilitaires, y compris le fait de calculer des valeurs par défaut si une métadonnée n'est pas renseignée).
Pour les espaces de noms disposant de sous-pages ("discussion:", "projet:", "aide:", "modèle:", "wiktionnaire:"...), il n'est pas nécessaire de les stocker dans un autre espace de noms, mais pour l'espace principal, je ne vois pas d'autre solution pour éviter de polluer l'espace principal avec pseudos-souspages qui ne fonctionnenet pas de la façon attendue (et où le caractère "/" fait partie du nom principal de la page, notamment parmi les catégorie:Abréviations et catégorie:Symboles).
Je n'envisage pas de métadonnées pour les espaces de noms spéciaux ("référence:", "catégorie:", "image:", "méta:", "mediawiki:") qui ne supportent pas non plus les sous-pages. Cependant si des métadonnées ou sous-pages étaient nécessaires aussi pour ces espaces, il leur faudrait un espace de noms dédié à chacun d'eux.
J'ai déjà tout prêt un modèle qui permet de donner le nom de la page de métadonnées depuis n'importe quelle page (y compris la page de métadonnées elle-même), ou le nom de la page associée à la page courante de métadonnées.
D'autre utilisations possibles des métadonnées sont le fait de pouvoir faire un suivi de qualité ou de révision des pages sans avoir à les éditer (on pourrait ajouter des variables de métadonnées éditables, même pour les pages totalement protégées), ce qui serait très utile aux projets gérant des listes de pages à revoir : on ajoute une variable spécifique de métadonnée pour marquer le travail à faire sur un article, on l'enlève une fois le travail fait.
Noter que quand on renomme une page de l'espace principal, cela ne renomme pas en même temps les pseudo-sous-pages, alors que ce serait possible pour les pages des autres espaces possédant des sous-pages (comme cela le fait déjà en renommant aussi la page de discussion associée à une page qui a été renommée).
Le renommage des sous-pages devrait aussi se faire en même temps que celui de la page de base dans le même espace de noms, dans n'importe quel espace supportant les sous-pages (comme "modèle:") mais il ne se fait toujours pas, et c'est un bogue actuel (connu et déjà discuté sur BugZilla) ou une fonctionnalité manquante de Mediawiki (par exemple quand on renomme un modèle, il faut encore renommer aussi la sous-page" /Aide" associée). Ce problème devrait trouver une solution à terme, et je ne pense pas que ce soit une difficulté supplémentaire pour empêcher de déplacer les sous-pages de métadonnées dans un nouvel espace à part. De plus, on renomme très peu d'articles dans le Wiktionnaire puisque l'on conserve des articles pour des graphies alternatives (le renommage n'intervient guère qu'en cas d'erreur comme un accent oublié sur un nom d'article, mais pas pour les flexions des accords au féminin, pluriel ou de cas, ni pour les formes conjuguées des verbes).
Je renonce à comprendre tout ça tant que ce n'est pas expliqué de façon plus courte, plus claire, plus simple, moins incompréhensible. Mais je voudrais dire qu'on n'a pas besoin des sous-pages pour voir : on peut très bien avoir la liste voulue dans chaque page, éventuellement sur plusieurs lignes si c'est trop long, et confier à un robot le soin de mettre tout ça à jour périodiquement. Simplifions ! Lmaltier8 décembre 2008 à 18:33 (UTC)
Un exemple simple pour l'espéranto, montrant comment cela fonctionne : abĥazo (expérimental) qui a deux clés de tri, une normale, et une spécifique à l'espéranto, les deux étant dans la page de métadonnées.
C'est on ne peut plus simple !
Le même article se classe différemment dans Catégorie:Adjectifs en espéranto et dans les autres catégories non spécifiques à l'espéranto. Pour cela il lui suffit de référencer les métadonnées par un appel à {{métadonnées}} qui s'occupe aussi de sélectionner la bonne clé de tri par défaut.
Évidemment le problème est que la page abĥazo/:data n'est pas une vraie sous-page, et est donc incapable de fournir un lien permettant de retourner à l'article lui-même. Cette pseudo-sous-page serait mieux placée dans un autre espace que l'espace principal où les sous-pages ne fonctionnent pas (car BASEPAGENAME retourne le nom de la même pseudo-sous-page et non le nom de la page de base contenant les définitions du mot). Pour pallier à ça, la seule solution est de fournir explicitement le nom de la page de base dans l'appel de {{métadonnées}} fait en fin de page de métadonnées.
Je le répète: ces pages sont à usage interne, et pas destinées à être remplies systématiquement par tout le monde (d'ailleurs c'est aussi vrai pour les clés de tri, que beaucoup ne savent pas non plus positionner correctement). C'est pour ça que ces métadonnées pour les clés de tri devraient être faites par robot (qui auront leur tâche grandement facilitée s'ils n'ont pas à interpréter la syntaxe compliquée de nos articles), de même que les actuelles clés de tri par défaut utilisant {{clé de tri}}.
Le but est justement bien de SIMPLIFIER les articles en n'ayant plus à les encombrer partout de paramètres pour les appels de sous-modèles de forme ou de nature grammaticale (la seule chose encore nécessaire étant le code langue), surtout si ces paramètres doivent être répétés partout.
Je retiens que chez toi, tout ce qui est nouveau est par définition "compliqué". Alors que justement je propose de simplifier ça, et je donne des arguments.
Avant de proposer ça, j'ai bien entendu expérimenté les choses pour montrer la faisabilité. Si c'est "trop long" pour toi (qui visiblement n'aime pas qu'on lui explique les choses), c'est parce que je ne me contente pas de fournir une solution toute faite, mais j'explique les raisons, et comment on peut y parvenir.
Quant au format des métadonnées je me suis arrangé pour qu'il soit le plus lisible possible et quand même facile à éditer par tout un chacun (donc pas de code Wiki compliqué à lire, la première et la dernière ligne étant fixe, on ne doit faire qu'ajouter des lignes de type "variable=valeur|" entre ces deux lignes, lesquelles sont aussi générées par un patron lors de la création de la page). verdy_p8 décembre 2008 à 19:22 (UTC)
Quant à l'argument concernant les sous-pages /voir, il faut bien voir que la raison même de leur existence est qu'on a bien vu que la mise à jour des listes dans chacune des pages ne se faisait pas du tout (et surtout pas avec un robot inexistant), car c'était franchement compliqué pour les utilisateurs. J'ai seulement indiqué que le placement de ces pseudo-sous-pages dans l'espace principal pose problème et que ce n'est pas l'endroit idéal pour les mettre. Mais ces sous-pages ont leur utilité indéniable.
C'est pour ça que je propose de mettre ces sous-pages dans un nouvel espace de noms à part, nommé "sous-page:", dédié aux sous-pages relatives aux articles de l'espace principal, mais supportant la fonctionnalité des sous-pages (il faut que BASEPAGENAME fonctionne dans cet espace).
On peut tout à fait le faire en créant cet espace de noms dans un des espaces privés du Wiktionnaire (numéro 100 et plus) non encore utilisé. verdy_p8 décembre 2008 à 19:33 (UTC)
Verdy, tu devrais lire Lmaltier. Tu nous redis ça en trois lignes maximum, et on en reparle après (note que je suis d'accord avec toi, mais que je ne l'admettrai pas avant que tu aies respecté la règle des trois lignes, que moi je respecte). --Szyx8 décembre 2008 à 19:43 (UTC)
Tu relis les deux premiers paragraphes avant le filet horizontal : c'est l'objet de la demande (un nouvel espace de noms demandé) en 4 lignes. Le reste c'est la justification de la demande. Lmaltier n'a même pas lu ces deux premiers paragraphe (par paresse peut-être ?). (le paragraphe en gras ci-dessus répète exactement la même demande aussi en 3 lignes, que tu n'as pas lu non plus quand tu as posté ta réponse). verdy_p8 décembre 2008 à 20:11 (UTC)
Merci de ne pas me dire ce que j'ai lu et pas lu. J'ai même répondu à cette partie : on n'a pas besoin de ces sous-pages. Lmaltier8 décembre 2008 à 20:15 (UTC)
Pas besoin? Demande toi pourquoi ces pseudo-sous-pages "/voir" ont été créées si le besoin n'était pas là : c'est inutilement compliqué de mettre à jour des listes de mots sur toute une série de pages devant se référencer entre elles. Et en pratique, plein de monde oublie de mettre à jour ces listes sur toutes les pages, et il n'y a AUCUN bot (inutile et compliqué à faire et maintenir) qui le fasse. Et on a d'autres utilisations similaires (comme les imports du DAF qui aurait du se faire dans des sous-pages liées à un article principal, mais qu'on a posté dans un espace de discussion, ce cas pouvant se reproduire pour les imports d'autres dictionnaires ou lexiques). verdy_p8 décembre 2008 à 20:19 (UTC)
Note que si je retenais ta solution (pas besoin), alors il faudrait aussi ne plus utiliser du tout les modèles, et n'avoir que des articles bruts de forme sans aucun appel de modèles. Encore une fois, ce besoin est justifié, et évite des tâches administratives pénibles à faire ultérieurement. C'est un besoin de cohérence de l'ensemble, et qui demande le minimum de travail pour tout le monde, et le minimum de revérifications et de mises à jour ultérieures. verdy_p8 décembre 2008 à 20:24 (UTC)
Note enfin que je ne suis pas favorable à ce qu'on oblige à faire maintenir le Wiktionnaire par des robots (il devrait y en avoir le moins besoin si possible, à cause de la quantité impressionnante de choses qu'ils ont à faire et le traffic et la charge serveur importante qu'ils génèrent lorsqu'ils sont actifs), alors qu'une inclusion unique d'une sous-page simple dans un article a un coût totalement négligeable et invisible (et beaucoup moins important que le coût des mises à jours de listes, même manuelles), et génère moins d'erreurs et d'oublis, avec un bénéfice certain pour tout le monde. verdy_p8 décembre 2008 à 20:30 (UTC)
Je pense au contraire qu'un robot qui ferait ça après chaque dump simplifierait beaucoup les choses et éviterait les erreurs et les oublis. Il est bon d'automatiser ce qui est automatisable, et c'est automatisable. En fait, c'est exactement le même genre de problème que les liens interwikis, où personne ne remet les robots en question. Mais il faudrait l'écrire, bien sûr. Lmaltier8 décembre 2008 à 20:46 (UTC)
Qui fait tourner les robots et quand ? Cette politique est celle consistant à confier la maintenance à quelques utilisateurs privilégiés, qui de plus deviennent "asservis" à cette tâche. Je ne vois aucune "simplification" là dedans. Un robot doit surtout servir pour faire des corrections massives en cas d'erreurs fréquentes, ou en cas d'insuffisance des outils automatiques déjà en place (comme les modèles), ces insuffisances (de modèles) étant à corriger pour éviter ensuite d'avoir à continuer cette tâche par robot.
Un bon robot est un robot dont on n'a pas besoin trop souvent.
Tu noteras que je ne critique pas ce que font les robots actuellement. Mais même pour les liens interwikis, la Fondation travaille sur une solution permettant de se passer des robots pour cette tâche de maintenance (impossible à automatiser directement sur le serveur car les wikis ne savent pas ce qui se passent sur les autres wikis).
On sait ce que cela donne quand ces robots commencent à ne plus fonctionner ou ne tournent plus à cause de nouveaux problèmes ou d'ambiguïtés qu'ils ne parviennent plus à résoudre. Ensuite on se retrouve avec des pages de listes d'exceptions et une longue liste de taĉhes à faire manuellement, que personne n'a le temps ou le courage d'attaquer.
Il suffit de voir la liste des tâches à faire sur Wikipédia pour se convaincre que les robots ne sont pas une solution viable à terme pour faire de la maintenance, car les robots sont moins efficaces (et plus mal acceptés) que les tâches que le serveur peut faire automatiquement à un coût nettement moindre. Ici sur le Wiktionnaire, on a réussi à se passer des robots, et pourtant on a pu créer le plus gros dictionnaire (avec beaucoup moins de monde et beaucoup moins de corrections dans les articles que sur le Wiktionnaire anglophone par exemple) comportant le moins d'erreurs grace à une automatisation faite par le serveur lui-même à l'aide de l'utilisation très fine des modèles pour la génération des contenus et leur classification et indexation. Et quoi qu'on fasse, les robots seront toujours en retard s'ils doivent se baser sur des "dumps" de base de données. verdy_p8 décembre 2008 à 20:59 (UTC)
Pour votre information, j'ai travaillé pendant 13 ans dans le monde de l'édition et de la presse, et fait des logiciels destinés aux guides, annuaires, encyclopédies, journaux et magazines (notamment leurs bases de données de gestion des contenus, articles, publicités, réservation d'espace de parution, et la gestion des révisions et "bons à tirer", et des "chemins de fer" qui sont les listes de tâches à faire et compléter pour arriver à la parution finalisée). On a toujours eu besoin de gérer des métadonnées pour organiser les informations, les annoter, et les retrouver facilement.
Ici sur le Wikitionnaire nos outils "équivalents" et utilisables pour gérer ça sont les modèles, les catégories et les espaces de noms (et les sous-pages... sauf dans l'espace principal qui n'en veut pas). verdy_p8 décembre 2008 à 21:22 (UTC)
Ta proposition est séduisante. Mais peu de contributeur connaisse l'existence de ces sous pages "voir". Je ne suis pas sûr qu'il y en ait beaucoup d'ailleurs. Y a-t-il vraiment urgence à créer ce nouvel espace de nommage ? Le seul "préjudice" actuel serait de "tomber au hasard" sur une ces sous pages (sur plus d'un million de page...). Je sais que c'est reculer pour mieux sauter mais : on pourra toujours le faire plus tard... quand le besoin se fera sentir. Non ? Stéphane8888discuter8 décembre 2008 à 21:53 (UTC)
Bon ça y est enfin j'ai tout lu, et à peu près compris. L'intérêt des métadonnées est de pouvoir utiliser différentes clés de tri. L'intérêt d'un nouvel espace de nommage est d'utiliser ces métadonnées proprement (?). J'imagine que cela rejoint les (méta)données relatives aux langues, et les clés de tri pour les rimes (?) Stéphane8888discuter9 décembre 2008 à 14:50 (UTC)
Le besoin est là. Le préjudice actuel c'est surtout toutes les pages qui ne fonctionnent pas correctement dans les catégories, tous les modèles inutilement compliqués, etc. Par exemple, si je suis convaincu par les propositions de Verdy p, je peux créer une sous-page comme cela pour tous les sinogrammes, avec un bot, et m'en servir pour rendre enfin utilisable les catégories dédiées aux sinogrammes et simplifier les modèles dédiés au chinois. Koxinga9 décembre 2008 à 12:32 (UTC)
Je commence à voir l'intérêt de ce que tu proposes (j'imagine déjà un espace de nommage MétaDonnées). Mais par pitié, peux-tu rédiger de manière plus synthétique ? Tu nous noies dans tous tes textes, et on a alors du mal à saisir facilement ce que tu veux dire. - Dakdada(discuter)9 décembre 2008 à 13:36 (UTC)
Il y a la clé, le nombre de traits, différentes méthodes de saisie, les codes Unicode et Big5.
Concrètement, tout cela est rentré par un bot, est illisible pour le commun des mortels et peut effrayer les gens qui veulent juste corriger une faute d'orthographe dans les définitions. Juste en dessous, il y a les informations sur le classement dans les dictionnaires, qui ont aussi été entrées par un bot mais ne sont même pas dans un modèle. Si on repousse tout ça dans une sous-page, on peut écrire {{sinogramme-infos}} en haut de la page, et générer le résultat voulu sans obscurcir la source de la page. Koxinga9 décembre 2008 à 18:31 (UTC)
Tu as tout compris de l'intérêt de la séparation des métadonnées dans une sous-page. Note: je n'ai PAS proposé un espace de nommage pour les métadonnées: un seul espace pour les sous-pages de l'espace principal suffit amplement puisque les métadonnées seront dans des sous-pages ayant un nom "/:data" spécifique dans cet espace et qui ne risque pas de renter en collision avec tout besoin futur d'autres sous-pages (ou actuel pour "/voir").
Effectivement on peut y stocker des informations contextuelles évitant de noyer les articles sous des appels de modèles avec des paramètres optionnels absconds pour des cas particuliers. En revanche les métadonnées ne sont pas là pour fournir des paramètres indispensables aux modèles utilisés : si les paramètres sont obligatoires ou presque systématiques, et sont destinés à fournir du texte affiché, ces paramètres devraient rester dans le corps de la page avec l'appel du modèle. Immédiatement il ne resterait plus comme appels qu'à fournir le code langue, le seul paramètre réellement contextuel à partir duquel on peut récupérer les autres paramètres liés à la langue dans des métadonnées. verdy_p15 décembre 2008 à 20:00 (UTC)
Ce qu'il faut avant tout, quand on a un problème, c'est prendre le temps de discuter ensemble pour trouver la meilleure solution, ce n'est pas grave si ça prend du temps. Si on se lance trop vite sans discussion, et à grande échelle, ce n'est pas étonnant de trouver des inconvénients plus tard.
N'est-ce pas ce que j'ai fait, discuter pour voir quels problèmes cela peut générer et quels problèmes surtoutcela aide à résoudre ? Je n'ai pas lancé de robot de modification à grande échelle. J'ai une paire d'articles en espéranto qui utilisent ces métadonnées à titre de démonstration pour montrer comment cela simplifie la gestion du tri spécifique pour l'espéranto, et comment on peut l'utiliser aussi pour trier le chinois et le coréen, ou encore trier les termes par rime (ma marotte, vous direz, mais je suis convaincu que les annexes ne sont pas viables et demandent un travail considérable de maintenance ou même simplement de création uniquement pour le français, alors qu'on peut les généraliser bien plus facilement en créant des catégories appropriées gérées par métadonnées: ces catégories remplies, il devient nettement plus facile de générer les pages annexes de rimes, de façon presque automatique). Je peux faire la démonstration aussi pour le chinois et le coréen. Je démontre aussi déjà dans ces exemples que les clés de tri par défaut des articles ne sont plus cachées dans le code Wiki mais accessibles directement en consultant les métadonnées avec le lien en bas de page. La complexité des concepts est déjà hautement simplifiée gràce aux modèles que j'ai déjà écrits. Il n'y a aucune pollution des articles. Globalement {{métadonnées}} peut compléter, ou mieux remplacer totalement, l'appel à {{clé de tri}}, exactement au même endroit, et sans qu'il soit nécessaire de fournir le moindre paramètre.
Vous remarquerez que j'ai pris aussi le soin de fournir les liens assistants pour la création des métadonnées: il suffit de mettre le modèle {{métadonnées}} en bas d'article et de se laisser guider par le lien en bas, une fois l'article sauvegardé, le lien "créer" fournit un modèle prérempli si vous voulez créer des métadonnées à la main. Essayez ! Cela n'a absolument rien de compliqué tout est expliqué !). verdy_p15 décembre 2008 à 20:00 (UTC)
Et quand on en trouve, ce n'est pas une raison pour considérer qu'il y a un besoin supplémentaire de compliquer les concepts. Pour l'exemple donné, je ne pense pas que ce soit mieux de cacher les choses compliquées, il serait préférable qu'elles soient simples (ce qui est peut-être difficile dans ce cas précis, c'est vrai). Moi qui suis très expérimenté sur le Wiktionnaire, et en plus un professionnel du web, je n'y comprends rien. Je n'ose pas imaginer ce que ça peut donner pour les autres. On nous a assez dit qu'on était beaucoup trop compliqué, et qu'on décourageait les gens de contribuer à cause de ça, je commence à pouvoir témoigner personnellement que c'est vrai. Lmaltier9 décembre 2008 à 18:57 (UTC)
On a déjà des outils qui cachent du code compliqué : les modèles. Inclure {{-adj-}} est lisible et "assez simple" à coder, alors qu'il serait totalement illisible, et incorrigeable (sans erreur) d'inclure pour chaque adjectif le code suivant : {{-déf-|Adjectif|
|type=Adjectifs
|code=adj
|num=1
|langue=fr
}} alors pourquoi pas cette page Métadonnées qui, du reste, et moins "cachée" que le contenu d'un modèle, grâce au lien présent en bas de l'article (« Cette page dispose de métadonnées stockées dans sa sous-page /:data. »). La "complexification" née de ces Métadonnées, n'empêche pas le contributeur lambda de demander une évolution (comme aujourd'hui pour les modèles). Stéphane8888discuter10 décembre 2008 à 14:37 (UTC)
Tu noteras que j'ai modifié le texte de ce lien en bas de page pour ne plus montrer par défaut le nom de la sous-page de métadonnées. Le lien suffit et le texte qui apparaît lorsqu'on insère {{métadonnées}} en bas d'un article est maintenant simplement : « Cette page dispose d'une sous-page de métadonnées. » la partie en gras étant le lien vers cette sous-page. Bref rien qui pollue l'impression ou l'apparence globale de l'article. Ce lien apparaît juste au dessus de la liste des noms de catégories (qui ne sont aussi qu'un type particulier mais restreint de métadonnées, les autres métadonnées actuelles étant les interwikis qui s'affichent dans la barre latérale), dans un petit cadre horizontal style assez proche (toutefois j'ai écrit ce lien en plus petits caractères et je l'ai centré pour éviter toute confusion visuelle avec la liste des noms de catégories où se classe la page).
Je gère aussi déjà les métadonnées pour d'autres espaces de noms comme les modèles. L'intérêt d'avoir un espace de nom spécifique pour toutes les sous-pages de l'espace principal apparaît dans le code à inclure dans les sous-pages de métadonnées : comme l'espace principal ne gère pas les sous-pages, il faut encore indiquer le nom de l'article dans le paramètre donné à {{métadonnées}} à l'intérieur de la sous-page (sinon il n'y a plus de lien correct de retour à l'article lui-même car la pseudo-sous-page n'a aucun moyen de connaître sa page de base). L'alternative à cet espace de nom spécifique serait d'activer les sous-pages aussi dans l'espace principal (dans ce cas, rien n'est à toucher dans le code des modèles : les pages ":xxx/voir" deviennent automatiquement des sous-pages dans cet espace principal, et les modèles actuels pour "/voir" ou pour les métadonnées devraient déjà fonctionner, sans avoir à préciser le nom de la page de base).
D'aillerus je me demande si ce ne serait pas tout bonnement la meilleure solution: on peut se demander pourquoi l'espace principal ne gère pas les sous-pages, même s'il y a quelques articles dont le nom doit contenir un "/" comme partie intégrante du nom : cette poignée d'articles ne concerne normalement que quelques abréviations comme "c/o" et des symboles d'unités de mesure (ce n'est pas très grave si ils sont classés comme sous-pages d'un autre article, cela n'influencera pas tellement les statistiques ; noter que même s'il y a un "/" dans un tel nom, il n'y aura pas de "/:" et c'est aussi pour ça que j'ai réfléchi au nom "/:data" qui utilise un ":" au début du nom de la sous-page : aucune collision possible). verdy_p15 décembre 2008 à 20:16 (UTC)
Cela n'est pas le Wiktonnaire, mais il y a quelques ressemblances
En résumé : Wikipédia est un MMORPG (Jeu de rôle en ligne massivement multijoueur) « ayant déjà attiré plus de 10 millions de rôlistes dans le monde » (soit mieux que la plupart) dont l'objectif est d'amasser plus de contributions à points que les autres contributeurs. Ces points peuvent être obtenus aussi bien en étant plus méchant que les autres qu'en étant plus gentil, mais dans tous les cas le but est le pouvoir.
Je ne souscrit pas à tout ce qui est dit sur cette page, mais je trouve l'analyse sociologiquement intéressante. --Szyx8 décembre 2008 à 18:45 (UTC)
Je me questionne sur l’utilisation du modèle angl. Quand un mot est-il considéré comme un anglicisme ? Pour moi parking n’est (doublement) pas un anglicisme dans la mesure où le terme a été lexicalisé (depuis bientôt 30 ans) et que le mot n’existe pas en anglais (cf. en:parking). Doit-on qualifier d’anglicisme tout les emprunts à l’anglais ? (et utilise ce modèle sur redingote ?). Surtout : quels sont les critères ? Cdlt, VIGNERON * discut.8 décembre 2008 à 12:16 (UTC)
Spécifiquement dans le cas de redingote, à partir du moment ou le mot a été francisé on peut difficilement parler d'anglicisme. À mon avis, il faut que le mot ait une consonance anglaise (et vienne effectivement de l'anglais, sinon c'est un faux anglicisme, comme les exemples ci-dessus) pour qu'il soit qualifié d'anglicisme. - Dakdada(discuter)8 décembre 2008 à 20:16 (UTC)
La consonnance n’est clairement pas une critère nécessaire et suffisant pour être qualifié d’anglicisme. Éléphant sonne comme elephant mais ce n’est clairement pas un anglicisme. Inversement, ça le fait ne sonne pas du tout anglais et pourtant il est listé comme anglicisme (anglicisme par calque). Le critère de base est que le mot soit emprunté de l’anglais, mais ensuite quand cesse-t-il d’être un anglicisme ? Tout les emprunts sont-ils des anglicismes ?
Effectivement. A noter : la catégorie des faux anglicismes existe déjà, et a été proposée à la suppression, mais je la défends. Lmaltier8 décembre 2008 à 20:49 (UTC)
Si en plus il faut considérer les calques... autant carrément ne pas utiliser le terme anglicisme alors (et donc pas son éventuelle valeur péjorative) !
Par exemple on pourrait se concentrer sur trois catégories d'« étymologies étrangères » : emprunt, calque, et faux-emprunt (exclusives, suffisantes et objectives je pense). En plus elles peuvent être utilisés pour les termes empruntés de toutes les langues. - Dakdada(discuter)8 décembre 2008 à 20:50 (UTC)
Pour ceux qui ne connaissent pas, Kiwix permet d'avoir une version hors ligne du Wiktionnaire sur votre ordinateur.
Sans pouvoir la modifier, bien sûr. Et sans accès au texte de la GFDL, ce qui est mal.
Mais c'est ce qui est le but premier de la Fundation : permettre l'accès à la connaissance à tous. Bien, quoi. --Szyx9 décembre 2008 à 00:53 (UTC)
Page dédiée : Étymologie de la langue française
Le dictionnaire étymologique tchèque que je consulte régulièrement pour les articles dans cette langue que je crée comporte un système de renvoi à une page générale de l'évolution étymologique depuis l'indoeuropéen commun vers le protoslave puis du protoslave vers le tchèque.
C'est intéressant puisque cela permet au locuteur étranger de rendre familier un mot qui autrement serait totalement abstrait.
par exemple hlava (« tête ») du protoslave *golva que l'on rapproche du latin calva (« crâne ») et calvus (« chauve »).
=> B8 renvoie au chapitre Métathèse du l et du r dans les langues slaves et C2 au chapitre Amuïssement du g en h en tchèque
On pourrait avoir la même chose ici avec une page dédiée qui explique les grands traits de la mutation du français depuis le latin et sans trop allourdir les pages donner la possibilité au curieux de découvrir par un système de renvoie à des têtes de chapitre
par exemple chèvre : du latin capra (sens identique).
=> ou X Y Z renverraient à des chapitres sur la palatalisation du k en ch ; la diphtomgation du a en ie ; la monophtongation du ie en è ; le voisement du p en b puis l'assourdissement du b en v ; la chute de la consonne finale (j'ai choisi un exemple avec trop de mutations ;-)
J'aime le double système Lettre/Chiffre car il permet de mémoriser rapidement les grands traits de l'évolution. Je ne sais pas si une telle identation serait faisable. Si je m'appuie sur le dico que j'ai entre les mains cela pourrait donner :
A Du protoindoeuropéen au latin
B Du latin au protofrançais, lingua romana
C Mutations de l'ancien français
D Mutations du français moderne
E Autres (analogie, contamination, tabou, étymologie populaire)
Désolé pour les edits anonymes de mon bot, je n'avais pas vu qu'il avait des problèmes pour s'identifier ... Par contre, je croyais qu'un anonyme ne pouvait pas éditer avec l'API, comme le fait un bot. C'est un réglage spécifique aux projets ? Koxinga10 décembre 2008 à 22:24 (UTC)
Je pose la question : Wiktionnaire payant ?
Je viens de voir sur Macbidouille un article du 11-12-2008 intitulé « Un logiciel basé sur Wikimedia pour une consultation hors-ligne » dans lequel on parle d'une compagnie française Linterweb développant une application gratuite nommé Kiwix permettant de consulter de façon hors-ligne les bases de données Wikimedia : Wikipedia, Wiktionnaire, Wikibooks, Wikiquote, et Wikisource.
Certes, pourquoi pas ?
Mais, en consultant le site à la page , je lis que « La fondation Wikimedia nous autorise à utiliser la marque Wikipedia. Nous avons édité un premier CD contenant une sélection de 2000 articles anglophones... »
Je ne sais pas où se trouve ce CD, s'il est payant et au bénéfice de qui.
Y-aura-t-il un CD de Wiktionnaire ?, payant ?, et au bénéfice de qui ?
Ce premier CD coûte 11,59 euros, port compris. Vous pouvez vous le procurer sur WikipediaOnDVD au profit de Linterweb sans doute ?. La prose de la page (en anglais) est très intéressante...
Suite à la discussion Wiktionnaire:Wikidémie/novembre 2008#Édition par section (elle-même reprenant un très vieux débat dont on retrouve les dernières traces ici : Wikidémie de novembre 2007), je voudrais proposer de rendre modifiables les sections de langue, qui ne sont pas modifiables actuellement pour des raisons techniques.
Oui, ça aurait pu être discuté, mais la discussion est ici, quand même, beaucoup moins indispensable que quand on veut modifier des modèles utilisés à grande échelle (et quand en plus on reproche aux autres de ne pas respecter ce qu'on a décidé tout seul dans son coin sans discussion...) Lmaltier12 décembre 2008 à 15:23 (UTC)
Prix du Wiktionnaire
pour le prix de la catégorie la plus fantaisiste, je nomine Catégorie:Prénoms en espéranto, ou comment créer des prénoms que personne ne porte réellement et les appliquer dans un monde virtuel. Ma recherche sur Ksavero donne que meme la wikipedia esperantiste nomme l'article sur saint Francois Xavier Francisco Xavier.
ps * - autopromouvoir n'est pas seulement pronominal, d'ailleurs tous les verbes pronominaux en auto- devraient etre annotés comme redondants et synonymes de la forme pronominale sans auto- : se promouvoir ( = promouvoir soi-même), dérivés corrects et non redondants : autopromotion, autopromu, etc.
Au prorata du nombre d'articles , le prix du Wiktionnaire est actuellement (voir le bandeau en haut de page) :
$ 3 618 444 * 1 140 056 / 17 746 708 = $ 232 450
Pas terrible. --Szyx 12 décembre 2008 à 16:38 (UTC) Personne n'avait remarqué que je m'étais trompé d'un facteur 10 ! --Szyx14 décembre 2008 à 17:48 (UTC)
Je trouve que la manière de présenter (visuellement) les traductions sur le wiktionnaire anglophone est plus agréable que celle employée dans la plupart des articles en français :
utilisation d'une boîte déroulante
une boîte à traduction par sens possible du mot
boîte "fermée" par défaut
Ça permet, pour les mots ayant de nombreux voire très nombreux sens différents, de retrouver plus facilement la traduction qui nous intéresse.
Par ailleurs, je trouve ça très bien que notre modèle trad ajoute un lien vers l'article correspondant du wiktionnaire de la langue cible en exposant. Et j'aimerais bien qu'on propose aux germanophones d'adopter cette fonctionnalité dans leur modèle : c'est tellement pratique. Eiku13 décembre 2008 à 17:29 (UTC)
Même si elles sont pratiques, techniquement, une boîte déroulante ce n’est vraiment pas génial (temps de chargement plus long de la page, problème d’accessibilité, utilisation du Javascript donc dysfonctionnement, etc.). Pour ta seconde proposition, va plutôt sur de:Wiktionary:Fragen zum Wiktionary. Cdlt, VIGNERON * discut.13 décembre 2008 à 17:39 (UTC)
Les boites sont utiles pour les sections traductions volumineuse (un écran sur plusieurs colonnes par exemple), mais pour les petites sections je trouve que ça complique inutilement le code et que ça freine l'accès à l'information. Et parfois la boite est vide !! Par exemple dans sous le manteau, que je simplifierais volontiers. Stéphane8888discuter13 décembre 2008 à 18:05 (UTC)
Je reviens à la charge avec mon code Utilisateur:Koxinga/monobook.js. Il compte le nombre de lignes et n'enroule la boîte que si ce nombre est supérieur à une certaine limite. Ce n'est pas encore très propre, mais j'aimerais bien avoir des retours d'utilisateurs. Pour le tester, il suffit de copier le code dans votre monobook.js. Moi je vois les deux boîtes déroulées dans sous le manteau et c'est beaucoup plus pratique.
Je vais essayer de l'améliorer pour que lorsqu'il y a trop d'entrées, les boîtes ne s'enroulent pas complètement mais cachent une partie des entrées (affichent les dix première lignes et un lien qui dit clairement qu'il y en a plus en dessous.
Je pense qu'une boîte est très intéressante losqu'il y a beaucoup de traductions, qu'elle ne sert à rien si elle est ouverte par défaut, et qu'elle cache trop les informations si elle est fermée par défaut. Il faut donc trouver un compromis. Koxinga13 décembre 2008 à 18:23 (UTC)
Tu sais que je suis plus que favorable à ton action, mais copier du code comme cela sans comprendre, non. --Szyx14 décembre 2008 à 18:12 (UTC)
Pourquoi ? Tu as peur que je te pirate ton monobook ? Je ne comprend pas du tout, tu es favorable mais tu refuses d'essayer pour me donner ton avis, vérifier que ça fonctionne, proposer des améliorations, etc. Qu'est-ce que je dois faire alors ? T'expliquer le code ? Koxinga14 décembre 2008 à 21:03 (UTC)
J'ai maintenant essayé... ça marche très bien. Parfois, c'est bizarre d'avoir la boîte la moins visible (celle qui ne s'ouvre pas) qui pourtant est celle la plus étoffée. Comme dans embrasser. La boîte étant d'un bleu proche de celui des sections de langue, ça parait découper la page, finalement davantage qu'une sous-section (comme Prononciation, ...). Exemple dans : abdomen. Je précise que ça ne marche pas seulement pour les traductions, mais pour toute section utilisant ces boîtes : exemple avec les Méronymes de Jupiter. Je conserve ce monobook, pour tester à fond. Stéphane8888discuter14 décembre 2008 à 23:23 (UTC)
Je trouve aussi que c'est gênant et j'y avais pensé avant. Est-ce que vous pouvez essayer le nouveau code sur Utilisateur:Koxinga/monobook.js ? S'il y a trop de lignes, il n'affiche que les premières et indique qu'il y en a plus. Il y a encore des petits problèmes, comme la coupure dans le tableau une fois déroulée, mais je ne vais essayer de les résoudre que s'il y a un peu d'intérêt pour cette solution.
J'ai testé aussi, c'est bien. Le fait que les boites restent un peu ouvertes montre ce qu'elles contiennent (rien dans sous le manteau ; quelque chose dans embrasser). Et ça évite d'avoir juste un bandeau bleu (analogue à celui des sections de langues). Juste un détail, j'ai un décalage dans les colonnes quand je déroule une boîte à 3 colonnes. Exemple avec les boîtes Traduction et Méronymes de l'article Jupiter. Stéphane8888discuter20 décembre 2008 à 22:46 (UTC)
Est-ce que tu peux essayer avec la dernière version ? Je n'ai aucun problème sur l'article Jupiter. Le petit détail qui coince, c'est quand on a de grandes lignes sur une des deux colonnes, les autres s'arrêtent quand même à huit lignes, donc il y a du blanc qui est rempli quand on demande d'afficher tout. Ce n'est pas très intuitif mais je ne vois pas trop comment l'éviter. Koxinga20 décembre 2008 à 22:54 (UTC)
Je me demandais si il ne serait pas possible d’implémenter le moteur avec une fonction du genre de celle des moteurs de recherches pour les mots croisés. Par exemple, trouver tout les mots qui commencent par "abg" (il n’y en a qu’un à ma connaissance et il n’a pas son article sur le wikt), les mots qui finissent XXX, les mots qui contiennent XXX, voir des fonctions un peu plus compliqué comme "mots sans voyelles", "mots sans consonnes", "lipogramme en X", etc. Quelqu’un aurait les moyens de développer (ou implanter si cela existe ailleurs en libre) cela ? Cdlt, VIGNERON * discut.13 décembre 2008 à 17:39 (UTC)
Il faudrait demander une extension pour ça (il y en a peut-être déjà... à voir). En attendant, j'ai une page qui peut jouer ce rôle à cette adresse, même si elle est restreinte au français pour l'instant. - Dakdada(discuter)13 décembre 2008 à 17:56 (UTC)
Demander où ? (sur Bugzilla ? ils ont pas trop le temps apparemment). Ta page est génial, je connaissais ce genre de moteur pour des dictionnaires externes mais sur la base de données du Wiktionnaire c’est bien plus puissant. Tu es développeur ? Tu pourrais voir sur Bugzilla avec les devs de MediaWiki pour intégrer cela dans les pages spéciales ? On peut faire des suggestion d’améliorations aussi ? (un bouton de sélection de langue serait génial). Cdlt, VIGNERON * discut.13 décembre 2008 à 18:08 (UTC)
Je viens justement d'embêter Dakdada pour que son bidule génial outil ne censure pas les mots étrangers de la majorité des humains. --Szyx14 décembre 2008 à 18:08 (UTC)
Je suis en train de mettre à jour et d'ajouter quelques fonctionnalités dont la possibilité de choisir la langue, ainsi que le type de mot, ou encore choisir d'exclure les flexions. Un nouvel affichage plus détaillé des requêtes est aussi en travaux... Il y a encore du travail . N'hésitez pas à demander d'autres choses que je pourrais implémenter.
Pour ce qui est d'inclure ça dans le Wiktionnaire, ça me semble très difficile, du moins directement. Mais je pense qu'une bonne idée serait de migrer tout mon bazar sur un serveur de Wikimedia (meta:Toolserver), et de proposer de faire des requètes sur cette page. - Dakdada(discuter)14 décembre 2008 à 20:55 (UTC)
Déplacer cela sur le toolserver est une excellente idée, le type de mot, les flexions aussi. Tu pourrais en proposer des traductions (je pourrais t’aider) pour tout les wiktionnaires. Je pense même que l’on pourrait à terme faire un lien depuis Spécial:Recherche. Cdlt, VIGNERON * discut.17 décembre 2008 à 08:13 (UTC)
Pages « à faire »
Je vous soumets une idee discutee il y a peu avec Moyogo. Je mets en gras ce que je pense important.
Je peux te demander c'est quoi la sous-page antidico que tu as créé ? j'ai créé un mot qui pointe vers capabilité et m'étonnant que le mot n'existe pas, je cherche ce qui pointe dessus (un bon test pour vérifier si un mot "existe", est "reconnu") et je vois que cette sous-page est la seule à le reconnaitre :-(
De manière plus générale, cela fait un certain temps que je comptais te contacter pour valider une idée que j'avais en tête. Tu as fait des pages "mots manquants" qui m'ont été tres utiles dans ma manie de compléter le dictionnaire. Darkada, sur ma demande a créé la page des mots manquants en francais mais existant sur le wiktionnaire vietnamien (voir ici, là, et là.
Notre page Wiktionnaire:Proposer un mot est un peu bordélique et peu structurée pour des participants qui voudraient améliorer de manière un peu systématique. La page du wiktionary en:Wiktionary:Requested entries:English me fait tres envie, c'est comme ça que je verrais Proposer un mot évoluer. Ou faire une page séparée qui recense tous les mots que l'on n'a pas par ordre alphabétique (dont une partie est aussi stockée dans Wiktionnaire:Mot du jour).
Salut Diligent. Les pages des mots de l’Antidico sont assez utiles parfois. C’est vrai qu’il serait utile d’avoir une liste alphabétique de tout les mots attestés et manquants comme sur le wiktionary. Peut-être qu’un bot peut créer cette liste à partir des listes existantes (comme les miennes) en les comparants à la liste des mots français créés. --moyogo/ ⁽ᵈⁱˢᶜᵘᵗᵉʳ⁾28 novembre 2008 à 07:42 (UTC)
La page Wiktionnaire:Mot du jour pourrait pointer vers ces pages (un peu comme cela se fait pour la page collaboration de la semaine qui recense les 52 sous-pages).
Cette proposition est plus ou moins calquée sur la page d’accueil anglophone, elle ne reprend pas encore des sous-modèles pour les cadres mais contient tous les éléments de l’accueil actuel, correctement reclassés de façon logique, et agencés par importance. Elle apporte un meilleure vision de ce qu'est le Wiktionnaire.
Les couleurs et cadres sont uniformisés (tous bleu ciel pour ce qui concerne directement le Wiktionnaire francophone, gris clair pour les autres projets), les liens triés par type, les éléments importants pour la navigation sont dans le cadre du haut sous forme très condensée. Tout y est même les parties variables (mot du jour, projet de la semaine, annonce éventuelle). Les couleurs évidemment ça se discute, mais je voudrais éviter le "patchwork" multicolore inutile et lourd : éviter le rouge qui repousse ou semble signaler un problème, éviter le tout gris trop triste.
Mais pourquoi pas l'orange clair pour les bordures de cadre et un jaune paille ou un vert pâle pour les fonds, ou encore une différence de couleur entre d'une part les cadres horizontaux (en haut de page et dans l'index général qui étend l'index résumé dans la cadre du haut) et d'autre part les autres cadres bleus dans la partie centrale en deux colonnes.
J'ai tenté de définir un équilibrage à peu près stable des deux colonnes, mais une solution technique à base de tableau est plus délicate à mettre en œuvre pour gérer des bordures de cadre espacées, sachant que les cadres ne s'alignent pas nécessairement entre la droite et la gauche car ils ne sont pas en même nombre, ni de toute façon de même taille relative (vouloir les aligner dans un tableau augmenterait la hauteur totale de page et créerait davantage d'espaces blancs verticaux dans la page.
Je sais aussi que deux des icônes des coins supérieurs gauches de cadre ne sont pas sur fond transparent mais sur fond blanc, si vous avez des propositions d'icônes à fond transparent, je suis preneur.
Bien entendu les sous-cadres seront remis dans les modèles des cadres actuels, si la proposition est retenue avec des modification encore à faire : si j'ai copié les contenus de ces cadres c'est pour pouvoir les intégrer aux cadres du nouveau "look" et déplacer leur icône dans le coin supérieur gauche, sans avoir à créer plein de sous-pages supplémentaires qu'il faudraient ensuite modifier une par une : dans l'immédiat la page fonctionne telle quelle ; si vous le voulez je peux découper la page en sous-pages séparées pour chaque cadre.
Ma foi, ça me plait bien... bien sûr il reste quelques choses à peaufiner, comme le texte d'intro un peu trop long à mon goût (et écrit trop petit), où les couleurs un peu tristes/homogènes, un peu trop proches de celles du Wiktio anglophone (faudrait pas qu'on nous accuse de plagiat ), et je suis sûr qu'on pourra encore trouver des idées pour l'améliorer. Mais au moins la mise en page me parait meilleure qu'actuellement. - Dakdada(discuter)15 décembre 2008 à 08:41 (UTC)
Quel est le problème de "plagiat" ? OK j'ai dit qu'on devrait sans doute changer les couleurs, sans créer un patchwork... Rappel quand même: c'est encore une ébauche. Je vais essayer d'autres couleurs. verdy_p15 décembre 2008 à 12:12 (UTC)
J'ai aussi Firefox 3, et je n'ai pas de problème là-dessus. Mes remarques :
je rajouterais de langue après dictionnaire dans la phrase de titre, c'est important
Je ne vois absolument pas de quoi tu parles ici ! Le titre (en texte dans le cadre du haut) correspond exactement au titre de l'icône (qui disparaît totalement sur les sites miroirs qui ne reprennent pas notre monobook, ou sur les sites de navigation pour téléphone portable). La première phrase de l'introduction est aussi issue directement de l'accueil actuel. Un "dictionnaire de langue"? Quelle idée ?. verdy_p15 décembre 2008 à 13:05 (UTC)
je remonterais plus haut le travail collaboratif de la semaine
Est-ce nécessaire ? L'accueil par défaut est d'abord destiné aux visiteurs occasionnels qu'il ne faut pas rebuter en leur montrant en premier ce qu'il manque, alors que ce qu'ils cherchent d'abord c'est consulter le dictionnaire comme il est. Il découvrira le reste facilement. De plus ce cadre existe aussi le le portail communautaire dont le lien est mieux mis en avant.
et surtout, je suis d'accord avec Dakdada : le texte introductif est beaucoup trop long et en caractères beaucoup trop petits. C'est absolument impossible de laisser ça (si on ne veut pas faire fuir les gens). Il me fait penser aux long textes en petits caractères dans les contrats, qui n'ont pas vraiment bonne réputation.. En fait, sa place n'est pas dans la page d'accueil. Même en le supprimant, c'est encore beaucoup plus long que la page d'accueil anglophone. Lmaltier15 décembre 2008 à 09:24 (UTC)
C'est parce que tu utilises une police suffisamment petite. Utilise "Ctrl +" et tu verras que la mise en page n'est pas adaptée pour les petites résolutions. Mais c'est une bonne idée ! Koxinga15 décembre 2008 à 10:28 (UTC)
Soit honnête et fait un Ctrl+ sur la page d'accueil actuelle ! 'Ma proposition de mise en page tient nettement mieux les petites résolutions et le zoom !!! Car justement j'en ai tenu compte. verdy_p15 décembre 2008 à 13:09 (UTC)
Avant de parler de mon honnêteté, tu pourrais regarder de quelle version de ta page je parlais. À ma résolution normale, qui ne pose aucun problème sur le wiktionnaire actuellement, la liste alphabétique des lettres faisait sortir les puces sur la droite car elle ne pouvait pas être cassée par un passage à la ligne. Maintenant c'est bon. Koxinga15 décembre 2008 à 15:10 (UTC)
Je n'ai pas eu de problème sur une résolution petite, la mise en page suit parfaitement (d'ailleurs, cette page supporte mieux les petites résolutions que la page actuelle qui demande une plus grande largeur minimale. Faîtes le test en réduisant vos fenêtres et comparez les deux pages !). Le texte introductif est une traduction directe de celui de la page anglophone. Quant aux petits caractères je n'ai pas réduit plus que ce que fait la balise small sur la taille par défaut, et la page d'accueil actuelle utilise déjà des caractères encore plus petits ! verdy_p15 décembre 2008 à 12:12 (UTC)
Première impression : la page dépasse la moitié de l'écran (Safari et Firefox 3.0.4) pour être entièrement lisible et ne permet pas à un wiktionnariste comme moi de continuer à contribuer dans des conditions de travail favorables (je travaille (joue) avec 2 pages côte à côte) (Avec Explorer, la page est presque totalement incomplète)
La page actuelle dépasse aussi la moitié de l'écran ! C'est faux en plus, je peux réduire à une largeur très petite et caser deux fenêtres côte à côte sur un écran 1024x768 ! Il est impossible de tout caser dans une seule page sans forcément en cacher une partie (en bas), mais j'ai évité justement d'en cacher une partie sur le côté droit. Je me suis dit que les éléments importants utilisés tous les jours devaient être tous en haut dans une forme compacte. Mais sans sacrifier la présentation pour un novice qui y trouve tous les éléments de façon assez détaillée en commençant par le début: une présentation, et une bonne organisation des liens proposés. verdy_p15 décembre 2008 à 12:12 (UTC)
Dans la situation que j'ai connue au moment où j'ai fais le commentaire, ce que j'ai dit n'était pas faux. Je me suis sans doute mal exprimé; Je disais que je pouvais ouvrir côte à côte 2 pages avec la page d'accueil classique (mais sans voir la totalité des pages, bien sûr) alors qu'avec la nouvelle mouture proposée je ne pouvais pas les mettre côte à côte, pour pouvoir lire correctement l'une il me fallait une largeur de page plus grande que la moitié de mon écran 1680x1050; Tu sembles avoir réglé le problème (le mien) car maintenant c'est OK pour les 2 pages côte à côte; Juste un truc, sur Safari et Firefox, en haut « Ojectif : $ 6 000 000 » sort de la page (1/2 écran) - Béotien lambda15 décembre 2008 à 13:48 (UTC)
Je ne suis pas au collège, j'ai passé l'âge depuis plus de 25 ans ! Mais l'accueil actuel est plus que répulsif pour n'importe qui, tellement il est mal conçu et mélange tellement de styles de façon inhomogène. verdy_p15 décembre 2008 à 12:12 (UTC)
Beau travail, selon moi le texte descriptif (bon au demeurant) est à placer sur une autre page accessible via un "lien attractif et visible" présent sur la page d'accueil. Le bleu rend la page trop proche de celle des anglophones. C'est indépendant mais l'encart "Travail collaboratif de la semaine" devrait être moins long. Stéphane8888discuter15 décembre 2008 à 11:14 (UTC)
Le texte introductif pourrait être dans la page Bienvenue qui date et n'a pas été mis à jour depuis longtemps. Vous remarquerez que c'est une traduction directe du texte de la page anglophone. On peut sans doûte faire plus court, mais j'aime bien le texte de la page anglophone. verdy_p15 décembre 2008 à 12:12 (UTC)
Le texte du travail collaboratif de la semaine n'est pas dans la page elle-même c'est celui déjà en vigueur sur la page actuelle (j'ai repris le modèle existant). Je ne peux pas le changer. Malgré cela, ce texte n,'est pas aussi important pour l'accueil des visiteurs et novices, puisqu'il concerne des habitués qui se passent de l'accueil la plupart du temp, et qui ont leur propre portail communautaire. Raison de plus pour le placer plus bas. verdy_p15 décembre 2008 à 12:12 (UTC)
Pour ceux qui croient encore que la page n'est pas accessible sur petit écran, la preuve suivante pour l'affichage sur Mobile suffit à montrer que cette page est nettement plus accessible :
L'ordre des cadres est parfait pour la navigation sur mobile (je pourrais encore parfaire les choses our l'accessibilité, en utilisant des balises h2 pour les titres de cadres, afin de faciliter la navigation par un menu généré par ce site (ou repéré par les outils de navigation Braille) et qui découperaient la page en sous-pages, une sous-page par section ou cadre de la page actuelle, ou présenterait quand même le sommaire caché par défaut. Comparer à :
Ton cache n'est pas à jour (si tu avais essayé hier, le site n'en avais pas encore une copie dans son miroir local, et donc au lieu d'afficher uen page d'erreur pour page manquante affichait le sommaire par défaut). La page en ébauche que je donne apparait complète sur le site 7val.com aujourd'hui... verdy_p16 décembre 2008 à 19:17 (UTC)
Sauf qu'à ce moment, 10 heures plus tard, avec un autre ordinateur et un autre FAI (donc une autre IP, un autre cache, etc.), j'obtiens exactement le même résultat. --Szyx17 décembre 2008 à 02:03 (UTC)
Je ne sais pas si tu passes par un proxy, mais je viens de réessayer (sur ma connexion Neuf)
et j'obtiens bien ceci (assemblage de plusieurs copies d'écran à différentes positions verticales) :
A mon avis tu te plantes dans l’URL (tu as oublié l'accent aigu sans doute, et vu que ton URL affiche un caractère URL encodé pour l'apostrophe, et pas URLencodé pour le caractère accentué, ça doit produire cette erreur chez toi)...
Je ne sais pas comment ce site gère l'URL-encodage, mais visiblement il modifie le paramètre qu'on lui donne dans le chemin de page et "bidouille" l'encodage. Chez mois l'URL fonctionne directement (sous Google Chrome, Firefox, Safari, il faut que j'essaye de voir ce que fait IE avec des accents dans une URL et comment le site 7val.com détecte l'URLencodage standard, qu'il semble mal gérer en ne voulant semble-t-il que le codage 8bits en UTF-8 non URL-encodé). Regarde en visitant l'adresse proposée, puis revalide l'adresse qui apparait dans ton navigateur: il semble que le site fasse un redirect et "renomme" la page dans l'URL affichée après redirection. Il me semble que c'est un bogue de ce site qui gère mal l'UTF-8 urlencodé dans une URL. verdy_p17 décembre 2008 à 21:43 (UTC)
Réflexion faite, c'est un bogue de ta version de Firefox qui modifie l'URL saisie en forçant sa propre version de l'URL-encodage (théoriquement équivalent), mais le site a un problème de conformité aussi ! Il me semble que ça se joue dans les paramètres du type "toujours utiliser l'UTF-8 codé en 8 bits, et ton Firefox supprime l'URLencodage (le site 7val ne veut pas non plus des adresses non URLencodées codées en UTF-8 sur 8 bits; mais le site ne signale pas correctement au navigateur qu'il ne le prend pas en charge et Firefox suppose par défaut qu'il l'accepte dans une URL dès lors que la page affichée est codée en UTF-8 : mauvaise config HTTP du site). verdy_p17 décembre 2008 à 21:50 (UTC)
Ça marche aussi avec Safari ou le navigateur KDE, et Google Chrome ou Chromium (avec lequel j'ai fait les copies d'écran) tous basés sur le moteur de rendu HTML d'Apple, et avec ma version de Firefox... (peut-être pas la dernière, ou bien c'est dû à un plugin), et toutes les versions d'IE que j'ai. Ce que fait Firefox me semble donc bien un bogue de celui-ci (ou une mauvaise configuration chez toi, incompatible avec le codage UTF-8 recommandé des URLs mais que le navigateur n'a pas le droit de changer à sa guise ; mais il y a quand même un bogue sur le site 7val.com qui ne reconnaît pas l'UTF-8 non URL-encodé (donc codé en 8 bits comme ta version de Firefox veut absolument le faire en annulant l'URL encodage fait ici correctement par MediaWiki), ou qui l'interprète comme si c'était de l'ISO 8859-1 alors que tous les sites Wikimedia n'utilisent plus les diverses variantes de l'ISO 8859). verdy_p21 décembre 2008 à 14:09 (UTC)
C'est encore trop complexe et le texte d'introduction est trop long, il devrait être dans une sous-page pour les gens intéressés. Je pense aussi que la boîte de recherche devrait prendre toute la largeur, les liens à droite pouvant se mettre en dessous, à la place du texte introductif. Malgré ces quelques critiques, je trouve cela pas mal du tout, et c'est un pas dans la bonne direction. Tu fais un vote pour qu'on l'accepte ? Koxinga22 décembre 2008 à 21:42 (UTC)
Mais serais-je donc le plus vieux ici ? Bon d'accord, avec trois ans d'absence au milieu, c'est un peu de la triche ;o) ... Koxinga16 décembre 2008 à 18:53 (UTC)
Désormais triée par date d'apparition de chaque contributeur, cette liste a je crois un intérêt concernant l'histoire du Wiktionnaire. Sauf que sont oubliés tous ceux qui n'ont pas fait assez de chiffre pour y apparaitre, et je leur présente mes excuses. --Szyx17 décembre 2008 à 01:45 (UTC)
Sur l'article thanatopraxie la section "apr" ("Apparentés étymologiques") a été retirée, ce que je comprends tout à fait puisque le contenu faisait doublon avec la section "drv" de thanato-. Mais dans l'optique de rendre l'article thanatopraxie le meilleur et le plus complet possible (si par exemple il était développé pour devenir AdQ), ne finira-t-on pas par remettre cette section au bout du compte ? Si oui (ce dont je ne suis pas sûr), il faudrait plutôt replacer cette section. Qu'en pensez-vous ? Markadet∇∆∇∆16 décembre 2008 à 15:44 (UTC)
Ma devise est "trop d'info tue l'info". C'est moi qui ai retiré ces composés. La raison principale est qu'il vaut mieux mettre tous nos œufs dans le même panier, de façon qu'il existe une seule liste la plus complète possible des composés avec thanato-, et pas une liste partielle dans thanatologue et une autre liste partielle dans thanatopraxie , une troisième ailleurs, etc. On peut peut-être faire un lien direct en plus, mais je n'en vois pas l'utilité du moment que l'utilisateur voit en premier lieu la partie étymologie, et que celle-ci renvoie aux composés. En ce qui concerne la remarque de Szyx, je bois du petit lait, et me réjouis d'apprendre l'existence de cette rubrique, moi qui ferraillai naguère pour que l'on revoie la catégorisation à mon avis erronée en suffixes et préfixes de ce qui n'est (à mon sens) que des éléments de composition. --Zorglub16 décembre 2008 à 20:19 (UTC)
D'accord avec Zorglub pour les avoir retirés. Pour ce qui est de -compos-, je pense qu'il faut réserver ça aux pages sur les préfixes. Dans les autres, on groupe sous dérivés. Certains puristes voudraient sans doute distinguer dérivés et composés, mais la distinction est incompréhensible au commun des mortels. Le mot courant est dérivés pour tous les mots qui dérivent d'un mot. Pour ce qui est des préfixes et suffixes, ce sont les termes usuels, je les garderais, même si un préfixe n'est pas nécessairement tout au début d'un mot. Lmaltier16 décembre 2008 à 21:46 (UTC)
C'est l'éternel débat du modèle {{-apr-}}. Selon moi (et d'autres) ce modèle devrait être supprimé. Sa teneur étymologique doit apparaitre exclusivement par "filiation directe", c'est-à-dire dans les sections {{-étym-}} pour les étymons du mot vedette et dans {{-drv-}} pour ses "descendants". La teneur sémantique de {{-apr-}} (dans certains articles) doit être placé dans la section dédiée {{-voc-}}. Darkdada avait suggéré le remplacement automatisé de {{-apr-}} en {{-voc-}}. Cela éviterait la permanente interrogation : « ça sert à quoi {{-apr-}} ? Qu'est-ce qu'on y met ? » Ce changement radical est approximatif pour un certains nombre d'articles, mais il n'est pas faux puisqu'un mot apparenté de façon étymologique l'est quasiment toujours de façon sémantique.
Pour répondre à la question, je supprimerais la section {{-apr-}}. Car gérer les cousins étymologiquement éloignés, se fait à travers l'arbre étymologique (on y monte ou on y descend, cela est suffisant). S'il y a une intéressante anecdote étymologique au sujet d'un "cousin" : la section {-étym-} suffit. Stéphane8888discuter17 décembre 2008 à 22:35 (UTC)
Traduction par une expression
Quelle est la norme actuelle quand il n'y a pas un simple mot pour traduire, mais seulement un groupe de mot qui ne mérite pas forcément une entrée à lui (expression, périphrases) ? Qu'est-ce que vous faites dans ce cas ?
Je vois plusieurs possibilités :
Mettre un modèle {{trad}} quand même, même si l'entrée a très peu de chance d'exister un jour. Conjugué avec un bot qui crée des entrées comme PiedBot a pu le faire, on obtient des entrées comme apricot tree (voir abricotier) qui n'ont pas forcément grand intérêt.
Mettre un modèle {{trad}} sur les mots clés de l'expression. Voir par exemple l'espagnol pour enculer. Par contre le contenu de trad n'est plus une traduction de l'entrée, ce que je trouve dommage.
Mettre une forme alternative avec le paramètre dif : énerver : auf die Nerven fallen(de). Le problème est que cliquer sur le lien est assez surprenant, on n'est pas du tout là où on s'y attendais.
Cette solution ne me plait pas du tout. Je préfère très nettement :
où aucun modèle {{trad}} n'est utilisé (seulement des modèles {{lien|de|...}}) sur lse mots-clés, puisque les mots-clés en allemand ne sont pas eux-même des traductions du mot français (ta suggestion casse la collaboration interwiki par bot, et offrira des traduction incorrecte dans les autres wikis comme ici le wiki allemand). verdy_p17 décembre 2008 à 16:51 (UTC)
Abandonner l'idée du modèle trad. Ne faire que des liens simples vers les mots clés. On perd la catégorisation et les liens vers le wiktionnaire cible.
Si vous avez déjà eu le problème, quelle est votre solution ? Êtes-vous d'accord pour qu'on écrive quelque chose dans les conventions à ce sujet, après une discussion et un vote s'il y a lieu ? C'est un problème réel et qui prendra de l'importance lorsqu'on attaquera les traductions plus complexes. Koxinga16 décembre 2008 à 20:40 (UTC)
Si la traduction a sa place comme entrée, pas de problème (même si elle n'existe pas encore). Si elle n'a pas sa place, je pense que le mieux est de ne pas utiliser trad du tout dans cette traduction. De toute façon, si elle n'a pas sa place ici, elle n'a pas non plus sa place sur le wiktionnaire de la langue. Lmaltier16 décembre 2008 à 21:38 (UTC)
En résumé, si elle a sa place, elle a sa place, mais si elle n'a pas sa place, elle n'a pas sa place. CQFD. --Szyx17 décembre 2008 à 01:54 (UTC) Oui, je me moque.
La première solution me semble tout de même la meilleure. La deuxième peut passer et me semble (un peu) mieux que rien du tout. Les deux dernières me semble inadmissibles (un lien doit afficher ce vers quoi il mène !). Cdlt, VIGNERON * discut.17 décembre 2008 à 08:08 (UTC)
Je ne comprends pas cette réaction (malentendu sur les propositions ?). On peut mettre une locution en traduction sans pour autant utiliser de modèle trad, en mettant (ou non) des liens normaux sur les mots individuels. Par ailleurs, l'exemple choisi pour la première proposition me semble trompeur, car apricot tree me paraît avoir sa place comme entrée. Je proposerais comme exemple oiselet traduit par small bird, qui n'aura jamais sa place comme entrée. La question, pour moi, est plutôt : faut-il mettre smallbird (2 liens, à ne pas remplacer automatiquement par trad dans ce cas, je pense que le robot peut être suffisamment intelligent pour ça) ou small bird (pas de liens, bien sûr c'est moins pratique, mais ça évite de laisser croire qu'on clique sur un lien vers l'ensemble alors qu'on clique sur un lien vers un seul des mots). Lmaltier17 décembre 2008 à 08:24 (UTC)
Les liens sont quand même faits en sorte de manière à montrer ce sur quoi on clique (en fonction du style CSS, soit). Par exemple, pour « petitoiseau » on a un lien pour chaque mot, ce qui est montré par le fait que chaque mot est souligné indépendamment quand on passe la souris dessus. Par contre avec « petit pois » le lien est clairement sur l'ensemble. Je pense donc qu'on peut se contenter de la deuxième solution : * {{en}} : {{trad|en|little}} {{trad|en|bird}} (avec {{trad}}). Ou peut-être mieux * {{en}} : ] ] (avec liens directs). - Dakdada(discuter)17 décembre 2008 à 08:39 (UTC)
Pour toi la catégorisation est inutile alors ? Ça me paraît dommage de l'abandonner quand même. Pas tellement ennuyant pour un utilisateur qui consulte le wiktionnaire, un peu plus pour un contributeur qui veut vérifier toutes les traductions dans une langue peu présente, et beaucoup pour un éventuel programme qui veut sortir des traductions en une langue automatiquement. Koxinga17 décembre 2008 à 09:41 (UTC)
La catégorisation n'est abandonnée que pour les rares traductions "mot/locution", et encore... seulement pour les mots qui n'ont que cette seule correspondance. small bird est l'exemple type. Je résume :
Proposition n°1 : * {{en}} : {{trad|en|small bird}} Le lien vers Wiktionary est inutile et restera rouge. La catégorisation dans Traductions en anglais est pour moi secondaire.
Proposition n°2 : * {{en}} : {{trad|en|small}} {{trad|en|bird}} Bof. Les liens interwiki ne correspondent pas. Une virgule ajoutée entre les deux (sur un cas plus difficile) et ça devient faux.
Proposition n°3 : * {{en}} : {{trad|en|bird|dif=small bird}}me parait très déroutante pour le lecteur et difficile pour le contributeur. Et la correspondance interwiki est fausse.
Proposition n°4 : * {{en}} : ] ] ou idéalement * {{en}} : ] ] On perd seulement la catégorisation (secondaire d'après moi)
où c'est un modèle T qui fait la catégorisation. J'hésite un peu à proposer cela, parce que je ne suis pas très motivé pour compliquer encore la syntaxe mais je tiens quand même à ce qu'on garde des catégorisations, cela me paraît très utile et cela va devenir de plus en plus utile au fur et à mesure de la croissance du wiktionnaire. Koxinga17 décembre 2008 à 10:12 (UTC)
Cette proposition ne marcherait pas: ce n'est pas parce qu'on met un lien après le ":" que le mot ciblé par le lien se catégorisera. On est bien obligé d'utiliser un modèle pour le faire proprement, et c'est ce que font simplement les modèles trad/trad+/trad-. Le modèle pour le titre avant le ":", pourquoi pas mais je ne vois pas ce que apporte de plus que * {{T|en}} apporte de plus que ne fait pas déjà plus simplement * {{en}}.
Ta proposition serait plus intéressante en revanche sous une forme comme {{T|en|little|bird}} où l'énumération des termes serait gérée en interne. Cependant il resterait difficile d'ajouter des notes de précision, des romanisations, des différences graphiques entre la cible et le nom affiché, etc... Le prix se payera alors en terme de complexité d'appel d'un tel modèle (comment passer et nommer tous les paramètres nécessaires et conserver un code wiki lisible?), et du nombre variable de paramètres à gérer pour chaque terme (donc un modèle forcément bien plus lourd que les modèles actuels dont la complexité est limitée à un seul niveau d'indirection pour faire tout le travail. verdy_p17 décembre 2008 à 16:09 (UTC)
Je préférerais encore que les modèle {{en}} etc. catégorisent automatiquement eux-même (vu ce qu'il sont devenus...). Le problème étant qu'ils ne sont pas utilisés que pour les traductions (et ce n'est pas vraiment leur rôle... ou alors ça a encore changé). - Dakdada(discuter)17 décembre 2008 à 11:29 (UTC)
J'ai peut être la solution (après conflit de version ) : Il a été proposé de réserver les modèles de langues {{en}}, {{de}}, ... à la seule section des Traductions ({{-trad-}}). Un autre modèle, par exemple {{en2}} ou {{en-bis}} ou {{anglais}}, etc... pourrait être utilisé en remplacement de l'usage qui en est fait parfois aujourd'hui dans les sections Etymologie ({{-étym-}}), Dérivés dans d'autres langues ({{-drv-int-}})... Inutile de te préciser comment catégoriser à partir d'un modèle {{en}} dédié... Stéphane8888discuter17 décembre 2008 à 11:35 (UTC)
Multiplier les modèles de langue déjà très nombreux, je ne vois pas trop l'intérêt. Sinon les robots actuels savent déjà très bien repérer les {{trad}} qui sont utilisés sur les autres projets (seule variante, le nom du modèle trad lui-même, comme sur le wikitionnaire grec dont un robot vient importer ses noms de modèles trad "traduits en grec" ici, au prix d'une redirection simple de ces modèles, une redirection pas très génante et qu'il est facile de corriger automatiquement par un bot standard redresseur de redirections).
Le changer ici, veut dire ressortir de la collaboration actuelle entre wikis, et je ne vois pas ce qui peut le motiver. Bref il faudrait en discuter avec les autres wikis pour voir ce qu'ils en pensent. On peut faire beaucoup de chose avec un modèle unique, et les étendre au gré des besoins rencontrés sans changer tout le reste et les façons actuelles de coder la totalité des pages (1 million et demi si on compte aussi les discussions, une paille..., sans compter les millions de page des autres wikis qu'il faudrait coordonner, et un certain nombre de robots qui utilisent ces modèles, dont certains sont dressés par des membres qui ne parlent pas bien ou maitrisent très mal le français mais se sont contentés des explications qu'on a pu leur donner pour les aire fonctionner sur divers wikis (avec le français parmi eux).
Ta solution reviendrait donc à créer un modèle en2 pour les traductions existantes, en2- pour celles qui manquent, en2+ pour celles qui ont été vérifiées ! Tout ça pour gagner 3 ou 4 caractères par terme traduit (et je me demande quelle peut être la lisibilité de {{en2|bird}} par rapport {{trad|en|bird}}... Cela fait une indirection en plus, et 4 fois plus de modèles à gérer qu'actuellement.
Pour revenir à la question initialement posée au début de ce sujet, je ne vois pas où est le problème : si une locution n'a pas d'équivalent dans une autre langue donnée, elle ne peut logiquement pas figurer du tout dans les traductions proposées.
En revanche on pourrait imaginer un modèle du genre {{trad0|explications...}} pour tenter de donner non pas une traduction mot à mot (impossible ou seulement vaguement approchante), mais une explications ou une définition dans la langue indiquée, sans créer aucun lien dur un terme (les liens seront dans les explications ou la définition donnée).
De tels ajouts seraient alors sorties du cadre multicolonne des traductions « mot à mot » et présentées comme des listes de définition (avec * et : généré en interne par le modèle), par exemple
{{trad0|en|This untranslatable expression is used when... One could say... Note:... Related terms: ]...}}
Pour une telle extension destinée aux locutions intraduisibles ou seulement très vaguement approchantes, il n'y a pas besoin de créer des modèles de code langue dérivés (un seul modèle comme trad0 suffirait). Maintenant je n'y vois qu'une utilité limitée, car on peut aussi bien écrire plus simplement (et de façon plus générale sans limitation sur ce qu'on peut mettre en explications dans ce cas (sans utiliser aucun modèle trad) :
* {{en}} : : This untranslatable expression is used when... One could say... Note:... Related terms: ]...}}
sans utiliser aucun modèle de langue supplémentaire. Mais on perd le fil de ce wiki qui est de fournir des traductions expliquées en français et pas en anglais. Ce serait donc plutôt :
* {{en}} : : Cette expression intraduisible en anglais pourrait se formuler ''xyz'' quand... : On pourrait aussi dire... : Note :... : Autres termes apparentés : ''{{lien|en|something}}''...
La seule utilité de trad0 serait alors de catégoriser cette longue définition en mettant alors seulement :
* {{trad0|en}} : : Cette expression intraduisible en anglais pourrait se formuler ''xyz'' quand... : On pourrait aussi dire... : Note : ... : Autres termes apparentés : ''{{lien|en|something}}''...
(aucune lourdeur dans le code wiki qui reste très lisible avec des modèles simples).
Noter quand même qu'il est impossible dans ce cas à un robot d'importer ces explications (qui devraient être en français ici) d'un wiki à l'autre. Et il n'y a pas non plus de terme "clé" qui convienne dans ce cas pour faire des liens inversés (on peut seulement utiliser {{lien|en|something}} pour les lier de façon unidirectionnelle dans le contexte des explications données.
On ne parle pas de toucher au modèle trad, plutôt aux modèles de langue en début de chaque ligne ...
J'ai bien compris, mais ta remarque ne correspond pas aux suggestions de "solutions" données ici : qu'est-ce qui manque en début de ligne où ne figure que le nom de la langue ? verdy_p17 décembre 2008 à 16:09 (UTC)
Importer des modèles en grec est une très mauvaise idée. j'étais vraiment surpris quand j'ai vu ça ... Qu'est-ce qui empêche le robot de traduire le nom ? Koxinga17 décembre 2008 à 15:59 (UTC)
Rien n'empêche ce robot de le faire (le code du Bot pywikipedia le permet déjà : il faut prévenir son utilisateur pour qu'il mette à jour un seul fichier python pour connaître les synonymes utilisés ici : ce bot a une configuration facile pour la localisation). verdy_p17 décembre 2008 à 16:09 (UTC)
Suite
Je reviens ici pour expliquer plus clairement car a priori Verdy p n'a pas compris ma proposition et la discussion devient touffue.
Je ne souhaite pas la création de codes {{en2}}, etc. dérivés des codes langue
Mon idée est juste de changer le format actuel :
* {{en}} : {{trad+|en|mot}}, expression plus ]
en
* {{T|en}} : {{trad+|en|mot}}, expression plus ]
Ce modèle T est un peu le {{trad0}} de ton dernier exemple je crois. Il peut donner la langue et faire la catégorisation, ce qui permet de mettre ce qu'on veut dans les définitions, sans essayer de force l'emploi de {{trad}}.
Il peut aussi par exemple indiquer que toute la ligne est une traduction dans la langue en argument grâce à des span, pour que cela puisse être manipulé par javascript ensuite et que les utilisateurs puissent choisir quelles langues les intéressent. Ce dernier exemple n'est qu'une idée en l'air, mais c'est pour montrer que c'est beaucoup plus flexible. Koxinga17 décembre 2008 à 16:41 (UTC)
Oui c'est bien ce que j'avais compris, mais je ne répondais pas qu'à toi (les modèles en2 et autres c'était l'idée de Stephane8888 et mon long passage répondait à cette proposition juste en dessous). Ton modèle T est effectivemetn similaire au trad0 décrit à la fin (j'aurais du le dire pour conclure, car ton idée initiale est bonne pour le cas décrit). Cependant tu ne pousses pas ici le raisonnement jusqu'au bout, car je ne vois pas ce que vient faire ton emploi de {{trad+}} dans ton exemple : si c'est une traduction effective, pas besoin de longues explications, le mot peut figurer dans la liste des mots traduits ; sinon ce ne doit PAS être {{trad+|en|mot}} mais un simple {{lien|mot|en}}. verdy_p17 décembre 2008 à 17:00 (UTC)
Je ne vois pas le problème de {{lien}} : il simplifie l'écriture du lien en permettant de recopier le texte affiché dans la cible du lien (en évitant des erreurs). On a d'autres modèles qui font cette copie par exemple pour les sommaires alphabétiques de catégories... où c'est pourtant moins nécessaire pour une vingtaine de modèles d'alphabets que sur des millions d'articles. On a aussi {{ucf}}, une variante de {{lien}} qui fait cette copie légèrement modifiée. verdy_p17 décembre 2008 à 21:34 (UTC)
Oh, ça c'est une idée... tout à fait réalisable à mon avis, sans même avoir à ajouter de nouveaux modèles. Il suffirait, comme je l'ai suggéré, de modifier les modèles de langue type {{en}} pour qu'automatiquement :
ils catégorisent l'article dans les traductions en en ;
Surtout pas ! Du moins pas sous leur forme simple {{en}}, et je ne vois pas l'intérêt de le faire sous la forme {{en}} quand il est plus simple de faire {{T|en}} (ou {{trad0|en}} pour bien montrer que c'est une traduction et pas un mystérieux "T" majuscule). Les modèles de langues sous la forme simple {{en}} doivent ne faire QUE générer le nom de la langue et c'est tout, et aucune catégorisation.
N'oublie pas qu'il faut générer plusierus choses: le nom de langue à afficher et la liste des mots derrière, et les URLs des Wikis, et les différents états (présent ou non) sur les différents wikis ciblés, et encore d'autres choses à faire comme le paramétrage de l'écriture (pas encore fait) et la libellisation du texte en langue étrangère affiché sur la page (pour les moteurs de recherche qui se demandent ce que sont ces mots français "bizarres" dans une page théoriquement française, ce qui atténue les notes sur la gestion des langues par ce wiki et diminue le potentiel de recherche par des moteurs tiers comme Google ; on a trop de mots étrangers sur trop de pages, et qui ne sont pas étiquetés correctement dans leur langue d'une façon acceptable à la fois pour les moteurs de recherche mais aussi pour l'affichage dans les navigateurs qui doivent sélectionner contextuellement des polices pour les bonnes écritures). verdy_p17 décembre 2008 à 20:43 (UTC)
ils ajoutent un marqueur (genre <span class="traduction lang-en"></span>.
C'est possible en effet dans le modèle anglais mais en mettant un paramètre contenant le texte (mais il faudrait indiquer un type pour savoir si on veut un span ou un div, car un span n'est pas utilisable pour marquer plus d'un bloc). Les modèles d'écritures gèrent déjà cela pour ceux que j'ai déjà faits (par exemple {{Latn}} ou {{Hang}}, mais ils ne précisent pas la langue, juste la forme souhaitée pour l'écriture et la sélection correcte des polices dans un contexte très multilingue où plein d'écritures sont présentes sur la même page).
Ce marqueur pourrait alors en effet être utilisé par un script qui cacherait ou n'afficherait que les langues que l'on désire voir affichées ou pas, grace à des gadgets bien définis. J'ajoute que les modèles {{trad}} seront un peu plus légers car ils n'auront alors plus à catégoriser les langues. D'un autre côté, cela implique qu'on n'utilise ces modèles que pour les traductions.
C'est déjà envisagé sous la forme {{en|Text in English}} mais le type par défaut est vide et ne peut afficher que le nom de la langue actuellement (on pourrait lui demander de ne pas afficher le nom de la langue mais le texte en paramètre s'il y en a un, de sorte que le type par défaut devienne "span" si un paramètre 1 est précisé), ce qui permettrait alors d'écrire anglais, le texte indiqué venant alors se substituer au nom en français de la langue. Compare par exemple "{{Kana}}"="{{Kana}}" et "{{Kana|あいう}}"="{{Kana|あいう}}", avec un code d'écriture ici (et non de langue). Note: je ne veux pas retriendre aux traductions, ni même à la génération d'un lien, l'utilité d'un tel paramètre est de maruqer seulement le texte. Tout autre mise en forme nécessiterait un code spécifique autour ou l'ajout d'un nouveau type particulier dans les modèles génériques "lang/type" (sans qu'il soit nécessaire de toucher aux modèles de paramétrage langue par langue {{en/type}} ni {{en}} ni aucun des nombreux autres pour toutes les langues pour cela). verdy_p17 décembre 2008 à 20:43 (UTC)
Dernière remarque : étant donné que toutes les langues dépendent d'un même modèle {{lang}}. Il suffrait donc en théorie de ne modifier que ce modèle pour que les catégorisations et l'ajout du span soient faits automatiquement. Bien sûr, un vote devra avoir lieu avant de changer tout ça, étant donné l'omniprésence de ces modèles (protégés). - Dakdada(discuter)17 décembre 2008 à 17:07 (UTC)
Cela ne me semble pas du tout une bonne idée de mettre ça dans les modèles de langue. Cela n'a pas de sens de les restreindre aux traductions après les avoir rendu aussi puissants. En plus, il y aurait un gros travail pour remplacer les codes de langue utilisé en étymologie et autres. Pourquoi ne pas ajouter un modèle {{T}} qui fait ça ? Koxinga17 décembre 2008 à 19:42 (UTC)
Note: la syntaxe {{en|type=xxx}} forme courte avec type optionnel, est équivalente à {{lang/xxx|en}} (forme longue avec type hors paramètre), mais pas à {{en/type|xxx}} qui ne retourne que les paramètres différents des valeurs par défaut (puisque c'est {{lang/xxx}} qui les détermine); je ne m'étais pas aperçu que {{lang}} était protégé (depuis peu).
Mais {{en|type=xxx|param}} ne relaie pas le paramètre "1" dans {{lang/xxx|1=en|2=param}} en le passant en paramètre 2 (je n'avais pas prévu que ces modèles puissent retourner des valeurs dépendant d'un autre paramètre comme un texte à formater ou indexer, mais seulement qu'ils retournent des constantes définies pour chaque langue à travers un simple switch et un formatage par défaut fait de le même façon pour toutes les langues). C'est une modif simple à faire, mais il faut retoucher tous les modèles comme {{en}} pour qu'ils le fassent. (Note xxx désigne un des noms de types supportés par un modèle nommé "lang/xxx".)
L'autre solution serait d'utiliser un sous-modèle {{lang/xxx|en|param}} directement mais autant utiliser un modèle séparé ici (comme {{T|en|texte}} ou {{trad0|en|texte}} proposé ci-dessus) pour le traitement spécifique des traductions sans mot ou locution équivalente : ils sauront utiliser facilement les modèles existants de façon générique, car ils ne dépendent pas ni ne nécessitent de traitement spécifique pour certaines langues comme cela a été fait, à tord à mon avis, pour le chinois dans {{trad}} (et oublié dans {{trad-}} et {{trad+}} ! alors qu'on pouvait le faire de façon générique sans utiliser un autre sous-modèle intermédiaire comme {{trad/défaut}} et {{trad/zh}} avec un switch assez stupide dans {{trad}} pour savoir lequel des deux utiliser) ; celui qui a pensé à ce switch aurait du réfléchir un peu (mais on peut toujours revenir dessus : le modèle trad/zh sont totalement inutiles tout pouvant se faire dans trad directement (et aussi dans trad- et trad+) qui utilisent tous les trois trad/défaut qui peut tout à fait gérer le paramètre optionnel du chinois (qui n'est d'ailleurs pas spécifique au seul chinois et serait utile aussi pour l'hébreu, le coréen, le vietnamien, le géorgien écrit en khoutsouri, etc.). verdy_p17 décembre 2008 à 21:19 (UTC)
Pour la catégorisation automatique, il faudrait quand même se poser la question : est-ce que ces catégories ont déjà été utilisées par quelqu'un ? Levez le doigt ! Passer des heures à se prendre la tête et à se poser la question comment compliquer le Wiktionnaire pour des catégories jamais utilisées, ce n'est pas une bonne chose. Je redis aussi que ne pas arriver à comprendre quelque chose, ou ne pas arriver à suivre tellement les changements s'enchaînent, il n'y a rien de pire pour décourager les contributeurs. On est là pour faire un dictionnaire, pas pour concevoir un logiciel (et je sais ce que je dis). Lmaltier18 décembre 2008 à 06:54 (UTC)
Puisque tu sais ce que tu dis, tu sembles oublier qu'un dictionnaire c'est d’abord un index alphabétique correct (dans tous les dictionnaires imprimés), et qu'on ne le parcourt pas seulement en allant directement à une entrée mais aussi en consultant les termes proches à partir du classement alphabétique. Les catégories sont faites pour ça et j'ai fourni le moyen de les ordonner correctement langue par langue. Et je ne vois pas du tout en quoi cela complique ou éloigne les utilisateurs ou contributeurs (et cela n'empêche pas non plus que le plus gros du travail effectué ici se fait avec des modèles et des Bots que cela ne gène pas non plus, bien au contraire car cela les aide à classer et modifier correctement les pages avec des infos contextuelles moins ambigues et plus faciles à repérer, surtout si les clés de tri par langue sont hors de la page mais dans une sous-page à la syntaxe nettement plus simple !). verdy_p21 décembre 2008 à 06:44 (UTC)
Pour reprendre systématiquement toutes les traductions d'une langue, c'est le plus simple. Je suis en train de le faire pour le chinois pour ajouter pinyin, formes traditionnelles et simplifiées, et je devrai peut-être le refaire si on décide de donner le code {{cmn}} au lieu de {{zh}}. J'imagine le cas d'un contributeur connaissant une langue peu représentée ici, c'est très agréable de pouvoir rapidement avoir toutes les traductions pour les vérifier. C'est aussi un moteur de motivation non négligeable de voir le nombre de pages monter dans ces catégories. Enfin bref, cela ne coûte rien de les garder et moi au moins elles me sont utiles. Construire un dictionnaire comme on essaie de le faire implique de résoudre des problèmes logiciels. Considérer un dictionnaire comme un ensemble de pages de texte, ça ne marche pas. Il ne faut pas être complexe pour le plaisir, mais il faut aussi organiser au maximum pour pouvoir continuer à manipuler les données même quand on en aura beaucoup. Koxinga19 décembre 2008 à 20:15 (UTC)
Donc, ça fait quand même 1 utilisateur. Mais, pour faire ce travail, il aurait peut-être été aussi simple de chercher les pages utilisant le modèle zh (grâce à la boîte à outil de la colonne de gauche). Lmaltier19 décembre 2008 à 20:59 (UTC)
Puis d'enlever les 21 000 pages sur les caractères chinois, voire les quelques unes se servant de {{zh}} pour indiquer l'étymologie ou autre. Bon, je ne serai pas de mauvaise foi trop longtemps, je suis d'accord qu'il y a toujours d'autres moyens (je pense surtout à utiliser un dump dans mon cas).
Ma solution est plus propre quand même, et finalement plus logique. Je ne pense pas que cela soit plus compliqué sur le long terme, même si le changement est toujours gênant. Surtout, je ne veux pas que tu te décourages pour ce genre de choses, je préfères qu'on en discute tranquillement. J'ai envie que ça avance, mais je suis aussi prêt à attendre et à en discuter si tu veux, pour comparer nos visions globales du Wiktionnaire.
Je ne pense pas que cela découragera les contributeurs débutants, pas plus que de voir des choses comme "{{en}}" au lieu de "anglais". On a cassé le côté intuitif il y a bien longtemps (et je crois que c'était nécessaire). Maintenant il y a toujours une phase d'apprentissage pour éditer directement la page, et elle ne me paraît pas plus ardue avec {{T|en}} qu'avec {{en}}. Par contre je suis pour qu'on instaure des moyens de contribuer ponctuellement sans se plonger dans le code wiki.
Est-ce qu'on a déjà parlé ici d'importer le feedback du wiktionary ?
Non, ne pas utiliser {{cmn}}, le modèle {{zh}} fait référence au code normalisé zh qui fait référence de façon non ambigüe au seul mandarin (quand il n'est pas complété par un autre code). C'est bien ce que reconnait la norme BCP 47 qui adopte pour les macrolangues la signification de la langue très majoritaire qu'elle contient (contrairment à ISO 639 qui est de toute façon plein d'ambiguïté au sujet de l’usage correct de nombre de codes). BCP 47 reconnait qu'on cherche le chinois par le code alors qu'implicitement c'est le mandarin qu'on recherche et pas une autre langue chinoise, le terme "chinois" étant devenu synonyme de "mandarin" pour la plupart des gens qui ne savent pas qu'il y a d'autres langues en Chine.
On peut en revanche utiliser d'autres codes pour le wu , le cantonnais , etc. C'est donc plutôt l'usage du code qu'il faut nettoyer des références aux autres langues que le mandarin. Et c'est aussi la solution la plus simple à mettre en œuvre.
On a exactement le même cas pour l'albanais (shqip) qui est une macrolangue dont la langue individuelle largement majoritaire est le tosk (l'albanais officiel en Albanie) : on garde pour désigner le tosk (l’usage d’ issu de l'ISO 639 n’est normalement pas nécessaire), et on ne change de code que pour les variantes de l’albanais comme le thrace (ou arvanite) parlé en Grèce (variante parfois codée avec un sous-code région devenu obsolète car ne distinguant pas clairement les deux langues albanaises qui sont toutes deux parlées maintenant en Grèce, suite aux migrations).
Je vous renvoie donc aux recommandations de BCP 47, qui fixe un cadre très clair non ambigu et simple à comprendre pour la codification. verdy_p21 décembre 2008 à 06:44 (UTC)
Stephane8888 (d · c · b) vient de m’apprendre que les anagrammes doivent être séparé par langue, donc une section {{-anagr-}} par langue. Je ne trouve pas cela logique, j’aurais plutôt tendance à mettre une seule section {{-anagr-}} par article. Qu’en pensez-vous ? Cdlt, VIGNERON * discut.19 décembre 2008 à 06:53 (UTC)
Si, c'est parfaitement logique. La notion d'anagramme n'existe que pour une langue donnée (cette précision est en général omise dans les définitions, mais sous-entendue). Cela n'a pas vraiment de sens (ni d'intérêt) de faire autrement. Si tu trouves une définition d'anagramme qui prend pour exemple deux mots de langues différentes, ça m'intéresse fortement.
Tu fais peut-être le rapprochement avec le bandeau voir de début d'article, qui est interlangues. Mais le bandeau sert simplement à simuler le regroupement des mots dans les dictionnaires papier : sur le papier, on voit tout de suite le regroupement, ici le bandeau est nécessaire. Et s'il est interlangues, c'est qu'on est un dictionnaire qui regroupe toutes les langues. Lmaltier19 décembre 2008 à 08:07 (UTC)
Je perçois les anagrammes comme des jeux de mots pouvant être utiles aux poètes, ou utile aux créateurs de palindromes (donc dans une seule langue). Voir aussi Anagramme sur Wikipédia. On peut toutefois imaginer signaler une anagramme interlangue célèbre (peut être y en a-t-il d'anglo-françaises pour Montréal ?) Pour un mot comme robot (appartenant à 5 langues) on a déjà 5 listes d'anagrammes possibles... de quoi s'occuper. A ce propos, on pourrait recenser (dans Wiktionnaire:Ressources) des sites utiles pour trouver des anagrammes de l'anglais, etc. Stéphane8888discuter19 décembre 2008 à 17:49 (UTC)
Ayant créé l'article inexister, et, pour ne pas encourir les foudres de Szyx, la conjugaison afférente, je constate que des formes fléchies de participe passé et présent ont été incluses dans toutes les conjugaisons (je me réveille en retard). Or je suis quand même perplexe devant "brillées" ou "inexistées", s'agissant de verbes intransitifs qui, en principe, n'ont pas d'occasions d'accorder leur participe passé. Quant au participe présent, sauf jusqu'au XVIII" siècle, il ne s'accordait pas en tant que forme verbale, mais seulement certains verbes devenus par dérivation impropre, adjectifs, et qui, dans certains cas, changent légèrement de forme. Par exemple, théoriquement (donc sauf en français classique jusqu'au XVIIIe) fatiguantes n'existe pas ou plutôt constitue une erreur orthographique (et donc peut apparaître comme telle ou sous un bandeau "français du XVIIIe") pour fatigantes. Et à mon sens, existées, brillées, ne devraient pas figurer. Pensez aux étrangers qui apprennent le français: tout cela n'est-il pas déroutant ? Ne risque-t-on pas de les induire en erreur par cette avalanche d'informations sous forme de tableau qui nécessiteraient une cascade de précisions et de restrictions ? J'en conclus que ces formes devraient s'efforcer à inexister. --Zorglub19 décembre 2008 à 11:29 (UTC)
Pour le participe présent, n'y connaissant rien je me range aux avis plus éclairés. Pour le participe passé, il existe une option dans les modèles pour dire qu'il ne s'accorde pas (pp.inv=1), mais je n'ai pas expérimenté depuis les interventions de Verdy (j'attendais qu'il ait fini). --Szyx19 décembre 2008 à 11:53 (UTC)
Pas de problème: pp.inv est là pour ça (et il existe depuis longtemps, ce n'est pas un paramètre que j'ai ajouté). Si ça te laisse perplexe, cela aurait dû te faire le même effet dans les conjugaisons (toutefois auparavant ce n'était pas toujours visible dans les conjugaisons avec l’auxiliaire avoir, du coup rien ne mentionnait l'invariabilité qui n'était indiquée que pour les verbes, moins nombreux, conjugués avec l'auxiliaire être). Bref, il suffit d'ajouter le paramètre qui manque. La motivation venait du fait de conjugaisons fausses dont le féminin ou le pluriel du participe n'est pas régulière (et ne consiste pas seulemnt à ajouter un e ou un s).
Donc ce qu'il faut vérifier c'est la liste des verbes intransitifs (non pronominaux) conjugués avec avoir. S'ils ne sont pas autocatégorisés avec {{i}}, on pourrait le faire pour en obtenir une liste assez facilement. verdy_p20 décembre 2008 à 12:48 (UTC)
Le participe présent est toujours invariable, c'est clair, et le participe passé variable ou non selon les verbes (attention : certains verbes intransitifs ont parfois un emploi spécial transitif, par exemple nager). J'imaginais que les interventions de Verdy p dans les modèles de conjugaison avaient été corrigées. Il faudrait le faire d'urgence. Lmaltier19 décembre 2008 à 14:30 (UTC)
Non, excuse-moi : les interventions de Verdy sont à mon avis globalement positives (j'espère qu'il me lit), même s'il se trompe dans le cas des participes présent(s) (et qu'il persiste à écrire 250 lignes d'explications quand 5 suffiraient). S'il se trompe, nous corrigeons, mais je suis convaincu que ce que fait Verdy va généralement dans le bon sens. --Szyx19 décembre 2008 à 20:46 (UTC)
Tout ça n'a pas grand chose à voir avec le problème et avec ce que j'ai dit. Mais je ne peux pas m'empêcher de dire que ce genre de projet a avant tout besoin de beaucoup de contributeurs. Tout ce qui fait diminuer leur nombre est négatif pour le projet. Lmaltier19 décembre 2008 à 21:19 (UTC)
Remarquez, on pourrait rajouter des flêches (à la Google Trends) mentionnant différents évènements comme l'import de noms de communes, l'import de gentilés, la création de nouvelles flexions, etc. Mais il nous faudrait un journal récapitulatif pour ça ( on a ça ?). - Dakdada(discuter)20 décembre 2008 à 09:10 (UTC)
Je viens d'ajouter les codes nécessaires aux liens directs sur les sections pour {{-adj-dém-}} et {{-pronom-dém-}}. Il serait bien, je pense, que (1) on fasse le tour de tous les modèles qui n'ont pas encore de code pour en ajouter un (2) que les codes soient listés à un endroit adéquat. --Szyx20 décembre 2008 à 08:49 (UTC)
Ta faute ? Non ! Je ne voulais pas dire que c'était la faute de qui que ce soit, juste qu'il y avait une amélioration à faire. --Szyx20 décembre 2008 à 09:30 (UTC)
Image: remplacé par Fichier:
Je ne sais pas si vous êtes au courant, mais je mets ce message à toutes fins utiles (en fait c'est la 2e fois, mon bouzin ayant planté entre-temps, mais vous vous en fichez).
Depuis quelques jours, une mise à jour de MediaWiki a remplacé le préfixe de l'espace de nomsImage: (vo : Image:) par Fichier: (vo : File:)
Au vu de ce que j'ai attrapé au vol sur le Bistro de Wikipédia, cela ne change rien à court terme pour ce qui nous concerne. Je mettrai néanmoins à jour Aide:Espace de noms quand je serai motivé.
PS : l'image que j'ai mis deux sections plus haut utilise la syntaxe nouvelle : ]. Afin de défendre ma réputation, je précise que j'étais déjà au courant depuis quelques jours, même si je dois admettre que je me suis fait prendre au dépourvu – je n'avais pas entendu parler de cette modification avant qu'elle soit mise en place ) --Szyx20 décembre 2008 à 10:16 (UTC)
Ne vous inquiétez pas, "Image:" est maintenu comme un alias (et il le restera pour longtemp avec ses options actuelles, dixit les développeurs de MediaWiki qui nous ont informés sur Wikipédia et sur Meta), d'autant qu'il est prévu que "File:" serve à désigner en priorité les liens vers les pages de description (et n'autorise alors qu'un nombre limité d'options adaptées principalement pour afficher les images fixes), alors que d'autres préfixes que "Image:" seront ajoutés pour supporter d'autres rendus que celui des seules images et des vidéos et clips audio en tant qu'objet contenant un player.
La principale motivation actuelle était davantage liée au fait que "Image:" devait être utilisé pour faire un rendu du son ou des vidéos dans un objet qui n'est pas une image mais un player (non paramétrable en fonction du type de média effectif, ce qui fait qu'il manque de fonctionnalités).
Parmi les extensions attendues et actuellement discutées, il y aura peut-être le rendu des PDF (une page à la fois, possibilité d'indiquer la page), l'extraction d'une image d'aperçu dans une vidéo (avec un paramètre timecode par exemple) affichée comme une image sans player, l'extraction de sous-images (recadrage) à partir d'une image plus grande, certains effets sur les images comme la rotation, la sélection d'une bande sonore pour les vidéos multilingues, et le paramétrage du player (ces extensions devraient alors utiliser d'autres préfixes que "File:" qui ne peut faire qu'un rendu par défaut, et dont les options supportées pour les images peuvent être génantes, et le support d'autres types de médias (par exemple l'adressage d'un fichier dans une archive).
Il n'est pas exclu que "Image:" supporte des options supplémentaires spécifiques aux images et que "File:" ne supportera pas. Je ne pense donc pas au vu de ces descriptions (et des développements en cours d'autres moteurs de rendus des fichiers que le seul moteur de "thumbnails") qu'il faille changer "Image:" en "File:" dans les pages affichant les images ou icônes, mais qu'on devrait le faire en revanche pour remplacer ]" par ] ou ] si on ne doit afficher qu'un lien vers la page de description du média. En toute logique on devrait aussi remplacer "]" par "]" ou ] pour les clips vidéos ou sonores qui ne sont pas des images au sens strict. verdy_p20 décembre 2008 à 12:36 (UTC)
Verdy, tes explications sont intéressantes et utiles (et je n'avais pas vu que tu avais mis à jour la page d'aide, merci), mais quand donc apprendras-tu à synthétiser ta pensée en quelques lignes ? --Szyx20 décembre 2008 à 12:44 (UTC)
C'est parcequ'on lui a dit qu'ici, contrairement aux dicos papier, il avait la place . Merci pour les explications. Euh, c'est Fichier:... en File:... non ? Stéphane8888discuter20 décembre 2008 à 21:37 (UTC)
Effet de bord inattendu : c'est MediaWiki qui modifie ce que j'ai écrit (je viens de mettre nowiki pour clarifier...). verdy_p21 décembre 2008 à 06:48 (UTC)
Liens vers le TLFi
Pour information, j'ai créé une fonction javascript (je commence à avoir le coup de main) pour corriger les liens vers le TLFi dans le cas où il y a des caractères accentués (ce qui n'est pas rare). Pour cela les utilisateurs doivent... rien faire, c'est automatique, plus la peine donc de corriger à la main. enfin il faut juste que javascript soit activé
D’ailleurs le CNRTL regroupe (en plus du TLFi), les 4e, 8e, et 9e éditions du dictionnaires de l’Académie française, ainsi que le BDLP, le BHVF, et le DMF. On pourrait peut-être modifier le modèle en conséquence. Cdlt, VIGNERON * discut.22 décembre 2008 à 08:24 (UTC)
Le modèle est sensé lier directement aux articles du TLFi, pour les autres éditions on pourrait en effet rajouter des liens dans les modèles {{R:DAF4}}, {{R:DAF8}}, {{R:DAF9}} et éventuellement créer les autres. - Dakdada(discuter)22 décembre 2008 à 08:45 (UTC)
Pour résumer, l'auteur a recherché Métonymie et est tombé sur une page en impasse (NB : je suppose qu'il n'est pas passé par la recherche mais directement par l'URL, car il aurait sinon été automatiquement redirigé vers la bonne page). Le problème c'est que le Wiktionnaire possède bien un article métonymie mais comme les redirections d'un mot en majuscule vers un mot en minuscule sont effacés (voir les conventions à ce sujet), il n'y a pas été renvoyé directement.
La page sur laquelle il est tombé proposait pourtant de renvoyer vers l'article correct via un lien, mais ce lien était enfoui dans le tableau, ce qui a fait penser qu'il n'y avait pas d'article (ça ne saute en effet pas aux yeux).
C'est pourquoi j'ai essayé de rendre ce passage plus clair en mettant bien en évidence (en grosses lettres) les articles qui pouvaient correspondre à la requète. Vous pouvez voir le résultat dans une recherche du genre Métabolisme. Pensez-vous que cela suffise ? - Dakdada(discuter)20 décembre 2008 à 16:54 (UTC)
Fait. Essayez donc RoM (j'ai fait exprès de faire un truc étrange). Ce n'est pas parfait () mais c'est le mieux qu'on puisse faire sans avoir recours à une vraie recherche. - Dakdada(discuter)20 décembre 2008 à 22:14 (UTC)
À mon avis, ce serait mieux si cela s'affichait dans le même cadre que le reste du message. Mais je ne disais rien parcequ'il est probable que c'est techniquement difficile. --Szyx20 décembre 2008 à 22:18 (UTC)
J'aime bien l'idée mais je ne suis pas sûr qu'il faille mettre ce message en si gros caractères ! Ça donne l'impression qu'on gueule le mot à la figure de celui qui l'a tapé avec une capitalisation indésirable ici. C'est tout de même très utile pour éviter de créer des redirections inutiles.
Suggestions/questions :
On pourrait faire la même chose pour les apostrophes ASCII et ne plus avoir à les rediriger systématiquement vers des apostrophes typographiques ?
Malheureusement tant qu'on n'aura pas de fonction de parseur plus sophistiquées, on ne pourra pas faire cela autrement qu'avec des redirections normales. - Dakdada(discuter)21 décembre 2008 à 11:03 (UTC)
Comment tu as fait pour détecter les autres capitalisation dans la page de recherche ? Tu as du patcher un bout de PHP dans une extension MediaWiki, non ? Ce même petit bout de code PHP pourrait détecter la présence des apostrophes ASCII dans le titre non trouvé, et rechercher les noms d'articles écrits plutôt avec l'apostrophe typographique. verdy_p21 décembre 2008 à 11:09 (UTC)
A ce sujet il ne serait pas inutile d'avoir une fonction Parser pour effectuer des remplacements de caractères simples dans une chaîne... Il me semble que cette extension Mediawiki (du type {{replace:texte|chaine recherchée|chaine remplacée}} (éventuellement avec une expression régulière et un paramètre pour mettre les drapeaux de paramètres de recherche/substitution, une fois réglé des problèmes de sécurité liés aux possibles références directes aux variables internes de PHP) existe déjà (mais elle n'est pas chargée ici). Son code PHP est simplissime (au moins pour la recherche simple sans expressions régulières). verdy_p21 décembre 2008 à 11:18 (UTC)
De cette extension ils n'ont intégré dans les ParserFunctions standards que celles concernant URLENCODE:, URLDECODE:, ANCHORENCODE: et ANCHORDECODE: ...
C'est vrai que certaines fonctions en font trop (par exemple LEN:, RPOS:, EXPLODE:, etc. mais la substitution simple avec REPLACE: aurait pu être adoptée quand même, car elle n’est pas coûteuse et aurait été très utile pour compléter LC:, UC:, LCFIRST: et UCFIRST: qui sont insuffisants... verdy_p21 décembre 2008 à 13:41 (UTC)
Peut-on le faire aussi pour les liens rouges (des termes avec une mauvaise capitalisation ou apostrophe), afin qu'ils ne proposent plus une création directe, mais aille sur la page de recherche affichant ce message, pour des cas comme ceux là ?verdy_p21 décembre 2008 à 06:57 (UTC)
Les gros caractères sur la totalité du titre sont superflus à mon avis (et trop gros), étant donné qu'il y a déjà le cadre et les caractères gras sur le nom trouvé et proposé. J'alignerais simplement le style du cadre sur le style de la boîte en dessous. verdy_p21 décembre 2008 à 11:18 (UTC)
Voir présentation alternative dans Discussion MediaWiki:Noarticletext (avec une présentation unifiée). (note: les tests sont désactivés par un bout de code "xxx" destiné juste à montrer ce que cela peut afficher, et aucun lien réel vers un article existant n'est donc proposé en bleu (no voit les titres proposés en rouge ou noir). verdy_p21 décembre 2008 à 12:37 (UTC)
Excellent changement, au moins on sait où est l'erreur quand on tape le mot. Je précise que je suis effectivement passé par l'URL, étant wikipédien c'est une habitude de facilité. Mais plus simplement, pourquoi ne pas considérer qu'en l'absence de double-sens (comme État c/ état) on ne pourrait pas avoir une redirection systématique de la majuscule vers la minuscule (et on supprime la redirection le jour où une nouvelle entrée doit être créé avec la majuscule)? Ca permettrait de sauter une étape. Popo le Chien21 décembre 2008 à 22:47 (UTC) bon évidemment pour PC ça commence à faire compliqué.
Flexions de verbes à vérifier
La Catégorie:Wiktionnaire:Flexions à vérifier est en cours de remplissage (automatique). Visiblement il y a du travail pour recenser tous les subjonctifs oubliés dans de nombreux verbes qui y sont listés. Notes:
suite à une demande sur ma page de discussion, le modèle {{fr-verbe-flexion}} gère maintenant le paramètre impers=oui pour les verbes impersonnels (voir appert pour « il appert que... », et pas « elle/on appert »).
Le modèle fait également maintenant la détection des subjonctifs non oubliés pour les verbes du second groupe (il autodétecte la présence du passé simple), ce qui a nettoyé la catégorie ci-dessus.
Le modèle gère en plus un autre paramètre optionnel grp=3 pour nettoyer de la catégorie les flexions de verbes au troisième groupe pour lesquelles il n'y a pas d'oublis des subjonctifs (voir a, as, es, bois, etc.). Ce paramètre n'a pas d'autre effet actuellement que de désactiver le test des conjugaisons "oubliées". Il n'y a pas de raison d'indiquer partout le groupe du verbe (je pense qu'il n'est utile que pour le troisième groupe, et uniquement pour faire le ménage dans la catégorie ci-dessus).
Bon courage pour modifier les articles (je ne sais pas si on peut le faire automatiquement car il faudrait croiser les articles avec les conjugaisons mentionnées dans le verbe à l'infinitif difficile à déterminer à partir de la seule flexion, et pas toujours indiqué de façon uniforme dans l'article sur la flexion verbale !
verdy_p21 décembre 2008 à 07:26 (UTC)
Note : avant les modifications du modèle, la catégorie comptait environ 800 entrées ; j'ai pu réduire leur nombre à environ 400 en autodétectant les flexions régulières du 2e groupe (par leur passé simple). En revanche, je m'aperçois que les oublis des flexions du subjonctif dans le 1er groupe sont fort nombreuses. Les statistiques sont en train de monter rapidement. La catégorie va mettre environ 3 jours à se remplir (en tâche de fond) avec les détections faites par le modèle modifié dans sa dernière version, j'estime que la catégorie contiendra environ 5000 flexions une fois terminé.
Cela veut dire qu'il n'est pas utile de se précipiter pour corriger tout ça : je suggère de ne s'occuper que de corriger les flexions des verbes du 3e groupe (nettement moins nombreux) dont la plupart sont déjà correctes (et ne nécessitent généralement que l'ajout du paramètre "grp=3" dans l'appel du modèle).
Tout le reste, c'est à dire les verbes du 1er groupe et la plupart des verbes (réguliers) du 2e groupe devrait pouvoir se traiter par robot, qui pourra simplement récupérer la liste des articles listés dans cette catégorie (une liste à télécharger d'abord pour la relire avant de lancer le robot, car il peut s'y glisser de nouvelles flexions de verbes du 3e groupe), avant d'ajouter les temps et modes manquants.
Je ne sais pas s'il faut que ce robot modifie les définitions : certaines mentionnent seulement « # Du verbeaccaparer. » (avec un lien superflu à mon avis sur le mot verbe, étant donné que c'est un terme très générique, déjà utilisé dans le titre de section posé par {{-flex-verb-|fr}}), d'autres mentionnent « # Première personne du singulier de l’indicatif présent du verbeaccaparer. » avec la liste complète énumérant les définitions pour chaque mode, temp et personne, ce qui semble un peu redondant avec ce qu’affiche le modèle des flexions, mais dont certaines définitions sont suivies d'un exemple de citation.
Pour moi, dans un premier temps il suffit seulement de modifier les seuls paramètres du modèle {{fr-verbe-flexion}} (sauf si le robot sait se débrouiller pour interpréter et reformater les définitions qui suivent.
Cependant je suggère que les définitions des verbes du 3e groupe (faites facilement à la main car relativement peu nombreuses en comparaison des deux autres groupes) adopte une forme standard.
Attention :
Les verbes "irréguliers" du premier groupe ne semblent pas échapper à la règle d'identité du présent ou imparfait de l'indicatif et du subjonctif présent.
Cependant il y a des verbes irréguliers (assez rares) dans le 2e groupe qui échappent à la règle classique (comme haïr et amuïr qui ont un tréma sur la terminaison, un tréma qui peut muter avec des prononciations spécifiques, ainsi qu'une irrégularité de conjugaison du subjonctif par rapport à l'indicatif et aux autres verbes en "-ir" du groupe ; traditionnellement on les classe dans le 2e groupe même si haïr en toute logique serait mieux classé dans le 3e, alors que amuïr est plus régulier car il garde son tréma "historique" partout même si sa prononciation ignore ce tréma et prononce donc le u qui le précède comme une semi-consonne. Comme le 2e groupe est autodétecté par l’identité de l'indicatif présent avec le passé simple, ces verbes irréguliers du 2e groupe pourraient être listés par le modèle (vérification des subjonctifs oubliés), à moins qu'on leur indique grp=3 dans l’appel du modèle {{fr-verbe-flexion}}.
(Je me demande si l’orthographe traditionelle amuïr n’a pas aussi une orthographe révisée amuir sans ce tréma historique qui ne joue absolument plus aucun rôle, que ce soit dans la prononciation ou dans la conjugaison... (ce tréma traduit la présence d’un ancien e caduque amuï, le même e qu’on trouve encore dans le mot muet qui a la même racine étymologique). J'ai lu en effet les noms dérivés amuissement et amuïssement, sachant qu'on ne prononce plus le u comme une voyelle simple comme on le faisait quand il y avait un e caduque après lui)
Après tout, on a eu aussi successivement vraiement encore utilisé aujourd’hui avec un e caduque écrit mais le plus souvent (pas toujours) amuï dans sa prononciation de nos jours, puis vraïment qui n'a pas été très utilisé et est devenu rapidement vraiment (l'orthographe vraiement existe encore, et c'est d'ailleurs toujours celle que j'ai apprise en premier avec un e que je prononce encore tellement il me paraît logique grammaticalement à cet endroit et conforme aux autres adverbes dérivés d'adjectifs ; je n'aime pas trop l’amuïssement systématique des e caduques dans le langage parlé courant, même s'il est fréquent dans le discours rapide ; je prononce toujours Erreur sur la langue ! ces e dans un discours soigné).
Concernant le 3e groupe, le modèle fait des détections correctes (par exemple abattions et abattiez) où les subjonctifs présent ont été oubliés alors que l'imparfait seul est listé : il ne suffit pas de mettre grp=3 pour les sortir de la catégorie, mais il faut bien ajouter les subjonctifs manquants.
Google montre que certains ont vraiment tendance à écrire vraiement, mais quand même pas énormément.
Plus de 443 000 pages trouvées avec "vraiement" par Google, dont pas mal dans ds romans, articles de presse, ce n'est pas une orthographe mineure, ça veut dire que nombreux sont ceux qui l'emploient ! (C'est peut-être peu à côté de 44 millions de page avec "vraiment"). Mais en en regardant beaucoup on constate que ce sont des pages relativement soignées (pas des blogues ou des forums). Il est bizarre que vous ayiez supprimé vraiement (dont il existe des références historiques indéniables, par des auteurs fameux). verdy_p1 avril 2009 à 06:05 (UTC)
Par curiosité, de quelle région du monde es-tu pour avoir appris l'orthographe vraiement (et pour prononcer ce e !) ? (un mot me suffirait comme réponse) Lmaltier21 décembre 2008 à 18:04 (UTC)
De Haute-Bretagne principalement, initialement à Rennes puis dans un village près de Rennes (mais aussi dans ma famille dans le Nord où ce e est prononcé). Il ne l'est pas apparemment ici en Poitou-Charentes, et je ne l'ai pas entendu à Paris. Et j'ai beau faire, je frappe toujours vraiement en premier que je corrige après si je le vois, sachant que cet usage est vieilli. verdy_p22 décembre 2008 à 14:14 (UTC)
Il y en a bien qui prononcent Erreur sur la langue ! les flexions de verbes en -ai, alors j'ai cessai de m'aitonnai. --Szyx21 décembre 2008 à 23:20 (UTC)
Moi y compris, et c'est aussi comme ça que je l'ai appris (quand j’entends un Erreur sur la langue ! à la place d’un Erreur sur la langue !, j'ai réellement toujours l'impression que la personne se trompe de temps). Mêmes journalistes à la TV sur les grandes chaînes nationales s’appliquent souvent à prononcer Erreur sur la langue ! dans un discours soigné ; sur les autres chaînes, les présetnateurs s'en fichent royalement et prononcent n'importe lequel suivant le contexte ou l’humeur).
Les terminaisons en -ai sont toutes prononcées Erreur sur la langue ! et non Erreur sur la langue ! de façon traditionnelle depuis très longtemps (elles étaient même obligatoires dans l’enseignement jusque dans les années 1970, et certaines professeurs continuent de les enseigner car ce n’est pas proscrit et aide à apprendre les conjugaisons correctes sans s et ne pas confondre le présent ou passé simple avec l'imparfait), contrairement aux terminaisons en -aie, -aies, -ais, -ait, -aient qui sont bien prononcée Erreur sur la langue !. Je ne sais pas trop ce qu'il en est dans le Sud de la France, mais je sais que cet usage tend à se perdre phonétiquement (pas pas encore phonologiquement, les distinctions de temps étant encore jugées importantes par nombre de profs).
(ainsi que parfois le verbe dans tu es, il est, mais c’est plus rare et ça dépend du contexte ou du locuteur : on les prononce Erreur sur la langue ! avant un mot commençant par Erreur sur la langue ! pour forcer l’alternance des voyelles, et on prononce éventuellement la liaison sur le t ou le s final ; d'autres aussi, comme moi, les prononcent systématiquement Erreur sur la langue ! avec la liaison éventuelle). verdy_p22 décembre 2008 à 14:14 (UTC)
Locutions
Il y a beaucoup de mots simple qui utilisent {{-loc-}} (voir râteau, transept, cuisse). Le problème c'est que c'est un titre de troisième niveau, pas de quatrième. Je ne trouve pas comment faire pour faire un titre de quatrième niveau permettant de lier un mot aux locutions liées (notamment, ce n'est pas marqué ici : Convention:Structure des pages). Est-ce qu'il existe un modèle pour cela ? Si non, on devrait en créer un. Koxinga21 décembre 2008 à 16:04 (UTC)
Convention:Structure des pages précise bien que les dérivés (donc sous -drv-) sont des mots et "La sous-section expressions NE contient PAS les locutions et NE contient PAS les mots composés".~Je n'ai pas trop de solution, mais il y a un problème, au moins sur cette page d'aide, il faudrait alors la mettre à jour. Koxinga21 décembre 2008 à 16:17 (UTC)
Je sais bien, mais soit on décide de mettre expression et locution ensemble, soit on crée un nouveau modèle pour les locutions. Dans les deux cas, il faut le dire sur la page de structure des articles. Koxinga21 décembre 2008 à 16:46 (UTC)
Les mots et locutions dérivées sont sous -drv-, -exp- étant destiné aux phrases complètes (proverbes, dictons, par exemple). Quant à -loc-, il faudrait peut-être le supprimer pour éviter les tentations (il faut utiliser le modèle précis : -loc-nom-, etc.). C'est sûr que la page d'aide est à revoir, au minimum pour la distinction -drv-/-apr- qui est incompréhensible (et qui n'a pas vraiment de sens, donc est inapplicable). Lmaltier21 décembre 2008 à 17:55 (UTC)
Supprimer {{-loc-}}, c'est tentant... Je vais étudier la question (je veux dire quantifier le volume du travail pour pouvoir le faire). --Szyx21 décembre 2008 à 23:15 (UTC)
French Wikipedia introduces advertising links on image pages (copy from here)
French Wikipedia introduces advertising links on image pages
On the French Wikipedia, all description pages for images hosted on Wikimedia Commons have been changed to include a link to purchase a poster print of that image from "WikiPosters", a service run by Messages SAS (a 90 employee printing company based in Toulouse). The company has donated 500€ to the Wikimedia Foundation and 500€ to Wikimedia France, and intends to donate 1,50€ to Wikimedia France for each poster sold. However, the agreement between Messages SAS and the French Wikipedia community, while requiring the latter to insert those links, does not seem to place binding financial obligations on the company.
Technically, this is realized by changing the MediaWiki:Sharedupload system message using JavaScript to add a link "Obtenir un poster de cette image (nouveau !)" ("Obtain a poster of this image (new!)) to the top right of each image description page. After clicking on the link, the reader can choose between the ordering pages of different poster vendors (currently only wikiposters.fr).
Regards, HaeB (talk) 08:59, 20 December 2008 (UTC)
L'extremaduran est une langue qui porte le code "ext"
Bonjour,
en récupérant des traductions pour l'article ivoire, j'ai trouvé une traduction pour l'extremaduran. Le problème c'est que cette langue porte le code ISO 639-3 "ext", ce qui entre en conflit avec le modèle {{ext}}. Avez vous une proposition pour corriger le problème. Le code ISO 639-2 de cette langue est "roa" qui est un peu fourre-tout (langues romanes). On ne peut pas modifier le modèle {{par ext}} car un nombre important de page l'utilise. Une idée ? Pamputt22 décembre 2008 à 10:15 (UTC)
Je pense qu'on va en effet devoir changer le nom du modèle, ce n'est pas la première fois que cela arrive. Il n'y a pas tant de pages que ça qui l'utilisent, trois ou quatre mille, c'est à la portée d'un bot. On prend quoi comme non, {{extension}} ? Koxinga22 décembre 2008 à 10:24 (UTC)
J'ai fait tourner un programme sur le dernier dump pour trouver des pages qui avaient l'air étrange. Les résultats de mes investigations se trouvent ici. Rien d'insurmontable, mais quelques centaines de pages mal formées à chaque fois.
C'est une bonne façon de rendre le wiktionnaire plus cohérent, plus "sérieux", et c'est plus sympa si on le fait à plusieurs ! N'hésitez pas à participer au nettoyage, à me voler un bout d'une liste pour vous en occuper vous-même, à me suggérer d'autres idées de choses à vérifier. Je vais essayer d'approfondir mon analyse de toute façon mais si vous avez quelque chose qui vous tient à cœur, je peux commencer par ça.
Attention dans la liste "pages utilisant un modèle trad avec trois arguments non nommés" les arguments cachés en paramètre 2 contienne l'orthographe correcte, alors que la cible désignée par le paramètre 1 (celui qui s'affiche puisque le paramètre 2 est ignoré car non nommé "dif") est erronée. On a le cas sur des noms communs allemands où la cible comporte une minuscule initiale. Je ne sais pas qui a eu l'idée de nommer ce paramètre « dif » alors que dans un lien habituellement on ne nomme pas le second paramètre optionnel.
C'est peut-être correct en alémanique/suisse allemand/alsacien {{gsw}} mais pas pour le code {{de}}. Dans un tel cas, il faut dupliquer la traduction dans les deux langues pour lever l'ambiguïté orthographique, car elle a certainement été entrée par des Suisses ou Alsaciens (voire des Frisons de Belgique). Ce ne serait pas inintéressant de savoir qui justement, ou s'il s'agit d'un import par un Bot (et la "faute" serait sur le Wiktionnaire allemand où les suises allemands mélangent leurs usages avec minuscule avec celui du haut-allemand)
Pour compliquer, on peut noter que la Suisse a aussi accepté dans une réforme orthographique encore récente les minuscules dans les noms communs, même en allemand standard et pas seulement dans la variété alémanique, ce qui agace profondément les Allemands du Sud et Autrichiens qui semblent attachés à leurs capitales, mais pas les Frisons (même ceux en Allemagne) qui ont adopté aussi comme les Suisses les règles néerlandaises pour les noms communs (règles presque semblables à celles du français à l'exception des noms de langues et cultures et des adjectifs formés sur les gentilés, où nous mettons des minuscules là où Néerlandais, Allemands et Anglais maintiennent encore la capitale).
Ça alimente régulièrement les discussions sur la Wikipédia allemande où cette différence est régulièrement source de conflits d'éditions (c’est aussi ce qui a motivé un certain nombre de Suisses pour promouvoir l’alémanique et vouloir l’utiliser pour le haut-allemand standard de Suisse, en entrant cette fois en conflit avec les vrais alémanistes qui ont leur vocabulaire et leurs grammaire propres et n'aiment pas trop l'intrusion trop fréquente de prétendus "synonymes" allemands mais pas alémaniques).
Pour ce qu'on doit faire ici pour ces mots allemands, je ne pense pas qu'on doive rentrer dans le débat : en France ou ailleurs qu'en Suisse, on applique toujours les règles de l’Allemagne dans l'enseignement (cette réforme helvétique est encore ignorée même si elle est supportée par certains en Allemagne), mais des Suisses bilingues français-allemand qui contribuent ici (relativement peu nombreux en Suisse où les barrières linguistiques sont presque aussi fortes qu’en Belgique entre les cantons, avec parfois un certain niveau d’intolérance dans certains villages divisés en deux par une frontière invisible de chaque côté d'une même rue ou d’une petite rivière !) risquent de ne pas être d'accord... Mais ici on n'a pas besoin de maintenir des synonymes en Allemand qui ne diffèrent que par une capitale même pas obligatoire en Suisse ! D'autant qu'ici on a des Alsaciens qui ne veulent pas de la confusion entre langues alémanique et allemande. Ce cas pour l’allemand donne une situation un peu similaire à notre orthographe réformée de 1990 (non obligatoire), d’où notre préférence ici pour l’orthographe française traditionelle acceptée normalement par tous.
C'est moi qui ai nommé cela, parce que avec toute la complication du modèle trad, ce n'était pas clair du tout qu'il doive se comporter comme un lien. Je pense plus généralement que multiplier les arguments non nommés, surtout quand ils sont optionnels, est une très mauvaise idée. Le modèle trad possède déjà deux arguments non nommés, c'est bien assez de mon point de vue. En vrai, si j'avais vu qu'il était aussi utilisé avant, je ne l'aurais peut-être pas changé aussi cavalièrement, mais son existence n'était documenté nulle part, j'ai cru que c'était un vestige du tout début.
D'ailleurs, l'usage de dif ne me semble pas très adapté à l'allemand et les liens n'étaient déjà pas bons avant. J'avais plutôt compris qu'il était destiné à l'arabe ou l'hébreu. L'usage de dif pour indiquer un lien différent de ce qui est affiché me paraît trompeur et pas très intéressant. On en avait déjà parlé il n'y a pas longtemps. Si on ne catégorise plus dans ce modèle, il vaut mieux alors ne pas s'en servir du tout. Koxinga22 décembre 2008 à 15:23 (UTC)
Au passage, il y a aussi à nettoyer Catégorie:Wiktionnaire:Flexions à vérifier qui compte près de 9 000 entrées (la mise à jour automatique semble s'être arrêtée en cours, ou bien la tâche de fond sur le serveur a changé de priorité, pourtant il y en a plein d’autres : j'estime qu'il y en a plus de 25 000, la plupart pour des verbes du 1er groupe qui sont aussi très souvent des noms communs au singulier ou pluriel). Cela concerne les subjonctifs présent oubliés avec les indicatifs présent (ou imparfait pour les 1re et 2
Comment tu ferais pour ôter ou changer/préciser {{-loc-}} dans des articles comme à bas de ? Ce n'est pas à proprement parler une locution nominale (elle n'a pas valeur de nom commun) ni une locution adverbiale (elle ne complète pas un verbe) mais sert en quelque-sorte de préposition pour introduire un groupe nominal, l'ensemble devenant un complément d'objet indirect ou un complément de nom. Peut-on parler alors de « locution prépositionelle » ? verdy_p22 décembre 2008 à 20:13 (UTC)
On n'a pas une page qui recense les grands travaux à faire, et où les bonnes volontés manque (ou le courage, ou un bot pour faire le gros du travail) ? verdy_p22 décembre 2008 à 20:07 (UTC)
La vérité, c'est que nous sommes en sous-effectif chronique (à la louche, une centaine de contributeurs actifs, pour 1 million d'articles, c'est totalement délirant, non ?) --Szyx22 décembre 2008 à 20:16 (UTC)
Oui mais cette centaine est bien équipée avec ses outils, et arrive à faire beaucoup de travail et assez vite (on a 1 million 200 mille articles, la croissance est de plus en plus rapide depuis l'automne, comme quoi nos outils s'améliorent, quoi qu'en disent certains !). On n'a pas forcément besoin de beaucoup d'utilisateurs très actifs, mais juste de beaucoup d'utilisateurs occasionels qui peuvent passer apporter leur graine d'inspiration de temps en temps, ou corriger des choses qu'on ne voit plus ou pas nous même (nous on a les outils pour revérifier le tout, ce qui donne beaucoup de travail sur le serveur ici comparé au serveur du Wiktionnaire anglophone malgré ses plus nombreux contributeurs qui font beaucoup plus d'erreurs dispersées difficiles à retrouver).
D'ailleurs j'aimerais bien qu'on reparle de notre page d'accueil (et ma proposition de refonte ci-dessus) qui doit en faire fuire plus d'un qui ne sait pas trop où aller ni comment utiliser le wiktionnaire. Si je l'ai faite c'est justement pour à la fois bien montrer ce qui est fait ici, et fournir la plupart des liens utiles pour une navigation rapide sous une forme condensée en tête de page. L'accueil actuel a trop de blancs, trop de place pour des zones à liens rouges (tâches à faire), et franchement pas assez pour la consultation. Hors de nouveaux contributeurs arriveront ici d'abord s'ils commencent à se servir du wiktionnaire et le trouvent pratique à utiliser et facile à naviguer. Notre petite centaine de gros contributeur ne passe pas souvent par cette page (mais ils pourraient utiliser plus facilement la page d'accueil que j'ai proposée qui contient tous les liens essentiels de façon accessible, et mieux classés que dans l'accueil actuel). verdy_p22 décembre 2008 à 20:34 (UTC)
Je trouve que ce serait une bonne idée d'avoir une page comme celle-là ici.
Surtout si, comme sur en:, un lien est présent et très visible en haut de chaque page (juste sous l'appel aux dons surement encore un truc de javascript auquel je ne comprends rien).
Oui, je suis d'accord. Voire même mettre un espèce de "tip of the day" si on n'a pas beaucoup de nouvelles, pour répandre les bonnes pratiques. Koxinga22 décembre 2008 à 18:12 (UTC)
Je me demande si j'ai jamais vu ce "dismiss" ici ! En tout cas, s'il est désactivé et ne peut plus réapparaître c'est à cause d'un cookie stocké sur ton PC (comme c'est aussi le cas pour les annonces du site comme la campagne de levée de fond qu'on peut "réduire" de façon assez durable, saus toutefois le cacher complètement). Regarde dans ta liste de cookies de ton navigateur ceux associé au site où tu es, et supprime-le, tu devrais revoir apparaître le message disparu. verdy_p22 décembre 2008 à 19:58 (UTC)
Au fait, je confirme que le javascript sur le wikitionnaire anglais utilise bien un cookie pour cacher la "site notice". Ce cookie s'appelle "dismissSiteNotice" (dans le domaine "en.wiktionary.org"), et a une durée permanente (à mon avis c'est un bogue: aucun cookie ne devrait avoir une validité permanente, mais au plus 24 heures, ou éventuellement jusqu'à un mois pour un cookie d'authentification pour le login automatique sur un site). Il est créé et prend la valeur "2.0" quand tu cliques sur "dismiss". Supprime ce cookie et tu auras à nouveau l'annonce. verdy_p22 décembre 2008 à 20:22 (UTC)
Tu pourrais mettre ça dans la boite "contribuer" à gauche après "communauté" (enfin, si tout le monde est d'accord) ? --Szyx22 décembre 2008 à 23:28 (UTC)
Suite aux problèmes du modèle {{ext}}, précédé par le modèle {{mod}}, et tandis que le wiktionary se bat avec ses propres démons (see, law, ...), j'ai essayé de faire un peu le point sur la situation. Vous pourrez trouver les résultats sur ma page modèles 3 lettres.
Je pense qu'il faut dès maintenant changer les modèles en conflit, même s'il n'y a pas encore de contributions dans les 7 langues concernées. Les autres peuvent attendre par contre ... Je n'ai pas regardé les conflits avec les redirects, mais je pense qu'il faudrait les supprimer au fur et à mesure pour que les contributeurs ne prennent pas de mauvaises habitudes.
Je ne pense pas qu'il y ait urgence (il n'y a pas encore conflit). Un changement à la fois est préférable pour nos petites habitudes. Acquérons déjà le nouveau {{par ext}}. Je pense qu'un certain nombre de redirect, par exemple {{bio}}, n'apparaissent plus dans aucun article, et pourraient être supprimés. Stéphane8888discuter22 décembre 2008 à 22:05 (UTC)
Je pense au contraire qu'il faut faire le ménage : je viens de supprimer (proprement je pense) {{chi}}, {{REF}}, {{ref}}, {{hum}} (cf {{chim}}, {{RÉF}}, {{réf}}, {{humour}}). --Szyx23 décembre 2008 à 01:17 (UTC)
Je pense aussi qu’il faudrait rapidement (avant fin janvier) faire le ménage dans ces modèles. Il faudrait aussi améliorer les noms des modèles et utilise des noms clairs, explicite, accessible, etc. Ces abréviations et raccourcis créent plus d’inconvénients que d’avantage. PS : ne pas oublier de penser aux historiques et modifier les pages de documentation en conséquence. Cdlt, VIGNERON * discut.24 décembre 2008 à 09:30 (UTC)
Pour l'instant je n'ai fait que les cas simples (cf Utilisateur:Koxinga/modèles 3 lettres). Je n'ai supprimé que des redirections à l'historique plus ou moins vide, et après avoir vidé totalement les pages liées (ce qui implique en principe la mise à jour des pages d'aide). --Szyx24 décembre 2008 à 09:48 (UTC)
Vote sur les traductions et les boîtes déroulantes
J'ai écrit mon idée de ce à quoi devrait ressembler la page d'aide sur la section traduction.
Pour un article à une seule définition, pourra-t-on toujours faire coexister la forme suivante ?
{{-trad-}}
* {{T|de}} : {{trad|de|le mot en allemand}}
Je pense qu'il faut être le plus consistant possible. Même s'il n'y a qu'une définition, il faut prévoir le cas où une deuxième définition apparaît plus tard, ajoutée par un contributeur peu consciencieux. C'est ce qui arrive tout le temps et dans ce cas, les traductions perdent d'un seul coup énormément de valeur. Je pense donc qu'il faut résumer le sens, même lorsqu'il n'y a qu'une définition. On ne le fera pas forcément, il y a trop de travail ailleurs mais l'aide doit expliquer ce qu'on devrait faire ... Koxinga23 décembre 2008 à 11:48 (UTC)
La présence des {{m}}, {{f}}, {{n}} ne se justifie (à mes yeux) seulement lorsque les traductions se réfèrent à un des genres. Exemple : souple --> elásticomasculin, elásticaféminin
Je n'ai pas touché à cela, je ne sais pas trop quoi en penser encore. Je suis d'accord avec toi, ces petits modèles sont assez inutiles dans la plupart des cas (du moins une fois que les articles correspondant existent), mais on peut les laisser, ils ne gênent pas trop. Koxinga23 décembre 2008 à 11:48 (UTC)
Ayant relevé que mes modèles de redirection pour le grec ont été supprimés d'office sans que j'en sois informé, probablement à la suite certaines critiques formulées sur ma page de discussion. Or, ces modèles sont nécessaires pour la wikification pour le projet francophone. Ils permettent une mise en forme à partir des imports de puis le projet grec. La GFDL impose obligatoirement l'import de l'intégralité des historiques sous peine de violation de celle-ci. J'ai donc restauré les pages en question, en prenant bien soin par la suite, d'y adjoindre les modèles en langue française.
Depuis plusieurs semaines, je fais l'objet de critiques sur ce projet, ce qui m'a vivement indisposé. Dernièrement, j'ai eu maille à partir sur le fait que j'ai été reverté comme le dernier des vandales pour avoir simplement supprimé un lien manifestement POV, sur suggestion de Lou, sur l'article FMI. À la suite de quoi, je me suis mis en wikibreak sine die, et envisage sérieusement de rendre mes outils d'admnin, voire de quitter définitivement le projet. N'ayant jamais désavoué mes collègues admin sur ce projet, j'aurais aimé qu'il en faut de même à mon égard. À bon entendeur.-- Bertrand GRONDIN → (écrire)24 décembre 2008 à 12:34 (UTC)
Ne t'énerve pas sur le sujet, on va en discuter calmement. C'est moi qui en avait parlé sur la wikimédia (Wiktionnaire:Wikidémie#Cat.C3.A9gorie:Mod.C3.A8les_en_grec ici). Je pense en effet que c'est inacceptable d'avoir des noms de modèle en grec sur le wiktionnaire français. Tu avais même fait le modèle {{trad}}, donc ces modèles apparaissaient y compris sur des pages en d'autres langues ! Je ne comprend pas en quoi ces modèles sont nécessaires, et surtout pourquoi il est nécessaire de les laisser dans les articles. Tu ne peux pas importer et convertir les noms de modèles en même temps ? Koxinga24 décembre 2008 à 13:08 (UTC)
Je ne vois pas en quoi l'existence de ces modèles (qui sont en fait des redirection) gêne quoi que ce soit. Après on peut les remplacer dans les articles d'une manière ou d'une autre, mais sans urgence. --Szyx24 décembre 2008 à 13:32 (UTC)
Comprendre le concept des modèles n'est pas facile pour un éditeur débutant, et c'est déjà un gros souci pour permettre aux gens de participer. Si en plus certains de ces modèles sont en langue étrangère, d'ailleurs même pas en alphabet latin, cela devient rédhibitoire. Je sais bien que ce ne sont que des redirects, mais si un débutant tombe dessus (notamment sur une page qui n'a rien à voir, c'est pour cela que je prend l'exemple du modèle trad), il va s'enfuir ! Dans les pages en grec, ce point est déjà moins gênant mais pour quelqu'un qui veut faire de la mise en forme, cela reste étrange.
Cela ajoute tout un jeu de modèles en doublon. Si on fait cela pour le grec, pourquoi ne pas le faire pour les autres langues ? Et dans ce cas, combien de redirects de modèles ? Comment faire pour changer un nom d'un modèle sans provoquer plein de double redirects ? Comment font les codeurs de bot pour se tenir à jour ?
Enfin bref, c'est mon point de vue et je le partage. S'il y a eu un vote communautaire avant que je participe acceptant ces modèles, je m'y plierai. Sinon, je pense que cela mérite une discussion sérieuse. Koxinga
À l'origine, ceci permettait une wikification automatique en cas d'import. Là, j'ai converti wikifié les imports, je ne vois pas en quoi cela poserait problème. Si cela est inacceptable, ma présence sur ce projet le sera ipso facto.-- Bertrand GRONDIN → (écrire)24 décembre 2008 à 17:15 (UTC)
Mais non, reste, ne part pas pour une petite critique comme ça. Je m'en voudrais vraiment d'être la goutte d'eau qui fait déborder ton vase. Je ne critique pas la qualité et l'intérêt de ton travail. Ta méthode me pose problème sur un point, mais il y a des moyens beaucoup plus constructifs de résoudre ça, par exemple m'exposer les motivations qui t'ont poussé à créer ces modèles. J'ai lu ton annonce d'avril, mais je ne vois pas le problème technique à convertir les modèles. Si tu veux je t'écris un programme qui te fait la traduction des modèles. Koxinga24 décembre 2008 à 18:06 (UTC)
Le fait que le message (d'avril) de Grondin soit resté lettre morte n'est qu'un signe de confiance (j'ai du le lire et n'étant pas impliqué sur le grec, et n'ayant pas de raison, ni de l'aider, ni de douter de ce qu'il fait, je n'ai pas répondu.). S'il existe un moyen d'avoir le beurre (même fonctionnalité) et l'argent du beurre (des noms davantage français) alors tant mieux. Bonnes fêtes. Stéphane8888discuter24 décembre 2008 à 18:57 (UTC)
Ce qui est inadmissible, c'est attendre sept mois pour m'en foutre plein la gueule et balancer, sans demander mon avis, tout ce que ce que j'ai fait, alors, et je le redis, je préfère claquer la porte, car j'estime que je n'ai plus rien à faire sur ce projet.-- Bertrand GRONDIN → (écrire)25 décembre 2008 à 16:06 (UTC)
On n'a pas attendu sept mois, pas consciemment en tout cas. C'est moi qui ait posé la question et je n'étais pas là il y a sept mois. Arrivant sur ces modèles, je n'avais aucun moyen de savoir ce qu'ils représentaient. Ce n'est pas pour t'embêter, c'est juste que c'est maintenant que cela ressort. Si c'est justifiable, pas de problème, je me rangerai à tes arguments et je t'aiderai à documenter pour que le prochain qui se pose des questions ait des réponses claires.
D'ailleurs, je veux être sûr de moi. On n'a rien balancé de ce que tu as fait, si ? Ce sont juste quelques redirects qui ont été remplacés puis supprimés. On fait ça pour plein de modèles, pas seulement les tiens. Si tu veux on les recrée en expliquant à quoi ils servent, en expliquant qu'il faut les remplacer régulièrement mais pas les supprimer, et tout va bien.
Il faut être heureux ne serait-ce que pour montrer l’exemple.
C'est Noël, et je constate pourtant que ces derniers jours nous avons réussi à fâcher sérieusement deux des principaux membres de notre petite communauté (Grondin et Béotien lambda).
Je suis très déçu. Je pensais que le Wiktionnaire était au-delà de ce genre de choses. Mais non, de toute évidence.
J'ai proposé à Béotien de créer Catégorie:Contributeurs qui font la gueule. Je vous rassure, je n'ai pas pour l'instant l'intention de m'y inscrire, bien que je l'ai envisagé . Mais comme je l'ai dit à Stephane, « je n'étais pas dans un de mes jours de déprime » .
Désolé pour la citation non attribuée (pour tout le monde : la légende de l'image ci-contre), je l'avais mise pendant quelques jours sur ma pdd et j'ai fini par penser qu'elle m'appartenait, tellement je l'avais aimée (mais l'association avec l'image est de moi). --Szyx24 décembre 2008 à 21:09 (UTC)
Suite à une question de Verdy p lorsqu'on parlait de mes analyses de dump et de la catégorie des flexioons à corriger, je me suis rendu compte que l'on n'avait pas vraiment de page centralisant tous les grands nettoyages en cours. J'ai donc essayé d'en créer une : Wiktionnaire:Maintenance et nettoyage.
Qu'est-ce que vous en pensez ? N'hésitez pas à ajouter ce que j'ai oublié, à reformuler, etc.
Si vous avez un peu de courage, ça serait bien de vider la catégorie "Problèmes de syntaxe des modèles" avant le prochain dump (normalement dans deux jours). Koxinga27 décembre 2008 à 13:13 (UTC)
Merci à Darkdadaah d'avoir fini les modèles juste avant le dump. Le dump nouveau est arrivé, ce qui fait que j'ai transféré mes listes de pages à problème sur : Wiktionnaire:Maintenance et nettoyage. Promis, je ne vous spammerai pas tous les mois, c'est juste que c'est le début alors j'essaie de voir si cela intéresse quelqu'un ...
Bonjour. Je trouve qu’il est commun aujourd’hui de classer les pronoms indéfinis en quelques groupes comme les pronoms négatifs et les pronoms de libre choix.
Il est aussi bien connu qu’il y a un rapport étroit entre les pronoms et les déterminants.
Je crois donc qu’il sera utile d’avoir des sous-catégories des indéfinis.
J’ai déjà créé par ignorance des règles de Wiktionnaire deux catégories : Catégorie:Pronoms négatifs en français et Catégorie:Adjectifs négatifs en français, cette dernière étant pour les déterminants négatifs.
Mais certains utilisateurs sont contre les sous-catégorisations. Je voudrais entendre vos opinions dans Wiktionnaire:Gestion des catégories/2008-2009#Pronoms négatifs. Merci. — TAKASUGI Shinji25 décembre 2008 à 16:36 (UTC)
Liens inter-wiki
Bonjour, je remarque que le nombre de liens entre ce Wiktionnaire est faible en comparaison avec le Wiktionnaire anglophone (et d'autres bien sur). N'y a-t-il pas des robots qui créent des liens entre les articles ? Pourquoi pas ? Mglovesfun26 décembre 2008 à 23:55 (UTC)
« le nombre de liens entre ce Wiktionnaire est faible » Tout dépend si c'est entre la patte gauche du Wiktionnaire ou si c'est entre la patte droite du Wiktionnaire (Cf Coluche). --Szyx28 décembre 2008 à 17:49 (UTC) Pardonne-moi.
De quels liens parles-tu ? Des liens inter-articles ? En mai 2008 on en avait 1,9 million (contre 2,6 million pour l'anglophone)... et 11,4 millions pour l'ensemble de tous les wikionnaires. On représentait donc 17% à comparer avec les 23% (833000/3,8M) en nombre d'articles. L'écart est probablement dû au nombre plus important de flexions sur le Wiktionnaire francophone. Stéphane8888discuter28 décembre 2008 à 21:55 (UTC)
Alors j'ai tenté quelque chose sur son avatar en français : {{Utilisateur Identifiant unique}}. Merci de me donner votre avis sur l'aspect fonctionnel, qui se traduit essentiellement par ce bandeau sur les pages d'aide (fr, en, es, nl, pour l'instant). L'idée est que chaque page localisée ait les liens vers toutes les autres grâce au bandeau ci-dessous.
Je n'ai pas actuellement de liste de page concernées, mais que pensez-vous du principe d'avoir une documentation multilingue ? --Szyx28 décembre 2008 à 18:59 (UTC)
Cela a l'air assez fonctionnel, mais est très lourd en terme de rédaction (et de mise à jour). Tu as d'autres exemples de modèles concernés ? Il faut vraiment ne le faire que sur les modèles où cela a un intérêt indéniable. Koxinga28 décembre 2008 à 19:36 (UTC)
Pour le lecteur (qui n'utilise pas les modèles) c'est inutile. Cette documentation est destinée aux contributeurs. A-t-on vraiment les moyens (en terme de ressources humaines) d'instaurer cet idéal de traduction ? Est-ce vraiment utile ? Lorsqu'on modifie l'usage d'un modèle (voir à ce propos Wiktionnaire:Journal des contributeurs) il faut alors retraduire une flopée de pages, avec une structure compliquée. Ce serait donc une complication lors de la modification des modèles. Je citerai (approximativement) la phrase sentencieuse, et maintenant "culte", de Lmaltier : « On fait un dico pas un logiciel. » Mais l'idée et sa faisabilité sont précieuses, surtout pour les modèles liés à la collaboration interwiki. (modèle {{trad}} ?) Stéphane8888discuter28 décembre 2008 à 22:14 (UTC)
Tu ne m'as pas bien compris : il s’agit précisément des pages destinées aux contributeurs, et particulièrement aux contributeurs qui ne parlent pas français (« je me suis dit que les pages ainsi destinées aux étrangers »). Rien d'autre. --Szyx28 décembre 2008 à 23:41 (UTC)
Oh, et toute ma construction technique est justement destinée à ce qu'on ne soit pas obligé de faire mille modifs quand une seule suffit. --Szyx28 décembre 2008 à 23:43 (UTC)
C'est une bonne idée, mais c'est en effet bien lourd à écrire, et surtout à maintenir. Je pense qu'on peut utiliser ce genre de notice multilingue mais uniquement sur des modèles très généraux et qu'on ne modifie pas tous les jours. Ou on peut faire plus discret, quand c'est possible, par exemple à {{-étym-}} on peut faire une simple liste à puce du genre « * English: etymology » etc. - Dakdada(discuter)30 décembre 2008 à 16:06 (UTC)
Laisse tomber, la liste des pages concernées se réduit sans doute à celle-ci.
Notez néanmoins que Jcwf a trouvé l'idée assez intéressante pour la reproduire (en plus simple) sur la version néerlandaise de la page :nl:Sjabloon:Universele_gebruiker.
En lisant avec attention la notice d'utilisation de l'extension des références, je me suis aperçu qu'il existait une manière de grouper les références, par exemple par langue, voire pour faire des notes. Il suffit pour cela de rajouter un attribut « group="fr" » dans les ref. Pour un exemple, voir Utilisateur:Darkdadaah/Test/Références.
Cela pourrait donc remplacer avantageusement nos modèles {{réf}} et {{RÉF}} qu'on avait justement créé pour cela. Reste plus qu'à implémenter tout ça, tout en faisant en sorte de simplifier la chose, ce qui ne devrait pas être bien difficile.
Par exemple, il suffirait de rajouter un argument de langue au modèle de section {{-réf-}} pour que la liste des références dans la langue donnée y soit écrite. De même, il suffirait d'écrire des modèles {{réf:TLFi}} qui créeraient la note <ref group="fr" name="TLFi">{{R:TLFi}}</ref> automatiquement (qui permettrait de conserver l'avantage qu'on a d'utiliser des modèles).
Contre Je déteste <ref> qui en obligeant à mettre le contenu de la note dans le corps du texte rend celui-ci complètement illisible (si tu veux, je peux trouver des exemples totalement délirants sur Wikipédia, particulièrement en:). {{réf}} et {{RÉF}} me paraissent être la bonne solution. --Szyx30 décembre 2008 à 23:29 (UTC)
Certains auront remarqué que, ce 30 décembre 2008, les mots magiques CURRENTWEEK et CURRENTYEAR rapportent 1 et 2008, au lieu de 53 et 2008 ou encore 1 et 2009. Le bogue 16838 a été rapporté. Urhixidur30 décembre 2008 à 16:44 (UTC)
CURRENTYEAR donne l'année civile qui est forcément désynchonisée avec les semaines. CURRENTWEEK donne le numéro de semaine, la semaine 1 ne commençant pas forcément avec l'année civile, mais étant entière (avec 7 jours). Les deux de sont pas sensées cohabiter ensembles. Ce qui colle ensemble c'est CURRENTISOYEAR (l'année ISO commençant toujours en début de semaine ISO un lundi, éventuellement dans les 3 derniers jours de l'année civile précédente) et finissant toujours un dimanche, en fin de semaine ISO éventuellement dans les 3 premiers jours de l'année civile suivante) et CURRENTWEEK (le numéro de semaine ISO dans l'année ISO, entre 1 et 53, la semaine 1 contenant forcément le premier jeudi de l'année civile, puisque le premier lundi, mardi ou mercredi de la semaine 1 peut être dans l'année civile précédente).
Il est dondamentalement erroné de numéroter les semaines avec CURRENTWEEK et CURRENTYEAR. Et ce n'est du tout pas un bogue ! (Le bogue 16838 est erronné). Utilisez les semaines ISO (qui commencent un lundi et finisieent toujours un dimanche et sont toujours complètes avec 7 jours), ou les semaines US (commençant un dimanche et finissant toujours un samedi avec le premier mercredi de l'année dans la nouvelle année et non dans l'année précedente), et vous réglérez votre problème. Ceci n'a rien à voir avec un bogue mais avec une maucivaise compréhension des contraintes calendaires. 79.83.234.1441 janvier 2009 à 01:24 (UTC)
Mise en place des sections modifiables
Le vote sur les sections modifiables a démarré le 11 décembre, il y a plus de deux semaines, et je pense qu'on peut le clore.
Pour information, j'ai mis en place une page explicative. Les articles a et b ont déjà été modifiés en guise d'aperçu. L'automatisation commencera bientôt (d'ici demain probablement), si vous avez un bot et que vous êtes intéressés pour aider à la transition, n'hésitez pas à le faire savoir. - Dakdada(discuter)30 décembre 2008 à 22:00 (UTC)
Le siteNotice que je compte mettre (apparaitra plus petit) :
Annonce : les sections de langue sont actuellement en cours de conversion de manière à devenir modifiables indépendamment. Durant la période de transition le style des titres de sections de langue sera perturbé, sans gène cependant pour la modification des pages. Les titres redeviendront normaux après conversion de l'ensemble des pages.
(Plus d'informations)
C'est pas sympa de faire ça entre les fêtes quand pleins de gens ne sont pas chez eux, ou sont partis dans leurs familles, sans accès Internet pendant quelques temps.
Ceci dit, je ne t"en veux pas, mais la notion de "trop longtemps pour appliquer un vote ou une décision" est à adapter aux circonstances...
Il n'y avait pas d'urgence non plus, en revanche on m'a demandé de patienter bien plus longtemps pour d'autres propositions bien plus urgentes à mon avis qui concernent la mise en place de la nouvelle page d'accueil ou les métadonnées pour régler les tris des différentes langues, ou la mise en place d'une espace de nommage "Sous-page:" destiné à remplacer les pseudo-sous-pages de l'espace principal (et rempalcer aussi la Catégorie:Sous-pages tout aussi inutile), qui aurait du être là pour faire toutes les sous-pages de gestion des fusions/importations d'articles, etc. verdy_p30 décembre 2008 à 23:24 (UTC)
Verdy, tu es injuste, j'ai plus d'une fois eu envie d'officialiser ta nouvelle page d'accueil selon le même principe (que nous attendons trop longtemps avant de faire les choses), sauf que je n'ai pas eu les couilles. Alors, ne me reproche pas d'avoir eu, pour une fois, le courage de mes opinions. --Szyx31 décembre 2008 à 00:23 (UTC)
Je te comprend tout à fait Verdy_p, et j'ai quand même bien hésité avant d'agir. Plusieurs raisons m'ont poussé cependant à m'y mettre :
le vote a quand même commencé le 11 décembre, avant les fêtes ;
c'est un changement qui a déjà été maintes fois évoqué et discuté (et il y a même déjà eu 1 vote auparavant, lui aussi avec une majorité de pour, mais avec un inconvénient technique désormais réparé) ;
c'est peut-être mieux en fait de profiter des fêtes etc. pendant que les gens sont moins censés être là pour justement faire ce genre de modifications profondes ;
ce serait bien de tout changer en une fois, de sorte que le prochain dump soit complet (le dernier date du 28 décembre, il y a 3 jours : autant en profiter).
Ajouté à cela que ce sera un changement aisément réversible (à la transition de robot prêt), et ça me semble quand même suffisant pour clore le et lancé les changements. Pour ce qui est de tes propositions, elles sont très fraiches et n'ont pas toutes été pleinement discutées, sauf peut-être pour la page d'accueil (tu pourrais proposer toi aussi une décision « officielle » pour changer la page d'accueil). - Dakdada(discuter)31 décembre 2008 à 11:52 (UTC)
Je me suis permis de mettre des liens vers cette page à divers endroits, en particulier sur l'en-tête de la Wikidémie. Je pense qu'elle n'est néanmoins pas encore assez visible, mais ce n'est pas mon propos du moment.
Mon propos est : si cette page vous plait, appropriez-la-vous, c'est-à-dire faites en sorte qu'il n'y ait pas presque que moi dans l'historique.
Mon bot qui gère les trad/trad-/trad+ m'a permis de remarquer que ces modèles étaient utilisés dans la section étymologie de nombreux articles. j'ai commencé par en changer plusieurs en liens simples mais maintenant je m'interroge.
Cette interrogation prenant des aspects de plus en plus généraux, j'aimerais avoir votre avis sur l'organisation de cette section. Je vois deux problèmes pour l'instant : le nom des langues et les liens vers les mots étrangers.
Le nom des langues
Ici, on utilise souvent le nom en texte simple ou le code de la langue.
Le wiktionary anglais utilise un modèle dédié en:Template:etyl, qui ajoute des catégorisations (en:Category:Etymology). Je trouve ces catégorisations vraiment très très intéressantes. Je comprend que l'on puisse critiquer des catégorisations qui n'ajoutent pas d'information sur le mot, mais pouvoir avoir une liste de mots venant de telle ou telle langue peut être très intéressant.
Avantages et inconvénients :
Notre solution est très simple.
Cependant elle est limitée en terme d'utilisation, de catégorisation et de normalisation.
La solution du wiktionary est plus rebutante à taper, surtout pour des débutants. L'utilisation de codes est parfois problématique, surtout pour parler d'anciennes langues ou de familles de langues (là je compte sur Verdy p pour nous expliquer si c'est réellement limitant ou si on a des codes pour tout).
On a des codes pour à peu près tout ce qu'on veut. BCP 47 fournit le cadre et se met en place progressivement (déjà il est en place pour la quasi-totalité des codes simples, il se met en place aussi pour les variantes d'écritures y compris les romanisations, avec de gros avantages en terme de présentation et de support natif dans les navigateurs et la personnalisation des polices de caractères adaptées à chaque écriture).
Un code langue peut paraître rebutant, pourtant c'est la solution la plus élégante pour gérer la collaboration entre wikis et la compatibilité avec les navigateurs et les normes du web. L'aspect rebutant n'en est un que la première fois: ceux qui maîtrisent les langues concernées connaissent ces codes ou peuvent les trouver facilement, l'apprentissage des codes se fait très facilement, langue par langue. Par la suite, on évite les problèmes d'homonymies, de synonymes, d'orthographe ambigüe, de catégories en doublon, et on automatise presque tout et tout devient plus facilement cohérent. Les codes peuvent être compris par tout le monde car ils viennent d'une norme internationale d'usage universel. Cela n'empêche pas d'avoir des catégories et intutilés affichés en clair en français, mais tout le monde peut participer même sans forcément connaître le nom préférable ne français. Le choix du nom à utiliser devient un problème annexe traitable et décidable séparément sans avoir à revoir des milliers d'articles et les chercher de façon complexe. verdy_p8 janvier 2009 à 19:18 (UTC)
Par contre leur solution est plus riche. Le problème des codes me semble réel mais faire un modèle qui accepte à la fois des codes et des noms pourrait être une solution. J'ai essayé de faire cela pour ma proposition de modèle {{T}}. Si on a un code tout se passe bien. Si on ne connait pas le code ou il n'y a pas de code, on affiche le nom quand même mais on ne catégorise pas et on catégorise la page dans une catégorie de maintenance. Comme ça quelqu'un d'expérimenté peut passer une fois de temps en temps et voir quels sont les cas simples où on peut remplacer par un code et les cas plus complexes où il faut créer un code spécifique s'il y a assez d'occurence.
On a déjà des pages de discussion et outils pour gérer les cas des codes manquants, et un cadre défini pour les ajouter (je n'ai rien inventé du tout, BCP (Best Current Practive) signifie "meilleure pratique actuelle". Si quelqu'un ne connaît pas un code, ou si le code est encore ambigu, rien n'interdit d'utiliser transitoirement un pseudo-code (utilisant un nom explicite de la langue), quitte à renommer le modèle plus tard une fois le code préférable déterminé. On peut le faire facilement tant que quelqu'un ne cherche pas à inventer de toute pièce un code entrant en conflit avec ceux de la norme internationale ou ne respectant pas les règles édictées dans BCP 47 (i.e. RFC 4645, RFC 4646 et RFC 4647 pour l'instant, ces numéros de RFC évoluant avec le temps mais BCP 47 restant stable et traçant la dernière version de ces RFC, mentionnant comment on peut utiliser les codes de langue ou d'écritures et de variantes ou régions normalisés dans diverses autres normes dont les normes ISO 639, ISO 3166, et ISO 15924, ainsi que les versions des anciennes RFC rendues autrefois associées à RFC 47 et rendues obsolètes en assurant la compatibilité ascendante ). BCP 47 établit de façon claire le code préférable et non ambigu, il garantit aussi la stabilité et la compatibilité ascendante, et définit les alias nécessaires pour les autres codes supportés par compatibilité et qu'on peut supporter ici aussi en tant qu'alias avec une redirection de ces codes.
Le nettoyage et l'unification ultérieure des pseudo-codes initiaux ou alias est facile à faire par un simple robot suppresseur de redirections ou même à la main quand on en trouve, mais immédiatement les articles sont bien catégorisés et classés à tous les niveaux (voilà qui aide bien quand on doit recatégoriser une langue mieux définie ou normalisée: ces catégorisations simplifient le suivi et aident à clarifier les ambigüités détectées ou distinctions superflues quand, après discussion par des experts linguistes internationaux qui maîtrisent encore mieux les langues concernées que nous, certains codes sont fusionnés ou scindés. Appuyons-nous sur leur travail, c'est tout l'intérêt des normes internationales qui ont plus de visibilité et plus de références sérieuses que notre seul Wiktionnaire).
On aura en revanche plus de problèmes si on essaye d'utiliser des noms et non des codes standards car souvent ces noms ne sont pas uniques et sont presque toujours localisés accepter les noms reviendrait à enterriner la multiplication des modèles et synonymes, ce qui n'apporte aucun intérêt pour la lecture du Wiktionnaire comme pour sa maintenance. Est-ce vraiment si difficile de reconnaître et taper des codes langue définis de façon très claire dans une norme internationale reconnue comme "meilleure pratique courante" et déjà utilisés dans toutes les autres normes du Web (HTML, CSS, moteurs de recherche, moteurs de rendu, identification des polices de caractères, etc...) ? verdy_p8 janvier 2009 à 19:18 (UTC)
Catégoriser les mots issus d'une certaine langue existe depuis peu sur Wiktionnaire grace à une proposition d'Henri Pidoux. C'est encore très artisanal. Mais nous avions imaginer dédié un modèle pour cette catégorisation. Voir cette discussion ouverte. Stéphane8888discuter8 janvier 2009 à 20:48 (UTC)
Utilisation du modèle trad
Ma proposition pour les traductions étant sur le point d'être accepté, la catégorisation "traduction en ..." devrait être enlevée du modèle {{trad}}.
Le modèle trad pourrait alors servir pour lier des mots étrangers au milieu d'un texte en français avec tous les avantages qu'il possède déjà :
Utilisation du code langue pour indiquer en quelle langue est le texte : utile pour un meilleur affichage des langues à rendu complexe, pour l'accessibilité, pour l'indexage par les moteurs de recherche, etc.
Utilisation du code langue pour lier à la bonne section de la page dans le wiktionnaire et vers un wiktionnaire étranger s'il y a lieu
Le wiktionary se sert d'un modèle équivalent au modèle trad dans leur section étymologie : le modèle term. Je ne dis pas cela pour qu'on copie tout ce qu'ils ont fait, mais il y a déjà beaucoup de réflexion sur le sujet, autant qu'on en profite. Ce modèle fait beaucoup de choses (trop ?).
Donc voilà, j'espère lancer une discussion pour prendre un peu la température. je ne propose pas de changement radical tout de suite, il faut bien y réfléchir mais personnellement je pense que les sections étymologie du wiktionary anglais sont bien mieux faites que les nôtres. En même temps, on peut profiter de leurs bêtises pour faire encore mieux .
Je vais surement me faire casser la gu... Ah ? C'est déjà fait ? ! Ne me demandez surtout pas quels étaient mes critères. --Szyx31 décembre 2008 à 16:28 (UTC)
Vous auriez pu attendre la fin des réveillons, il y a plein de monde à l'extérieur en ce moment ! Il n'y a pas urgence. verdy_p31 décembre 2008 à 17:27 (UTC)
Euh, tu fais un peu n'importe quoi Szyx, le vote dure jusqu'au 10 janvier, et je ne vois pas où est l'absence de consensus quand personne n'est contre. Koxinga31 décembre 2008 à 18:41 (UTC)
Oui, tu as raison, je fais n'importe quoi. Disons que c'est un peu la faute à Verdy, qui m'a mis au défi. Et beaucoup de ma propre faute. --Szyx31 décembre 2008 à 18:49 (UTC)
Tiens donc ? tu donnes les questions et les conclusions, avant même que je fasse une remarque (je ne t'ai pas mis au défit avant de faire ma remarque ci-dessus, mais il semble que ce soit toi qui mette les autres au défit). Sur les traductions, la catégorisation ne gène pas pour l'instant, d'autant que les catégories correspondantes sont cachées par défaut dans les articles qui les mentionnent: la catégorisation aide à la vérification globales des traductions (pour ne pas mélanger les langues): c'est bien plus facile de voir des anomalies de classement ou de codification dans les listes des catégories, que de les chercher dans les articles, même avec un dump et un robot indexeur.
On a certainement d'autres choses plus utiles à faire. A commencer par améliorer la navigation dans les catégories, et affiner leur tri pour les rendre plus facilement utilisables (ça commence à s'améliorer, même pour les écritures "difficiles", mais on doit pouvoir aller plus loin).
Après tout un dictionnaire est avant tout une collection d'éléments triés, catégorisés, et les catégories sont faites pour ça (pas seulement pour la maintenance du contenu). Je crois que développer les articles est une partie des tâches à faire, développer les catégories et les trier correctement en est une autre. Ces deux types de navigations sont ou devraient être aussi utiles l'une que l'autre, et complémentaires : sur Commons elles sont même indispensables à cause justement de la gestion multilingue, car il n'est pas aisé de faire et maintenir de nombreuses traductions et descriptions dans plein de langues, alors que le contenu doit rester organisé pour permettre de retrouver des éléments autrements difficiles à retrouver. Dans le Wiktionnaire on a le même problème à régler car on est bien dans un contexte largement multilingue, même ici dans l'édition francophone.
2009 semble être aussi le début d'une période ou les dictionnaires d'autres langues vont être plus massivement enrichis (c'est vrai qu'on a vu une croissance du bulgare, mais la demande est visiblement très forte pour l'enrichissement de l'anglais, l'allemand, l'espagnol, le portugais, l'italien, l'arabe et le chinois, mais aussi pour nos langues régionales). On doit se souvenir que notre Wikitonnaire sert aussi de modèle pour les autres éditions, et que la collaboration multilingue devra aussi s'améliorer avec les autres Wiktionaires, même si on a fait un peu cavalier seul ici, et même si la croissance de la partie française n'est semble-t-il pas encore près de son palier de croissance.
2009 annonce de nombreux chantiers pour faciliter la maintenance, la cohérence et enrichir la navigation, qu'on ne fera pas facilement sans créer en parallèle des catégories: tout ne se fait pas avec des modèles parfois trop lourds, (ou d'énormes pages de listes compliquées à créer, éditer et maintenir de façon cohérente quand des catégories sont souvent plus simples et donnent des résultats utiles et plus immédiats et plus complets avec une maintenance minimisée. On a beaucoup investi (peut-être trop) dans les modèles, et pas assez dans l'organisation du contenu), la catégorisation est encore insuffisante, ce qui pousse certains à les supprimer quand au contraire on devrait les étoffer pour les rendre plus utiles. Alors qu'en revanche bon nombre de pages de listes pourraient être (ré)générées automatiquement à partir de catégories mieux architecturées.
Et là je pense sérieusement que c'est la partie Thésaurus qui est insuffisante, de même que les pages de grammaire, flexions, lexiques... (dans de nombreuses langues) S'il nous faut des modèles ce n'est pas forcément pour formater des pages d'articles existantes, mais surtout pour naviguer plus facilement entre elles selon de plus nombreux axes de recherche.
D'autres éléments attendus: davantage de liens vers Wikipédia, Wikisource, Wikiquotes (auteurs, publications, références, articles de fond). Tout cela semble encore vague mais des propositions concrètes vont voir le jour pour formaliser et organiser tout ça.
Ensuite il y a la présentation elle-même des articles qui demande à être révisée pour adopter une forme plus classique des disctionniares existants. Certains chois ne sont pas forcément très conviviaux, et une refonte du style plus homogène sera bientôt nécessaire. (on voit maintenant apparaitre des boîtes déroulantes là où une meilleure présentation aurait permis d'éviter cette incongruité non accessible. Peut-être faut-il plus de Javascript, mais pas au détriment de la consultation sur divers médias (téléphone mobile, lecteurs Braille, utilisation facilitée pour des enfants, ou élèves en grande difficultés, ou personnes souhaitant apprendre le francçais ou enrichir et améliorer sa connaissance, ou mieux l'utiliser tous les jours. Le but serait que le Wiktionnaire devienne un outil aussi universel et utilisable dans divers logiciels (pourquoi pas non plus dans les traitements de texte, ou dans les sites tiers pouvant l'intégrer comme des forums, ou dans les navigateurs... Cette intégration (qu'on n'a pas forcément à faire nous même mais qu'on peut favoriser en facilitant la tâche des développeurs de logiciels ou sites tiers, mais aussi en leur offrant des outils leur permettant d'utiliser le Wiktionnaire plus facilement) devrait être poussée (quand pourrons-nous produire un correcteur orthographique ou grammatical à partir des données du Wikitonnaire par exemple? Peut-on fournir des métadonnées permettant à ces outils de proposer différents liens ou données finement corrélées à ce que tapent ou recherchent les utilisateurs dans divers logiciels ou sites? Peut-on proposer aussi à ces sites ou logiciels des moyens leur permettant de mettre à jour les données du Wiktionnaire pour y contribuer directement ou le corriger le cas échéant, sans forcément avoir à connaitre la syntaxe Wiki ou utiiliser nos formulaires de modification en ligne?)
C'est un texte très intéressant mais c'est risqué de parler de trop de choses à la fois. Je vais essayer de répondre avec mes options, mais je vais sûrement laisser plein de choses de côté.
Les catégories : C'est un outil efficace et je suis pour que l'on en utilise un maximum (y compris cachées). Cependant elles ne font pas tout et ne sont pas du tout un élément central à la navigation dans le wiktionnaire. Un dictionnaire n'est pas avant tout une collection d'éléments triés. Le tri n'est là que pour permettre d'accéder aux éléments. C'est pour ça que je trouve que l'index de toutes les pages présent sur la page d'accueil n'a aucun intérêt. Si on cherche un mot, soit on sait l'écrire et on le tape (ou le copie-colle, ou utilise Wikilook), soit on a une idée de la langue et/ou du thème, et des sous-catégories vont nous aider.
Certaines listes sont difficiles à remplacer par des catégories. Il faut le creuser parce que la maintenance de grandes listes est difficile et provoque des erreurs et inconsistances, mais ce n'est pas trivial.
Quelles sont les boîtes déroulantes qui auraient pu être remplacées par une meilleure présentation ? (d'ailleurs le javascript n'est en aucun cas nécessaire pour accéder au contenu des boîtes déroulantes. S'il est désactivé, ce sont de simples tableaux HTML). Je pense aux traductions par exemple. On ne peut pas vraiment adopter une forme "proche des dictionnaires classiques". Il n'y a pas de dictionnaire classique tentant de traduire dans toutes les langues. On est donc bien obligé d'inventer quelque chose. A mon avis, cela passe à court terme par des boîtes déroulantes, par un modèle comme {{T}} qui permet de choisir quelles langues on veut afficher et cibler les informations visibles. A long terme, je vois plus le wiktionnaire devenir un générateur de dictionnaires bilingues (ou un dictionnaire des synonymes, étymologique, etc.). La page centrale deviendra trop importante pour être facilement consultable, elle sera cassée en sous-sections.
Pour l'utilisation par des sites extérieurs, je te conseille d'en parler avec Arthurwolf. Il essaie justement de parser le wiktionnaire pour en tirer des correcteurs orthographique et grammaticaux pour Abiword. Tout mon travail de détection d'erreurs et d'incohérences dans les sections, les modèles, les tableaux, vise aussi à faciliter l'utilisation des dumps du wiktionnaire par des programmes externes.
J'ai aussi plein d'idées pour améliorer Wikilook, l'extension Firefox qui permet de chercher des mots dans le wiktionnaire.
Pour modifier le wiktionnaire sans syntaxe wiki : on peut autoriser la création d'article de manière assez simple, mais corriger sans connaître la syntaxe wiki me parait impossible. On peut par exemple fournir la syntaxe d'un stub dans les langues pour proposer d'ajouter facilement un article minimaliste mais l'organisation d'un article complet est souvent trop complexe.
Par contre, ce qui peut être intéressant c'est de proposer de signaler une erreur, d'ajouter cela automatiquement à une page qui les recense (par langue, par section, par type d'erreur) et ensuite des contributeurs expérimentés ajoutent ces erreurs.
Pour la coopération entre les langues, j'aime aussi la liberté de pouvoir essayer des solutions différentes. Cela permet d'explorer plusieurs voies. Ensuite les bonnes solutions sont copiées de wiktionary en wiktionary et finissent par s'imposer. C'est une méthode qui provoque beaucoup de problèmes et de perte de temps mais qui permet à chacun d'expérimenter et donc de tester plus de possibilités.
Bon, pas le temps de me relire, j'envoie comme ça, tant pis pour la cohérence
2009, que je vous souhaite très bonne, s'annonce riche en discussions ... d'autant que de puissants contributeurs sont venus (ou revenus) étoffer le Wiktionnaire. Selon moi, les boîtes déroulantes doivent être ouvertes par défaut, au moins au début de l'expérience. Y aurait-il un moyen de paramétrer facilement son monobook via "mes préférences" afin de choisir le type d'"ouverture" de ces boîtes ? Stéphane8888discuter1 janvier 2009 à 22:55 (UTC)
(le paragraphe en gras ci-dessus répète exactement la même demande aussi en 3 lignes, que tu n'as pas lu non plus quand tu as posté ta réponse). verdy_p 8 décembre 2008 à 20:11 (UTC)
--Szyx 8 décembre 2008 à 18:22 (UTC)
! --Szyx 11 décembre 2008 à 20:34 (UTC)
--Szyx 12 décembre 2008 à 16:38 (UTC) Personne n'avait remarqué que je m'étais trompé d'un facteur 10 ! --Szyx 14 décembre 2008 à 17:48 (UTC)
, je me suis permis de faire ce petit tableau.
--Szyx 19 décembre 2008 à 21:09 (UTC)
) --Szyx 20 décembre 2008 à 10:16 (UTC)
(mais l'association avec l'image est de moi). --Szyx 24 décembre 2008 à 21:09 (UTC)
Aide en français – Help in English – Ayuda en español – Hulp in het Nederlands – Hilfe auf Deutsch – ∇
Contre Je déteste <ref> qui en obligeant à mettre le contenu de la note dans le corps du texte rend celui-ci complètement illisible (si tu veux, je peux trouver des exemples totalement délirants sur Wikipédia, particulièrement en:). 
Pour - Quels seraient les inconvénients ? --Béotien lambda 14 mars 2009 à 16:01 (UTC)
--Szyx 30 décembre 2008 à 23:09 (UTC)
