Bonjour, vous êtes venu ici pour chercher la signification du mot
Wiktionnaire:Gestion des modèles/Sections modifiables. Dans DICTIOUS, vous trouverez non seulement toutes les significations du dictionnaire pour le mot
Wiktionnaire:Gestion des modèles/Sections modifiables, mais vous apprendrez également son étymologie, ses caractéristiques et comment dire
Wiktionnaire:Gestion des modèles/Sections modifiables au singulier et au pluriel. Tout ce que vous devez savoir sur le mot
Wiktionnaire:Gestion des modèles/Sections modifiables est ici. La définition du mot
Wiktionnaire:Gestion des modèles/Sections modifiables vous aidera à être plus précis et correct lorsque vous parlerez ou écrirez vos textes. Connaître la définition de
Wiktionnaire:Gestion des modèles/Sections modifiables, ainsi que celles d'autres mots, enrichit votre vocabulaire et vous fournit des ressources linguistiques plus nombreuses et de meilleure qualité.
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.
La solution serait, tout simplement, de changer les modèles de sections :
Actuellement
|
Proposé
|
{{=fr=}}
{{-étym-}}
...
|
== {{=fr=}} ==
{{-étym-}}
...
|
Il faut pour que ça marche que l'on enlève le "noeditsection" du modèle {{=langue=}}
. Une fois fait, si on rajoute dès maintenant des == on devrait pouvoir directement modifier les sections.
Inconvénients :
- l'écriture peut paraitre plus lourde. Mais ça ne me parait pas un point vraiment gênant (par exemple on peut dire qu'il sera plus facile de distinguer les sections) ;
- durant la transition où un bot (ou plusieurs, ce serait mieux) changeront tous les articles, les cadres paraitront cassés (mais tout à fait fonctionnels), voir la page Utilisateur:Darkdadaah/Test:Sections pour l'aspect des sections (avec le lien modifier). À terme, les cadres redeviendront normaux mais modifiables.
Je pense franchement que ça vaudrait le coup. Qu'en pensez-vous ? NB : il faudra que l'on vote proprement, puisque ce serait un gros changement. - Dakdada (discuter) 11 décembre 2008 à 15:54 (UTC)
- Je suis pour, mais oui « il faut qu'on vote proprement ». --Szyx 11 décembre 2008 à 19:46 (UTC)
- J'ajoute que cela aura un avantage important à mes yeux : mettre automatiquement dans le résumé de modification la langue concernée. --Szyx 12 décembre 2008 à 12:47 (UTC)
« Il faut pour que ça marche que l'on enlève le "noeditsection" du modèle {{=langue=}}
. »
- Note l'effet de bord de ta solution : si on enlève
__NOEDITSECTION__
, cela activera l'édition pour les sous-sections grammaticales (donc cela éditera leurs modèles et pas la sous-section affichée). Il y a une solution à ça : ne pas générer du tout de balise h3 dans {{-déf-}}
et prendre en charge la présentation du titre.
- Effet de bord cependant : la sous-section générée par -déf- disparaitra alors du sommaire. Si on veut le conserver aussi dans le sommaire, on se retrouve alors à adopter la même solution pour
{{-déf-}}
: il faudra encadrer alors {{-étym-}}
, {{-nom-}}
, etc., par des ===, et remplacer h3 par span dans {{-déf-}}
...
- Quel dommage que MediaWiki ne permette toujours pas d'insérer des options de style ou de génération dans les balises ==...== ; il aurait suffit d'avoir :
==|attribut1="valeur1" attribut2="valeur2"...| titre de section ==
- ou l'équivalent aussi facilement utilisable dans nos modèles :
<h2 attribut1="valeur1" attribut2="valeur2"...>titre de section</h2>
- pour désactiver sélectivement l'édition ou l'inclusion dans le sommaire, ou pour lui ajouter un style...) ; cela aurait évité complètement cette syntaxe très lourde en conservant les noms de modèles existants ! Pour les options Wikis, il aurait suffit d'avoir des attributs nommés spécifiquement pour MédiaWiki dans son "namespace XML" (par exemple
<h2 mw:edit-section="no" mw:in-toc="no" mw:section-id="III">
). Peut-on demander à rajouter ces attributs privés dans MediaWiki et le forcer à les reconnaître, pour activer/désactiver les edits de sections, ou activer/désactiver l'inclusion dans le sommaire, ou changer la numérotation de la section dans le sommaire et avant le titre de section si les numéros sont affichés (une possibilité qui manque aussi à Wikibooks et Wikisource pour respecter la numérotation originale des chapitres) au lieu de se contenter encore de __NOEDITSECTION__
et __NOTOC__
? verdy_p 13 décembre 2008 à 08:41 (UTC)
- Tu te compliques la vie : il suffit de cacher les editsection des titres de niveaux supérieurs à 2 via la feuille de style CSS. Idem pour cacher les niveaux dans le sommaire (mais c'est hors-sujet ici). Il n' a donc pas de problème de ce côté-là. - Dakdada (discuter) 13 décembre 2008 à 16:39 (UTC)
« Une fois fait, si on rajoute dès maintenant des == on devrait pouvoir directement modifier les sections. »
- Un million et demi de pages à modifier par Bot.... Une paille qui prendra plusieurs semaines si on ne veut pas surcharger le serveur, et qui rendra les articles partiellement inutilisables pendant ce temps en fonction de ceux qui ont la nouvelle syntaxe et ceux qui ne l'ont pas encore. Est-ce que ça vaut le coup et est-ce péreine comme solution? Ne vaut-il pas mieux demander aux développeurs de MediaWiki de prendre en compte des extensions à la syntaxe (comme la reconnaissance des attributs "mw:" que je propose ci-dessus qui éviterait d'avoir à alourdir la syntaxe des articles puisque ces attributs seraient "planqués" dans nos modèles existants) ? verdy_p 13 décembre 2008 à 09:03 (UTC)
- Voir le deuxième point ci-dessous, ainsi que la réponse de Koxinga. - Dakdada (discuter) 13 décembre 2008 à 16:39 (UTC)
« Inconvénients :
- l'écriture peut paraitre plus lourde. Mais ça ne me parait pas un point vraiment gênant (par exemple on peut dire qu'il sera plus facile de distinguer les sections) ;
- durant la transition où un bot (ou plusieurs, ce serait mieux) changeront tous les articles, les cadres paraitront cassés (mais tout à fait fonctionnels), voir la page Utilisateur:Darkdadaah/Test:Sections pour l'aspect des sections (avec le lien modifier). À terme, les cadres redeviendront normaux mais modifiables. »
- Les "cadres" fonctionnent à condition que ton modèle =langue= n'inclue pas la balise h2 qui est déjà générée par ==...== (sinon cela a pour effet de vouloir mettre un h2 dans un h2, et Mediawiki coupe le premier pour insérer le second à la suite (et non dedans) lors de la génération HTML finale.
- Tu noteras donc que j'ai changé la balise h2 de ton modèle par un simple span et ça marche aussitôt ! verdy_p 13 décembre 2008 à 08:29 (UTC)
- Mais par contre, cela affiche tous les titres de sections qui n'ont pas encore été modifié comme un simple texte, ce qui ne me semble pas acceptable, je préfère la solution de cadres cassés de DarkDadaah. Koxinga 13 décembre 2008 à 10:36 (UTC)
« Je pense franchement que ça vaudrait le coup. Qu'en pensez-vous ? NB : il faudra que l'on vote proprement, puisque ce serait un gros changement. - Dakdada (discuter) 11 décembre 2008 à 15:54 (UTC) »
- Raison de plus pour tenter d'abord une médiation technique avec les développeurs de MediaWiki, quitte à ce qu'ils ne le propose au départ que comme une extension utilisée seulement ici et pas par défaut sur tous les autres Wikis. verdy_p 13 décembre 2008 à 09:08 (UTC)
- Ceci est une modification que l'on voulait faire depuis très longtemps et qui nous semble importante. Ce n'est certes pas la meilleure qui soit dans l'absolu, mais elle est rapide, réversible et ne nécessite pas de refondre complètement toute la structure des articles. On ne va pas attendre encore 5 ans qu'un développeur daigne développer une extension avant d'activer la modification des sections de langue. - Dakdada (discuter) 13 décembre 2008 à 16:39 (UTC)
- Tu as vu que j'ai modifié ta démonstration pour faire fonctionner l'affichage du titre ? As-tu vu aussi le problème des sections de niveau 3 (étypologie, nom, adjectif, etc.) qui deviendraient éditables (dans leur modèle et non dans la page) si on n'y prète pas attention ? verdy_p 13 décembre 2008 à 16:53 (UTC)
- Pour l'affichage du titre, c'est un faux problème : si je laisse le h2 c'est justement pour que les sections soient conservées lors de la transition (dans le sommaire notamment), et cela permet en plus de modifier tout de suite les sections (le seul problème, temporaire, est le cassage du style de la barre). Remplacer le h2 par un span est justement ce que l'on fera quand toutes les sections auront été modifiées. Pour la modification des autres sections, je t'invite à relire ma réponse plus haut. - Dakdada (discuter) 13 décembre 2008 à 17:26 (UTC)
- Si tu envisages effectivement de garder h2 temporairement pour la transition, il faudra, si vous commencez la transition, éliminer aussi temporairement le cadre affiché au dessus dans la feuille de style CSS pour h2, car il sera très génant. J'ai d'ailleurs du mal à comprendre pourquoi on n'a pas DEUX cadres l'un sous-autre quand h2 est dans ton modèle. As-tu bidouillé la feuille de style CSS générale pour que le deuxième h2 généré n'ait pas de cadre, alors ue le premier h2 généré par le début de ==...== conserve un cadre (mais sans contenu ?
- C'est le problème de cadre cassé que j'évoquais, et qui me semble dû au fait qu'on incruste deux balises h2 l'une dans l'autre. Je n'ai pas modifié de feuille de style, l'affichage des cadres cassé est un artéfact. La seule solution, pendant cette phase de transition. - Dakdada (discuter) 14 décembre 2008 à 17:25 (UTC)
- Je note aussi que ta page d'exemple utilise un div initial de classe "ns-0": c'est sensé faire quoi ? Envisages-tu aussi d'insérer ce dic initial en tête de toutes les pages ? verdy_p 14 décembre 2008 à 16:13 (UTC)
- J'ai rajouté ce ns-0 pour simuler une page d'article, de l'espace de nommage principal (par exemple le style des cadres des langues est défini par « .ns-0 h2 ». - Dakdada (discuter) 14 décembre 2008 à 17:25 (UTC)
- Pour : j'étais déjà pour il y a un an, en ce qui concerne les seules sections de langues : Darkdada l'a rendu possible ! Stéphane8888 discuter 11 décembre 2008 à 21:20 (UTC)
- Pour : On peut vivre sans, mais sur les pages longues ce sera un plus. --Szyx 11 décembre 2008 à 21:42 (UTC)
- Pour : Cela ne me semble pas absolument fondamental pour l'instant, mais ça l'est déjà pour certains, et ça le deviendra de plus en plus quand les pages grossiront, alors je suis pour le principe. Mais ça risque de faire encore plus peur à ceux qui veulent contribuer pour la première fois. Le Wiktionary, qui utilise pourtant beaucoup les modèles (de plus en plus, et autant que nous maintenant, j'ai l'impression) n'a pas de modèles pour ce cas, ce qui rend la page interne plus facile à lire. Il faudrait voir ce qu'on peut faire pour que ça apparaisse plus simple, même avec un modèle (les = de =fr= deviennent gênants). Lmaltier 11 décembre 2008 à 21:48 (UTC)
- Pour : Pas fondamental pour les utilisateurs chevronnés (quoique pratique, par exemple pour avoir plus d'informations dans les modifications récentes). Cela contribuera surtout à rendre le Wiktionnaire plus accessible aux visiteurs occasionnels. Koxinga 12 décembre 2008 à 09:05 (UTC)
- Pour Serpicozaure(discuter) 12 décembre 2008 à 19:00 (UTC)
- Contre Lire mes commentaires ci-dessus. Noter les effets de bords que cette proposition a oublié de considérer. Le problème technique ayant justifié le noeditsection existe encore au délà des seules sections de langues. verdy_p 13 décembre 2008 à 08:57 (UTC)
- En fait je suis pour rendre les sections de langues éditables, mais pas de cette façon ; je préférerais une solution technique permettant de lever réellement la contrainte actuelle, et de pouvoir plus librement étiqueter les sections effectives dans la page (MediaWiki devrait être capable de repérer et découper les sections autrement qu'avec les seuls ==...== ou h1..h6).
- Noter qu'on peut aussi faire autrement en mettant les sections de langues dans des sous-pages éditables séparément, la page principale ne contenant alors plus aucune définition mais seulement une liste de sous-pages incluses par un modèle ad hoc générant le titre et le lien de modification. L'intérêt est aussi de faciliter les imports d'autres langues sans toucher aux sous-pages "/fr" contenant les sections françaises. Seul problème : l'espace principal ne gère pas directement les sous-pages, ce qui multipliera le nombre d'articles au moins par deux (ou plus s'il y a d'autres langues pour le même mot : une page supplémentaire par langue), sauf si on place ces sous-pages dans un autre espace. Mais alors l'espace principal n'aura plus d'articles contenant du texte (seulement une liste triviale de modèles nommés par code langue), puisque tout sera en fait dans cet autre espace de noms (y compris alors la sous-page éventuelle pour "/voir" ). verdy_p 13 décembre 2008 à 09:16 (UTC)
- Je ne pense pas que l'un empêche l'autre ... Tu as un développeur pour ton extension ? Une idée des échéances ? Cela me paraît plein de très bonnes idées, je suis pour une division des articles par langue, des sous-pages de méta-données, etc. Tout ça est encore très hypothétique et va se passer à très long terme et je ne pense pas que l'on doive arrêter toute modification de structure d'ici là. La solution proposée, moins séduisante, améliore la situation et quelques jours ou semaines de bazar valent le coup. Koxinga 13 décembre 2008 à 10:36 (UTC)
- Pour : Certaines pages deviennent difficiles à modifier. En l’absence de solution technique existante, cette solution me parait être la moins mauvaise. Quant à la désorganisation qui en résultera, comme il y a quasiment un bot par utilisateur actif, cela pourrait aller très vite en fait si le travail est réparti. De plus, rien n'empêche de modifier la page d'accueil temporairement pour signaler le travail en cours et de commencer la modification par les pages d’aide. LBO disc 27 décembre 2008 à 13:16 (UTC)
Le vote a commencé le 11 décembre, et on est au delà de 2 semaines après. Il y a 6 votes pour et 1 contre. Ça ne fait pas énorme, mais aucun véritable inconvénient technique n'a été soulevé qui auraient pu compromettre la mise en place de ces sections modifiables : c'est pourquoi je vais commencer à m'y mettre rapidement (d'autant que le dernier dump n'est sorti qu'il y a deux jours, ça nous laisse du temps d'ici là). - Dakdada (discuter) 30 décembre 2008 à 19:17 (UTC)
Voici les étapes des modifications :
- Adaptation des modèles de langue pour les rendre modifiables dès le début de la phase de transition, malgré un cadre cassé. Cela signifie qu'il suffit de rajouter les signes == de part et d'autre des sections de langue pour pouvoir les modifier directement ;
- Information des contributeurs : annonce par le Sitenotice (qu'on peut cacher dans les préférences), avec un lien vers une page d'explication, Annonces ;
- Changement de tous les modèles de langues de tous les articles par bot ;
- Ajustement des modèles de langue définitivement (réparation du cadre cassé en enlevant le h2 du modèle).
J'ai commencé à tester sur un wiki local, je commencerais d'ici peu. - Dakdada (discuter) 30 décembre 2008 à 19:17 (UTC)
Sous-pages, "/voir", clés de tri multiples par langue et métadonnées "/:data"
- Concernant les sous-pages relatives aux articles de l'espace principal, rien n'empêche de mettre en place dès maintenant cet espace de nom "Sous-page:" supplémentaire (à créer parmi les espace de nom privés libres, dont le numéro est supérieur à 100). On y transférera déjà les pseudo-sous-pages "/voir" existantes (qui n'ont rien à faire non plus parmi les modèles car directement liées par nom aux articles de l'espace principal) pour nettoyer la catégorie:Sous-pages" où ces pseudo-sous-pages n'ont rien à faire non plus car ce ne sont pas des sous-pages).
- Mais effectivement les métadonnées (qui fonctionnent déjà) seraient mieux stockées dans cet espace plutôt que l'espace principal (je n'en ai pas fait l'usage pour l'instant pour les entrées de l'espace principal, hormi une page ou deux à titre d'essai et de démonstration, on les retrouve facilement par la catégorie:Métadonnées qui contient les pages d'essai. Dès que c'est fait on aura un super-outil pour faire le suivi technique des pages, et je suis déjà prêt à lancer la génération des clés de tri spécifique pour les catégories en espéranto, coréen et chinois.
- La question que je me suis posé était : devrait-on avoir des pages de métadonnées séparées pour chaque langue? Je ne pense pas car le besoin ne se justifie pas : une convention de nommage des "variables" de métadonnées suffit, et ces varaibles seront assez peu nombreuses, surtout au début, souvent même un seule pour les mots espéranto, une pour les mots en coréen, trois ou quatre pour les mots en chinois...). Et même pour le suivi technique ou de qualité des pages, cela ne se fera probablement pas langue par langue au sein de chaque page de mot, mais pour la page entière (peut-être que je me trompe, mais je ne vois pas encore la nécessité de scinder les métadonnées d'une page en plusieurs sous-pages.
- J'ai utilisé le nom "/:data" pour les métadonnées pour éviter tout risque futur de collision, également car cela rappelle leur rôle de "métadonnées" et je ne voulais pas non utiliser "méta" pour éviter la confusion avec Wikimedia "Meta". Effectivement "data" n'est pas français, mais ce n'est pas génant pour des métadonnées qui ne sont pas destinées à être affichées directement dans l'article mais utilisées pour la cuisine interne de nos modèles utilitaires (ou pour des projets de gestion de qualité des contenus. et effectivement leur contenu n'est pas du texte mais des données de type "variable=valeur", assimilable à des colonnes de données au sein d'une même rangée de table de données (donc pas besoin d'insister sur "méta", le ":" suffit pour le rappeler implicitement). J'aurais pu utiliser "/:données" mais c'est plus long à taper et le nom de cette sous-page n'apparaîtra jamais nulle part dans aucun article disposant de ces métadonnées, pas même dans son code source Wiki. verdy_p 13 décembre 2008 à 16:51 (UTC)
- Tes propositions sont très intéressantes, mais il va nous falloir un bon moment de réflexion avant de tomber d'accord sur les changements à effectuer : donne nous un peu de temps. - Dakdada (discuter) 13 décembre 2008 à 17:30 (UTC)
- Note: le modèle
{{-déf/2}}
est une modification (un fork) de {{-déf-}}
corrigeant le bogue pour les conventions internationales, qui ne sont plus une exception à gérer parmi les autres langues, et sont nommées "catégorie:conventions internationales et non catégorie:Conventions internationales (et prenant déjà en charge la recherche de clé de tri spécifiques par langue stockées dans les métadonnées lors de la sous-catégorisation des définitions par langue). Le modèle {{nom-pr}}
utilise déjà {{-déf-/2}}
au lieu du {{-déf-}}
actuel qui est protégé. Il serait souhaitable que quelqu'un mette à jour {{-déf-}}
avec le code dans {{-déf-/2}}
, afin de pouvoir vider la catégorie en doublon des conventions internationales, puis remplacer à nouveau -déf-/2 par -déf- aux deux endroits que j'ai testés.
- Avant d'utiliser -déf-/2, j'ai évidemement d'abord fait un essai à moins grande échelle sur les verbes auxiliaires, je suis passé aux noms propres pour voir ce que cela donnait à une échelle plus grande. Tout fonctionne normalement (sauf les conventions internationales qui car certains articles utilisent encore -déf- qui gère encore l'ancienne exception des conventions internationales et remplit encore la catégorie en doublon). verdy_p 13 décembre 2008 à 16:51 (UTC)
- À voir dans la page de discussion concernée (j'irai). - Dakdada (discuter) 30 décembre 2008 à 19:08 (UTC)