Wikipédia:Questions techniques/semaine 10 2024

Une réponse a été apportée à cette question.

Bonjour, y a-t-il une possibilité automatique de récupérer la liste des contributions d'un utilisateur dans une catégorie précise, ou dans les pages incluant un modèle particulier ? D'avance merci, Fourmidable ^abla ? _{aussi sur Wikiversité} 5 mars 2024 à 13:23 (CET)[répondre]

C'est techniquement possible, mais pas facilement accessible afin d'éviter des abus je pense. Le plus simple est de trier les contributions avec le menu avancé pour afficher que celles dans l'espace de noms des catégories, puis utiliser la magie Ctrl + F. Lofhi (discuter) 3 avril 2024 à 10:25 (CEST)[répondre]

OK merci ! Fourmidable ^abla ? _{aussi sur Wikiversité} 4 avril 2024 à 02:50 (CEST)[répondre]

Requête en attente d'une réponse. (comment y répondre ?)

Sur la version mobile de Wikipédia, je rencontre des problèmes d'affichage: la page ne s'adapte plus à la taille de l'écran (apparaissant donc très dézoomée) et les sections s'ouvrent automatiquement. Cela rend la lecture très ardue, et la navigation presque impossible.

PurpleCharlie (discuter) 6 mars 2024 à 01:57 (CET)[répondre]

Bonjour @PurpleCharlie.

Essayez d'appuyer sur le bouton « version mobile » en bas d'une page. Escargot (discuter) 6 mars 2024 à 06:21 (CET)[répondre]

Justement, le souci c'est que c'est bien sur la version mobile que je suis :/ PurpleCharlie (discuter) 6 mars 2024 à 15:08 (CET)[répondre]

Même dans votre navigateur ? Vous n'êtes pas en « disposition de bureau » ou équivalent ? Escargot (discuter) 6 mars 2024 à 20:55 (CET)[répondre]

Oui, je ne suis pas en disposition de bureau, j'ai bien vérifié PurpleCharlie (discuter) 6 mars 2024 à 21:02 (CET)[répondre]

En revanche, la disposition de bureau s'affiche aussi naturellement sur mon mobile si je ne la change pas PurpleCharlie (discuter) 6 mars 2024 à 21:02 (CET)[répondre]

Vérifiez ne pas avoir choisi d'afficher les sites web avec un mode « ordinateur » dans les paramètres de votre navigateur web. Vérifiez aussi d'être bien sur https://fr.m.wikipedia.org/. Avec le petit « m ». Lofhi (discuter) 3 avril 2024 à 10:27 (CEST)[répondre]

Hello Csar62 et la bande
pour une fois, je ne suis pas allé chercher ds les archives avant de vous poser ma question, parce que ça me semble un pwal compliqué.
Mon souci :
Récemment, j'ai fait qq modifs sur l'article Joe Bel, notamment ds la section /* Albums */ où j'ai rencontré ce « problème » :
Effet attendu :

• 2018 : Dreams (La Ruche)
• 2024 : Family tree

Effet obtenu :
2018 : Dreams (La Ruche)

• 2024 : Family tree

Explication :
Quand j'ajoute le modèle "{{pistes}}" (c'est pareil avec "{{Album}}") à l'album « Dreams », la puce disparaît et la date de l'album vient s'aligner en marge gauche ; j'ai essayé pas mal de trucs, mais quelle que soit ma tentative, ce qui précède le modèle (astérisque, espaces, etc.) disparaît et le wikilien "date de sortie de l'album" est collé à la marge gche.
Je précise que l'album « Family tree », lui, est en « texte simple » (sans modèle, juste le li "date")

Un « truc » pour obtenir l'effet attendu ?
Bonne aprèm' !
Edit : Arf... je réalise que j'aurais peut-être plutôt dû poser directement cette question sur les PdD des modèles ? Désolé, si c'était le cas.
— jeep (j33p) ॐ 6 mars 2024 à 13:57 (CET)[répondre]

Une réponse a été apportée à cette question.

Bonjour @J33p

J'ai modifié en ajoutant le modèle {{Liste pour légende}}. Est-ce que le rendu est bien celui que vous attendiez ? Escargot (discuter) 6 mars 2024 à 14:15 (CET)[répondre]

 j33p : Bonjour. ...le modèle {{Album}} n'a pas l'air conçu pour être utilisé dans une liste à puces. On peut regarder dans quelques-uns des 6000+ articles où il est utilisé, il y est toujours justifié à gauche... Cdlt Csar62 (discuter) 6 mars 2024 à 14:16 (CET)[répondre]

@Csar62, oui, c'est ce que je comprends (je m'en doutais après mes multiples essais infructueux).
C'est dommage — voire bizarre — vu que dans le § « Discographie  » de la page consacrée au plan « bio de musicien », la convention indique bien une liste à puces pour les œuvres.
Donc, je vais peut-être m'en ouvrir aux devs, sur les PdDs idoines, voir s'il ne serait pas intéressant de faire évoluer les deux modèles dans le sens du respect des conventions.

Merci de ton passage !
— jeep (j33p) ॐ 6 mars 2024 à 14:55 (CET)[répondre]

Salut Escargot bleu (on se vouvoie si tu préfères)

Hmmhhh... pour être tout à fait honnête avec vous, ce n'est pas tout à fait l'effet que je recherchais (car la puce semble 1/2 interligne plus bas que la ligne où se trouve l'album), c'est pô terrib' (àmha) ; mais c'est gentil d'avoir tenté et, surtout, j'ai découvert le modèle {{Liste pour légende}} que je ne connaissais pas, donc, rien que pour ça, merci !

Je vais réfléchir à ce problème (peut-être voir avec les devs des modèles).
— jeep (j33p) ॐ 6 mars 2024 à 14:45 (CET)[répondre]

Une réponse a été apportée à cette question.

Hello, firstly apologies writing in English.

I am working on the dark mode feature for MediaWiki and we are running into issues with making that work on French Wikipedia due to the non-standard use of infoboxes across the site.

The problem is as follows:

• When I visit Paris the infobox has the class "infobox_v2".
• When I visit Taos_Amrouche the infobox has the class "infobox_v3"

For some time we have been recommending projects adopt standard markup for common elements. Having machine readable standard markup across projects helps us ship features quicker and minimizes the work that technical editors need to perform.

My request: Could you please consistently add the infobox class to all infobox templates alongside the infobox_v2 and infobox_v3 class? If that's difficult to do, I'd love to understand why and work out how we can address this in the software. Not addressing this is likely to delay the roll out of dark mode to French Wikipedia so the sooner we fix this the better!

Thanks in advance for your guidance! Jon (WMF) (discuter) 6 mars 2024 à 22:00 (CET)[répondre]

J'ai pris la libert�� de traduire, --Dezedien (discuter) 7 mars 2024 à 15

48 (CET)

Bonjour, tout d'abord je m'excuse d'écrire en anglais.

Je travaille sur la fonctionnalité mode sombre prévue pour MediaWiki et nous rencontrons des problèmes pour la faire fonctionner sur la Wikipédia française en raison de l'utilisation non standard des infobox sur le site.

Le problème est le suivant :

• Lorsque je visite Paris, l'infobox a la classe "infobox_v2".
• Lorsque je visite Taos_Amrouche, l'infobox a la classe "infobox_v3"

Depuis un certain temps, nous recommandons aux projets d'adopter un balisage standard pour les éléments communs. Le fait de disposer d'un balisage standard lisible par machine dans tous les projets nous aide à livrer les fonctionnalités plus rapidement et minimise le travail que les rédacteurs techniques doivent effectuer.

Ma demande : Pourriez-vous ajouter systématiquement la classe infobox à tous les modèles d'infobox, aux côtés des classes infobox_v2 et infobox_v3 ? Si c'est difficile à faire, j'aimerais comprendre pourquoi et voir comment nous pouvons y remédier dans le logiciel. Le fait de ne pas résoudre ce problème risque de retarder le déploiement du mode sombre sur Wikipédia en français, donc plus vite nous réglerons ce problème, mieux ce sera !

Merci d'avance pour vos conseils ! Jon (WMF) (discuter) 6 mars 2024 à 22:00 (CET)

@Od1n perhaps you have some historical context here?

My understanding is you used to have an infobox class based on tables, but it seems if that is the only reason, all those classes and associated styles could be renamed infobox_v1 ? Jon (WMF) (discuter) 6 mars 2024 à 22:01 (CET)[répondre]

Some context : this discussion, where I also link to here, here, and here.

The problem is that there are hardcoded styles into MediaWiki (and strong ones, causing important layout changes, sometimes even having "!important"…). So for instance if we add ".infobox" to use the MoveLeadParagraph feature, that causes issues because MediaWiki also applies CSS to that class. Most of the issues are in the Minerva skin. See skins.minerva.content.styles/hacks.less. Same problem with ".ambox" for example, see this search.

By the way, on frwiki "infobox_v2" and "infobox_v3" are very different and certainly will never be merged. Of course, we could add a common class to both of these, to mark all infoboxes, but what would be the roles of this class? Soon or late, various unrelated roles would be added to that class.

On a related note, very legacy infobox templates on frwiki were using the ".infobox" class, and there are some leftovers on that on the wiki.

For me, the only acceptable solution, long-term viable, would be fine-grained configurability: for feature X, let wiki Y specify that the class assigned to this role is class Z (or more complex selector, allowing for several classes, nested class, and so on).

od†n ↗^blah 7 mars 2024 à 07:02 (CET)[répondre]

@Od1n, what is the problem with .infobox class? What does it breaks on wiki, and what would it cost us to fix it? Trizek ^bla 7 mars 2024 à 14:54 (CET)[répondre]

Tu n'as pas lu les messages et les recherches de codes que j'ai indiqués ? Et ce que ça coûte, c'est un gros, gros paquet de bordel à nettoyer, alors ça serait bien de ne pas en rajouter encore plus… od†n ↗^blah 7 mars 2024 à 15:19 (CET)[répondre]

@Od1n I tried out the infobox styles there and I see no clash.. in fact in some cases it improves things on mobile.

That said, do you know you can disable all of these rules by site configuration? In future we plan to allow more fine control so you can cherry pick the optimizations you need phab:T358071).

If that's the reason you are not using those classes, that would be a better outcome here? Jdlrobson (discuter) 7 mars 2024 à 17:45 (CET)[répondre]

@Od1n, j'ai survolé, faute de plus de temps, mais la question m'intéresse vraiment car elle semble aussi couvrir des problèmes d'accessibilité sur les infobox (cas des couleurs non accessibles). Désolé de te demander de répéter, mais je sais que tu es la personne qui a le plus de connaissance dans ce domaine. :)

J'ai l'impression que ce sont nos ajouts, dans le temps, qui ont complexifié le code de base, non ?

Comme @Jdlrobson, j'ai rapidement testé en ajoutant la class .infobox via l'éditeur de code à diverses infobox sélectionnées, et je n'ai pas vu de conflits. Et vu qu'il existe une possibilité d'ajouter la class sans en avoir les inconvénients, autant l'utiliser, non ? Trizek ^bla 7 mars 2024 à 18:27 (CET)[répondre]

Le problème principal est que sur ces classes "infobox", "ambox", etc. la skin Minerva applique de force tout un tas de hacks qui sont prévus spécifiquement pour les éléments de enwiki.

(à voir le coup du wgMinervaApplyKnownTemplateHacks, mais déjà voir s'il n'y a pas encore d'autres problèmes, et ensuite, pourquoi se faire appliquer des trucs, puis essayer de les annuler du mieux qu'on peut en espérant avoir tout repéré, alors que la solution correcte serait juste de ne pas les appliquer à la base.)

Et alors non, ce n'est pas parce que "ça a l'air d'aller" visuellement que ce n'est pas complètement pourri en dessous et qu'on ira s'en mordre les doigts plus tard. Nous en sommes déjà à cette situation alors j'essaie de ne pas aggraver les choses.

Et non, ce ne sont pas "nos ajouts" qui ont complexifié les choses, mais certains développeurs de mediawiki qui nous empilent encore et encore des couches de bazar. À chaque fois c'est seulement à moitié correct, et la partie pourrie au lieu d'être traitée elle reste en dette technique.

od†n ↗^blah 8 mars 2024 à 04:28 (CET)[répondre]

Merci pour les précisions. Les hacks sont juste pour enwiki ? Ou s'agit-il de la configuration par défaut que enwiki n'a pas changée ?

La désactivation des règles via la configuration semble être une possibilité à explorer. Cela mettrait visiblement tout le monde d'accord : les définitions de la class CSS ne seraient pas appliquées, mais on aurait toutes les infobox prises en compte par MediaWiki pour les différents rendus.

Et on est d'accord : il faut réduire la dette technique chaque fois qu'elle existe. Tout comme il faut rendre compatible nos wikis avec les outils par défaut. :)

Trizek ^bla 8 mars 2024 à 14:48 (CET)[répondre]

Pour le coup @Trizek, je pense qu'on peut comprendre la frustration d'@Od1n. La page de recommandations citée date de 2018 dans sa version originale. Notre projet a vu le jour en 2001. Même si les bénévoles techniques étaient à jour sur toutes les problématiques, il y a 23 ans de passif à corriger par des... contributeurs bénévoles. Je pense que parler de « non-standard use of infoboxes » est un anachronisme : ce n'est pas la fondation à travers MediaWiki qui a donné vie à ces boîtes. Ce sont les communautés qui ont créés des boîtes pis un standard est apparu du côté de la WMF, assez communiqué ou non, avec un consensus communautaire ou non et maintenant une quasi-obligation de les utiliser, sauf à demander à la WMF de supporter un cas différent par édition de projet (possiblement). Pour autant, personne ne devrait jeter la faute personne : on avait déjà discuté (je m'en souviens parce que j'avais initié le sujet) il y a quelques années des classes ambox pour la version mobile. Si je ne me trompe pas, elles ne sont pas utilisées chez nous afin de s'accommoder de l'existant, tout simplement par manque de mains et de temps. Même si certains viennent par ici et par là corriger des problèmes techniques, le nombre de contributeurs qui s'attardent à la maintenance continue comme @Od1n sont très peu nombreux. Annoncer le mode nuit en novembre dernier pour finalement se rendre compte en mars suivant que les projets ne sont clairement pas prêts, c'est mettre la pression sur tout le monde. Lofhi (discuter) 11 mars 2024 à 00:29 (CET)[répondre]

J'ai entamé la migration des 500 infobox V2 restantes. Cela va me prendre facilement plusieurs semaines. Plus d'un an si j'avance qu'au rythme d'une infobox par jour si personne d'autre n'a envie de me rejoindre (et je les comprends). Une fois que nous aurons que des infobox V3 et Lua l'unification pourra être réalisée sur des bases plus saines. Heureusement que des courageux avaient déjà migré le plus gros en V3 au fil des années... Lofhi (discuter) 11 mars 2024 à 20:58 (CET)[répondre]

@Lofhi, merci pour ces détails. Comme je disais plus tôt, le sujet m'intéresse pour ce qui concerne l'accessibilité et l’unification graphique. Je découvre les méandres des infobox, qui est un niveau au dessus des pages et modèles sur lesquels j'ai pu travailler.

J'essaye de dévider la pelote des informations, et je ne parviens pas toujours à comprendre certains points. Ici, l'utilisation de .infobox et .ambox. Ces classes ajoutent des définitions CSS dont nous n'avons pas besoin, mais en même temps, elles sont visiblement indispensables pour gérer l'affichage de ces éléments sur les différents habillages (un objectif de standardisation que je comprends). Or, Jon dit qu'il est possible d'avoir ces deux classes utilisées mais sans quel leurs effets ne s'appliquent. elles sont alors utilisées uniquement pour de la détection.

De ce que je comprends, en faisant ces modifications, nous aurions nos infobox prises en charge sur les différents affichages, sans avoir les inconvénients. Sauf erreur, cela consisterait à :

1. passer les classes dont nous ne voulons pas les définitions dans la configuration afin de les exclure
2. ajouter .infobox à {{Classes début infobox}} pour couvrir les infobox v2 et v3 qui utilise ce modèle.

On en profite pour passer Ambox et appliquer la classe aux bandeaux d'info (qui auraient besoin d'un petit effort pour l'affichage sur mobile).

Aussi ma question - très sincère - est simple : pourquoi ne pas le faire ? Trizek ^bla 13 mars 2024 à 16:07 (CET)[répondre]

Je pense qu'Od1n a déjà répondu à cette question @Trizek. « Of course, we could add a common class to both of these, to mark all infoboxes, but what would be the roles of this class? Soon or late, various unrelated roles would be added to that class ».

Oui, ce que Jon dit fonctionne, mais ce n'est pas une correction qui vise le long terme, c'est une rustine pour un problème qui vient d'apparaître. La solution propre est d'abandonner .infobox_v2 en migrant toutes les infobox V2 restantes vers V3/Lua qui utilisent la classe .infobox_v3, mais qu'on renommera en .infobox, tout en étudiant ce que cela implique graphiquement. Répéter l'étape pour toutes les classes standardisées puisque visiblement elles sont stables et cela évitera de nous ronger les doigts (comme maintenant à quelques semaines de la généralisation du mode nuit). Pis dès lors travailler avec une seule classe standardisée pour les infobox devrait simplifier l'utilisation de Codex les prochains mois pour la cohérence graphique. Sauf que Codex est encore loin d'être mature, donc je m'avance. Lofhi (discuter) 13 mars 2024 à 18:51 (CET)[répondre]

Le dernier point d'Od1n devrait être réglé avec T358071, mais je ne considère pas ça comme une solution... C'est un état intermédiaire à la rigueur. Lofhi (discuter) 13 mars 2024 à 19:03 (CET)[répondre]

Je ne dis pas que nous allons vers une solution définitive avec l'annulation des classes CSS dans la config (config qui annule tous les rôles présents ou ajoutés). C'est effectivement une rustine, mais elle permet d'avancer, au moins pour que nos publics aient une expérience meilleure sur mobile ou avec le mode sombre. Pour moi, ça se tente, si c'est bien documenté pour ne pas perdre cette information. Trizek ^bla 14 mars 2024 à 20:57 (CET)[répondre]

Je suis pour la rustine, mais seulement pour la rustine et non comme une solution. Si cela permet à la WMF de débloquer la situation de son côté, je vois mal l'intérêt de résister. Les surrécritures de la WMF visiblement ce jour rendent la version de Minerva potable : https://fr.m.wikipedia.org/wiki/Aya_Nakamura?minervanightmode=1

Mais bon, pour une solution à long terme qui implique de revoir tous les modèles, autant dire qu'on n'y sera pas avant un moment... Lofhi (discuter) 14 mars 2024 à 21:40 (CET)[répondre]

Merci/ L’essentiel me semble être que cela permet à tout le monde d'avancer. Trizek ^bla 19 mars 2024 à 17:58 (CET)[répondre]

Hello @Trizek (WMF) Puis-je suggérer une idée peut-être bête ou prématurée: pour cet important travail technique, serait-il envisageable d'avoir le soutien d'un employé de la fondation pour l'adaptation de notre wiki ? C'est un travail purement technique, pas éditorial, et demandé par la fondation pour rester à l'état de l'art. Bien que la communauté resterait questionnée pour les décisions ayant un impact utilisateur.

On pourrait peut-être même envisager une demande de financement m:Grants:Project/Rapid/fr si un bénévole veut être rémunéré pour cette tâche. Le JS et le CSS ne sont pas du tout mon domaine de compétence pour ma part . -Framawiki ^✉ 23 mars 2024 à 18:07 (CET)[répondre]

Je pense que cela dépasse la simple question d'un soutien @Framawiki. Le mode nuit tombe trop tôt dans l'agenda de la WMF. J'ai demandé des palettes de couleurs et des composants utilisables directement depuis le wikicode en réutilisant Codex et grosso modo la réponse est : pas avant un moment (voir T359644 et T182050). Nous sommes dans une situation inconfortable où toutes les corrections qui doivent être réalisées devront peut-être être retapées si on veut s'appuyer de Codex pour viser le long terme. Même le mode nuit de la WMF actuel ne s'appuie pas de Codex ; la WMF devra le revoir pour intégrer Codex (voir T358031#9650862). Lofhi (discuter) 23 mars 2024 à 19:02 (CET)[répondre]

Y a aussi T355242 où j'ai spécifiquement râlé de comprendre que Codex ne serait pas facilement réutilisable. J'étais peut-être un peu nerveux ce jour-là. Lofhi (discuter) 23 mars 2024 à 19:06 (CET)[répondre]

@Framawiki, oui, on pourrait. Cependant, il y a beaucoup de choses qui se bousculent, aussi il me semble plus sage de trier un peu et de traiter les choses l'une après l'autre. :)

La question est ici d'ajouter une classe CSS aux infobox pour qu'elles soient identifiées comme telles.

Je sais qu'il y a d'autres questions, mais présentement, je cherche à comprendre ce qui empêche d'ajouter ces classes, sachant que les valeurs seront exclues.

Je m'arrête là : on passera à la suite quand on aura décidé de cette étape. Trizek ^bla 25 mars 2024 à 12:14 (CET)[répondre]