Convention:Structure des pages/Nouvelle structure des traductions

Vote clos Proposition 1 (Séparation des sens) : 9 pour, 0 contre la proposition est adoptée. Proposition 2 (Utilisation des boîtes avec javascript) : 7 pour, 1 neutre, 0 contre la proposition est adoptée. Proposition 3 (Utilisation d'un modèle T en début de ligne) : 5 pour, 2 neutre, 0 contre la proposition est adoptée. --Béotien lambda 17 janvier 2009 à 09:18 (UTC)

Vote proposé par Koxinga, qui a plein d'idées sur l'organisation des traductions et qui veut savoir ce que les autres pensent de ses propositions.

On va dire que le vote dure jusqu'au 10 janvier 2009 ...

J'ai (Koxinga bien sûr) écrit ma vision des conventions de traductions ici : Utilisateur:Koxinga/Conventions Traductions.

Il y a principalement trois nouveautés donc cette page est constituée de trois sous-votes.

Séparation des sens

Proposition

Le système de numérotation des sens "(1), (2)" après le mot n'est pas viable à long terme, se casse dès qu'on ajoute un sens, etc. Dans la pratique, on essaie de plus en plus de séparer les sens, avec des boîtes ou avec des listes séparées.

Cependant, c'est encore écrit dans l'aide qu'on peut utiliser les numéros.

Je propose de dire clairement qu'il faut séparer les sens et ajouter une petite phrase décrivant le sens devant chaque liste, pour que cela soit plus clair et plus robuste. Il faudra aussi rédiger une page expliquant comment séparer les sens, en précisant comment utiliser {{trad-trier}} et {{ttbc}}.

Discussion

pour reprendre l'exemple de chat, si le sens est - par extension - « félin », je trouve debile de reprendre toute la traduction de félin un renvoi vers la page → voir félin s'impose. --Diligent 23 décembre 2008 à 13:13 (UTC)

Bien sûr. Koxinga 23 décembre 2008 à 13:59 (UTC)

Remarque 1 : notez que ces conventions devraient aussi s'appliquer à toutes les sous-sections du genre synonymes, gentilés, etc. - Dakdada (discuter) 23 décembre 2008 à 17:58 (UTC)

Remarque 2 : il pourrait être utile de conserver des numéros, histoire de s'y retrouver plus facilement quand il y a beaucoup de sens. Mais cela sous-entend qu'on mette ces numéros à jour dès qu'on change les définitions… - Dakdada (discuter) 23 décembre 2008 à 17:58 (UTC)

Vote

•  Pour, bien sûr Koxinga 23 décembre 2008 à 13:59 (UTC)
•  Pour à 100%. Je m'efforce de le faire systématiquement pour les pages que je crée. Diligent
•  Pour --Szyx 23 décembre 2008 à 14:08 (UTC)
•  Pour : Même si la coexistence des n° offrait une solution rapide. Stéphane8888 discuter 23 décembre 2008 à 16:12 (UTC)
•  Pour: En nl. on le fait depuis longtemps. On le fait meme double: Les boxes contiennent et une description et le n°. Jcwf 23 décembre 2008 à 17:03 (UTC)
•  Pour : devrait être systématique, et pas seulement dans les sections de traductions (cf synonymes, etc.). Un numéro en plus serait peut-être utile quand même… - Dakdada (discuter) 23 décembre 2008 à 17:55 (UTC)
•  Pour : Serpicozaure(discuter) 23 décembre 2008 à 20:15 (UTC)
•  Pour VIGNERON * ^discut. 24 décembre 2008 à 09:32 (UTC)
•  Pour Cela conforte l'usage actuel LBO disc 27 décembre 2008 à 13:22 (UTC)

Utilisation des boîtes (avec javascript)

Proposition

La séparation des sens peut se faire avec plusieurs listes à la suite. On utilise de plus en plus les tableaux pour avoir plusieurs colonnes, mais même ces tableaux deviennent parfois très grands. Le cas où plusieurs sens d'un mot ont chacun une centaine de traductions va finir par arriver. La page deviendra alors complètement illisible.

Je pense que les boîtes sont une bonne solution à ce problème mais qu'elles ne sont pas parfaites à l'heure actuelle. C'est très frustrant de cliquer sur une boîte pour l'ouvrir alors qu'elle était vide. J'ai donc modifié la fonction du monobook.js pour qu'elle affiche huit lignes (le nombre est paramétrable). La boîte affiche toujours huit lignes et s'il y en a plus, offre un lien permettant de l'ouvrir en entier. Voici par exemple ce que je vois sur la page chat. Le code est ici et je vous invite à l'essayer, il suffit de le copier dans votre monobook.js. Je suis ouvert à toute suggestion ou retour de bug.

Ma proposition est d'ajouter cette fonctionnalité (une fois le code nettoyé et l'apparence améliorée) dans le monobook.js par défaut et d'inscrire dans l'aide que les boîtes sont la façon conseillée pour représenter les différents sens des traductions.

Même si c'est refusé, cela sera mieux que le flou artistique qui entoure ces boîtes en ce moment, entre la page d'aide du modèle qui dit de ne pas s'en servir et les contributeurs qui l'ajoutent tout de même.

Discussion

• l'organisation des colonnes est dysharmonieuse : dans chat, traduction de Chat domestique, la 3e colonne est totalement ecrasee. A part cela, je suis favorable a cette solution deja adoptee par le wiktionary. --Diligent 23 décembre 2008 à 13:09 (UTC)

Est-ce que tu as essayé mon code Utilisateur:Koxinga/monobook.js ? Pour l'instant le modèle indique aux colonnes de prendre 50% de la place, donc les deux premières s'installent et écrasent la troisième qui n'a aucune place en théorie. Mon code compte les colonnes et leur dit de prendre une part égale de place. Ce n'est pas parfait mais c'est beaucoup mieux. Koxinga 23 décembre 2008 à 13:59 (UTC)

• Il ne faut pas oublier le résultat lorsqu'on imprime. Je n'ai pas encore fait de test avec ta modification, mais d'une manière générale je trouve la version imprimée des pages "immonde". Pourtant, un dictionnaire est fait pour être sur papier, non ? --Szyx 23 décembre 2008 à 14:17 (UTC)

Je ne saurais trop vous conseiller de relire la longue litanie des discussions qui traitent des boîtes déroulantes. Il faudrait trancher définitivement et graver la décision dans le marbre avant que Utilisateur X ou Utilisateur Y ne vienne encore tout modifier avec sa façon de voir les choses. On participe en jouant dans les sables mouvants et plus on bouge plus on s'enfonce. Ugh !

C'est pourquoi je vote oui pour en finir, en me mettant la tête dans le sable...mouvant. -Béotien lambda 23 décembre 2008 à 14:48 (UTC)

La vision des sables mouvants est un peu pessimiste . j'ai bien lu toutes ces discussions et j'ai essayé d'apporter une solution technique nouvelle, pour voir si cela surmontait les réticences. Reprenez cet exemple de Stéphane8888 avec mon code, je trouve vraiment la solution avec les boîtes plus agréable et homogène. Koxinga 23 décembre 2008 à 15:03 (UTC)

Oui, j'ai revu cet exemple et la boîte prend moins de place que la solution traditionnelle, tout en affichant tout. Je suis convaincu. Stéphane8888 discuter 23 décembre 2008 à 16:55 (UTC)

• Il faudra penser à mettre à jour les patrons d'articles. --Szyx 24 décembre 2008 à 09:02 (UTC)

Vote

•  Pour, bien sûr Koxinga 23 décembre 2008 à 13:59 (UTC)
•  Pour, mais je ne vote pas pour la proposition 1, qui est comprise dans 2, (c'est ce que je voulais dire) -Béotien lambda 23 décembre 2008 à 14:33 (UTC)
•  Pour esthétique (j'ai tenté de suivre le coté technique de la longue litanie en question, sans succes) je trouve - comme Beotien Lambda - que la conjonction 1 traduction par sens + boite est jointe + claire ; esthetique ; pratique. --Diligent 23 décembre 2008 à 15:11 (UTC)
•  Pour : J'ai même rajouté un {{boîte milieu}} dans chat, hihi. Il faudrait qu'on offre les codes monobook qui vont bien pour les divers choix (boites fermées, boites ouvertes, à tant de lignes). Ou idéalement via un choix dans les mes préférences... La syntaxe "boîte début" est un peu lourde à saisir... mais elle est claire, c'est le principal, au moins dans un premier temps. Stéphane8888 discuter 23 décembre 2008 à 17:45 (UTC)
•  Pour : Serpicozaure(discuter) 23 décembre 2008 à 20:15 (UTC)
•  Pour : Mais je préfèrerais qu'on utilise un modèle spécifique aux traductions pour pouvoir le faire évoluer plus simplement dans l'avenir. --Szyx 24 décembre 2008 à 08:41 (UTC)
•  Neutre (limite  Contre), les boîtes déroulantes consomment pas mal de ressources (sur mon vieil ordi, la page peut mettre quelques secondes de plus à s’afficher) pour au final pas grand chose (sur Internet on a toute la place que l’on veut). De plus, enrouler les traductions, plutôt qu’un autre élément (la définition par exemple) créer un biais en supposant que les traductions sont moins importantes (que la définition). Cdlt, VIGNERON * ^discut. 24 décembre 2008 à 09:36 (UTC)
•  Pour Même si je peste sur la longueur du modèle. LBO disc 27 décembre 2008 à 13:25 (UTC)

Utilisation d'un modèle T en début de ligne

Proposition

Mon idée sur ce modèle {{T}} a provoqué une grande discussion sur la wikidémie, mais c'est finalement très simple et pas lourd du tout en terme de changement.

Au lieu d'écrire des lignes comme :

• * {{en}} : {{trad+|en|snow}}

je propose que l'on écrive :

• * {{T|en}} : {{trad+|en|snow}}

Pendant la transition (faite par mon bot qui gère les traductions), le modèle T ne fait qu'afficher le nom de la langue. Une fois qu'il est installé, il peut faire la catégorisation, que l'on peut alors enlever du modèle {{trad}}, ce qui permet de ne pas forcer l'utilisation de ce modèle à chaque fois et de ne s'en servir que lorsque le mot est réellement la traduction du mot vedette.

Le modèle T peut aussi indiquer des renseignements supplémentaires, par exemple écrire (langue à préciser) à la suite des macrolangues. Il peut aussi prendre un argument pour les langues n'ayant pas de code ({{T|anglais}}, et catégoriser les pages ayant ce genre de problèmes pour que l'on puisse trouver une solution ensuite. En ce moment, je me rend compte grâce aux logs de mon bot qu'il y a beaucoup de contributions qui concernent des langues sans codes, des dialectes, etc. et c'est difficile de garder le fil (voir par exemple Utilisateur:Koxinga/langues inconnues). Je pense que ce modèle peut être un outil nous permettant de mieux gérer les cas difficiles.

S'il est bien installé et que les entrées sont très homogènes, il peut aussi indiquer par des spans où se situent les traductions en chaque langue. Cela devient alors possible par javascript de n'afficher que les langues qui nous intéressent. C'est une idée à plus long terme, mais c'est pour montrer que cette approche est plus logique et plus puissante.

Je propose donc de conseiller l'emploi de ce modèle dans l'aide et de l'ajouter avec mon bot qui parcourt les traductions. Cela change les habitudes des contributeurs déjà présents mais ne complique pas réellement l'édition pour les nouveaux arrivants. Ce qui est complexe au début, c'est l'utilisation des codes, l'ajout de "{{T|" se fera par imitation avec les autres lignes.

Vote

•  Pour, bien sûr Koxinga 23 décembre 2008 à 13:59 (UTC)
•  Pour : Que des avantages. La très légère complication du code est largement compensée par l'allègement (à terme) de {{trad}}. Stéphane8888 discuter 23 décembre 2008 à 17:10 (UTC)
•  Pour Diligent 23 décembre 2008 à 17:14 (UTC)
•  Pour : Serpicozaure(discuter) 23 décembre 2008 à 20:16 (UTC)
•  Pour - Béotien lambda 24 décembre 2008 à 07:27 (UTC)
•  Neutre, nom et utilisation peu explicite. VIGNERON * ^discut. 24 décembre 2008 à 09:37 (UTC)
•  Neutre. J’avoue ne pas avoir compris l'intérêt. LBO disc 27 décembre 2008 à 13:27 (UTC)

Commentaires globaux

Désolé d'être aussi long. Cela représente les trois principaux changements que je veux instaurer dans Koxinga/Conventions Traductions, mais si vous avez d'autres commentaires, cela m'intéresse aussi.

Changements incompatibles ?

Si j'ai bien compris ces "trois principaux changements" ne peuvent pas "être instaurés" en même temps...

On a :

ou  : Séparation des sens + Utilisation d'un modèle T en début de ligne

ou : Utilisation des boîtes (avec javascript) + Utilisation d'un modèle T en début de ligne

non ? Excuse ma béotienneté.

-Béotien lambda 23 décembre 2008 à 12:45 (UTC)

Non non, bien sûr que je veux faire les trois à la fois :

On a :

• Pour chaque sens une boîte, avec un résumé du sens en titre de la boîte. C'est déjà fait sur quelques pages, par exemple chat, mais je veux l'inscrire dans l'aide.
• Dans les boîtes, pour chaque ligne un modèle T

Les deux n'ont pas tellement de rapport et c'est pour ça que je propose des votes distincts.

Redis-moi si ce n'est pas clair, peut-être que je m'exprime mal ...

Koxinga 23 décembre 2008 à 12:57 (UTC)

Non, je suis obtus. Voilà comment je comprends les 3 propositions appliquées ensemble :

balise
Traductions

Informatique

Informatique

• englais  : tag (en)

Marine

Marine

• anglais : beacon (en)

-Béotien lambda 23 décembre 2008 à 13:32 (UTC)

C'est à peu près cela. Voilà ma vision des choses, par exemple pour cette version simplifiée de balise :

Informatique

• anglais : tag (en)

Marine

• anglais : beacon (en)

On n'utilisera pas {{boite déroulante}} pour les traductions, il y a trop de contenu. Mettre ";Marine" ne sert à rien puisque c'est déjà écrit dans le titre de la boîte. Sinon on est d'accord et je ne vois pas le problème. On a bien séparé les sens, utilisé des boîtes et utilisé le modèle T. Koxinga 23 décembre 2008 à 13:46 (UTC)

Merci pour ces précisions. En fait tu es pour 2 principaux changements et non 3 ( puisque le 1 est dans le 2 , non ?) -Béotien lambda 23 décembre 2008 à 14:30 (UTC)

Oui, c'est vrai que le 2 implique le 1. J'ai séparé quand même les votes car je voudrais valider la séparation des sens même si les boîtes sont refusées. Koxinga 23 décembre 2008 à 14:39 (UTC)

Intérêt du modèle T

J'ai tente tres fort de comprendre l'avantage de { { T|en } } par rapport a { { en } } mais cela ne m'a pas saute aux yeux. hmmm... --Diligent 23 décembre 2008 à 13:19 (UTC)

J'ai essayé de l'expliquer sur la section de vote, mais je vais tenter d'être plus clair :

• Situation actuelle :
  • On met {{en}} en début de ligne, qui affiche "anglais", et c'est tout.
  • La catégorisation se fait dans {{trad}}, ce qui pose des problèmes :
    • {{trad}} n'est pas toujours adapté, notamment lorsqu'il n'y a pas de traduction exacte
    • {{trad}} est parfois employé en dehors des sections de traduction, ce qui rend la catégorisation inexacte (voir par exemple дом)
• Situation future :
  • on remplace {{en}} par {{T|en}} et on fait la catégorisation des traductions dans le modèle {{T}}. Comme il y a forcément un modèle T pour chaque langue, et qu'on n'a aucune raison de l'utiliser ailleurs (ce qui peut facilement être vérifié par mon bot), la catégorisation est plus précise.
  • Cela permet de n'employer le modèle trad que lorsque c'est adapté, parfois il vaut mieux ne pas le mettre.
  • Le modèle T permet aussi de traiter les langues n'ayant pas de code. J'en ai recensé pas mal ici. Actuellement, elles sont juste écrites simplement, souvent même sans lien. Il n'y a donc pas de moyen simple de les retrouver. Si on les a comme argument du modèlè T, c'est plus facile de les gérer avant de trouver une solution convenable.
  • Cela délimite mieux les différentes traductions, avec par exemple la possibilité à l'avenir de proposer quelles langues veut l'utilisateur. C'est aussi plus facile pour mon bot de vérifier que tout se passe bien.

Koxinga 23 décembre 2008 à 13:51 (UTC)

J'ajouterais que l'on pourra aussi « marquer » les lignes de traductions selon les langues, ce qui pourrait être exploité par un script (ou une simple feuille de style, mais ce n'est pas sûr) pour n'afficher, au choix de l'utilisateur, que certaines de ces langues (faisable via des gadgets). - Dakdada (discuter) 23 décembre 2008 à 17:53 (UTC)

Explications sur le modèle T

J'ai codé une première version du modèle T et essayé de l'expliquer sur la page d'aide : Modèle:T/Aide.

Est-ce que c'est plus clair ?

En résumé : rien de révolutionnaire mais une meilleure gestion des langues sans codes, un remplacement de {{ttbc}} et plus de possibilités d'amélioration pour l'avenir. Koxinga 28 décembre 2008 à 17:59 (UTC)

L'Après vote

La propagation automatique de ces changements est-elle prévue ? Est-elle faisable ? Stephane8888 Discuter 1 mars 2009 à 21:50 (UTC)

Mon bot ajoute déjà les modèles T quand il passe sur une page. Son rôle premier est de remplacer les modèle trad et ttbc, il ne passe que sur les pages contenant ces modèles pour l'instant.

Pour les autres propositions de séparation des sens, c'est très difficile automatiquement car il faut écrire un résumé de chaque définition en quelques mots pour décrire chaque sens. On peut quand même essayer de simplifier la tâche par une première analyse automatique. On peut par exemple sortir une liste des articles ayant plusieurs sens et une section traduction sans précisions, pour voir où il faut travailler. Cependant je n'ai pas vraiment de temps à consacrer au wiktionnaire en ce moment mais c'est en projet. Koxinga 1 mars 2009 à 23:53 (UTC)

Je me suis finalement motivé. Avec un premier tri très simple, j'ai l'impression que l'on a fait 241 pages et qu'il en reste 33 000. Je vais faire des petites listes en commençant par les plus anciennes, qui sont souvent les plus fournies. Koxinga 2 mars 2009 à 22:47 (UTC)