Discussion Wikipédia:Atelier accessibilité/Archives accessibilité 2012

Longueur des articles

Bonjour, certaines pages mettent vraiment longtemps à s'afficher quand la liaison internet est un peu capricieuse. Je ne me souviens plus de la méthode pour trouver le poids d'une page et puis y a-t-il des recommandations de limitation à ce sujet quelque part ? --Amicalement, Salix ( converser) 4 janvier 2012 à 10:40 (CET)

Oh, un de mes serpents de mer préféré, l'un des plus jolis

Pour aller à l'essentiel:

• rappel : le poids de la source wiki indiqué par mediawiki (par exemple dans les historiques) n'est pas une donnée significative : deux articles de même poids « wiki » peuvent donner des pages finales (celles qui sont consultées) de poids réel très différents, selon le rôle des images, des modèles etc.
• pour évaluer le poids final d'une page, le mieux est de passer par un service en ligne (ça peut aussi se faire via une extension du navigateur quand on utilise par exemple Firefox, mais cela peut alors être trompeur, je n'entre pas dans les détails obscurs). Un exemple de service de ce type : [1], mais on peut trouver plus simple et en français.
• pour les recommandations : il n'y en pas, ou du moins celles qui traînent encore ça et là dans les pages meta de Wikipédia sont obsolètes. Disons qu'un gros article peut couramment atteindre 1 Mo au final sans que ce soit choquant. Cela place les articles Wikipédia dans la catégorie des obèses si on compare à ce qui se fait sur d'autres sites où ce souci de qualité est spécifiquement pris en compte, mais c'est comme ça.
• pour aller plus loin : pour le moment, je ne sais pas. La difficulté serait de trouver quoi dire aux contributeurs dans quelque-chose qui est très technique (l'impression de vitesse d'affichage en fonction du codage de la page a autant d'importance que la vitesse réelle même si c'est fictif ; l'optimisation réelle du poids des pages Wikipédia passe avant tout par celle des images, qui est loin d'être simple ; l'optimisation javascript joue elle aussi un rôle important ; on a pas du tout la main sur ce que font les développeurs en matière d'astuces de codage des pages et qui n'est pas forcément heureux ; etc.). AMHA, retenir simplement que quand l'intérêt éditorial incite à déplacer une partie du contenu vers un article détaillé en laissant un résumé dans l'article principal, c'est toujours bien.

--Lgd (d) 4 janvier 2012 à 11:03 (CET)

aller, ma question habituelle : je serais curieux de savoir à quels « détails obscurs » tu penses dans le point #2. od†n ↗^blah 4 janvier 2012 à 16:52 (CET)

Par exemple, en cas de proxy FAI optimisant le contenu. --Lgd (d) 4 janvier 2012 à 17:18 (CET)

Merci pour cette réponse rapide et complète. Où peut-on lire exactement pour commencer le poids de la source wiki car c'est déjà, si je comprends bien, un indicateur de longueur du code qui permet de débusquer les logorrhées verbales. --Amicalement, Salix ( converser) 4 janvier 2012 à 11:37 (CET)

Il est vrai que les articles longs sont parfois accompagnés de beaucoup d’images pour les rendre plus digestes, cependant cela n’est pas très indicatif : par exemple les timeline utilisent une certaine place dans les articles, alors que l’appel à une image de Fichier: est beaucoup moins lourd.

Le poids de la source est indiquée par Mediawiki dans l’historique pour chaque version, entre le nom d’utilisateur et le résumé d’édition, et y est visible à condition de ne pas avoir activé le gadget « HistoryNumDiff »
Ltrl G, le 4 janvier 2012 à 13:55 (CET)

Merci Ltrl, j'avais coché ce gadget ! Mais comment éviter d'avoir des poids lourds comme Roger Federer ou Napoléon III qui flirtent avec les 300 000 octets ? --Amicalement, Salix ( converser) 4 janvier 2012 à 14:36 (CET)

Petite question à propos des liste de définitions

Est-ce que quelqu’un pourrait me dire si j’ai raison de penser que des listes de définitions seraient plus adaptées à cette page que des listes classiques ?
Ltrl G, le 4 janvier 2012 à 17:36 (CET)

Tout à fait, comme dans l'exemple du Glossaire du cinéma. --Lgd (d) 4 janvier 2012 à 17:51 (CET)

 Fait. Encore du travail à faire dessus, mais pas tout de suite
Ltrl G, le 4 janvier 2012 à 18:26 (CET)

Et là ?
Ltrl G, le 7 janvier 2012 à 00:05 (CET)

Oui, mais le besoin est moins évident que dans le cas de page proprement « glossaire ». --Lgd (d) 7 janvier 2012 à 00:10 (CET)

Mais comme les éléments de la liste actuelle sont orphelins, autant transformer, non ?
Ltrl G, le 7 janvier 2012 à 00:48 (CET)

Belle infobox

Je viens de tomber sur ceci : {{Infobox Joueur de basket-ball}}. Dans la section « Carrière professionnelle », la mise en page (qui ressemble au tableau qu’elle devrait être) est faite avec… des <br />.
Ltrl G, le 4 janvier 2012 à 21:45 (CET)

Oui, le problème est fréquent en fait. Le souci est que c'est un mode de saisie très pratique pour les contributeurs. Il évite de leur imposer l'usage de sous-modèles (types sous-groupes de palettes ou listes horizontalisées des palettes par exemple) ou celui de multiples paramètres numérotés foo1=... | foo2=... | foo3=... etc. avec en prime une limite du nombre d'occurences à déterminer dans le modèle. D'autre part, la correction de l'infobox nécessite alors un passage de correction dans chaque article, pas forcément aitomatisable avec un bot. Ce n'est pas simple. C'est douloureux. C'est comme ça... --Lgd (d) 5 janvier 2012 à 21:59 (CET)

Infobox V3 et carte

Comme ma question semble, par deux fois, avoir échapper à vos regards plus haut, je la remet ici. Y-a-t'il un moyen de résoudre le problème ci-dessous, que cela soit par un nouveau bloc V3, une « class » particulière, ou carrément la refonte total du système de carte géolocalisé ? (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 5 janvier 2012 à 19:24 (CET)

le Problème

Atelier accessibilité/Archives accessibilité 2012

Localisation sur la carte de Russie Moscou.

---

---

Localisation sur la carte de Russie Moscou.

---

capture d'écran du problème, au cas où

 

Note : j'utilise Windows 7 et Firefox 8.0. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 5 janvier 2012 à 19:25 (CET)

Encore une fois, désolé si la première fois n'était pas passée : Il ne faut pas mettre de modèles de cartes avec géolocalisation, de cartes complétées ou autres cartes bricolées avec des astuces CSS dans les infobox V3. Cela n'a pas de sens : tu mets un bidouillage techniquement périlleux et par ailleurs dramatique pour l'accessibilité dans un modèle d'infobox destiné à obtenir un résultat dont l'accessibilité est certifiée. Ces choses-là sont très bien dans des infobox V2, qui sont d'excellents modèles, tant qu'il n'y a pas enfin une solution de génération de cartes côté serveur.

Un peu fatigué ce soir, d'où ma réponse rapide, mais à ta disposition pour expliquer en détail. Cordialement, --Lgd (d) 5 janvier 2012 à 21:08 (CET)

Réponse du comte Ɲemoi – Le projet des infoboîtes V3 restera un échec tant qu’il ne sera pas admis qu’il y a des demandes et que les modèles d’infoboîtes doivent s’y plier. Un modèle de carte accessible est à coder, sinon il y aura des hacks. Mais je me répète, non ? ce 5 janvier 2012 à 22:32 (CET).

Un modèle de carte fait en CSS avec un assemblage d'une image de fond (image HTML ou background CSS) et de ce qu'on voudra (texte, lien image, élément vide rempli avec un background, combinaison des précédents) de la manière CSS qu'on voudra (positionnement, autre) ne peut pas être fait de manière accessible, parce que le recours à CSS pour générer un contenu ne peut pas être accessible : CSS ne sert fondamentalement pas à générer du contenu, mais uniquement à en faire la mise en forme. Il est donc inutile de réclamer le codage d'un modèle de carte accessible.

Les seules solutions s'appellent génération d'image côté serveur ou SVG directement servi au navigateur. Pour le moment, elle n'existent pas dans l'univers Wikimedia. Donc, on garde le bricolage à base de CSS qui est inévitable ; on sait que ce n'est accessible, on en tient compte et on passe à autre chose sans compromettre ce qui se fait en dehors de ce type de contenus.

Encore une fois : Dès lors qu'une infobox n'est pas actuellement portable en V3, il n'y a aucun souci pour qu'elle reste en V2 et il n'y aura aucun bénéfice à en faire à tous prix une V3 non accessible. --Lgd (d) 5 janvier 2012 à 22:42 (CET)

Il y aurait, cela dit, quelque-chose d'extrêmement pervers à faire des « hacks » (forcer des modèles non pertinents en V3), à les encourager ou à les provoquer : faire une V3, c'est pour le rendre accessible. Faire ce genre de hacks, c'est bosser pour faire inévitablement du non accessible tout en voulant faire de l'accessible. Personnellement, le masochisme n'est pas ma tasse de thé, pas vous  ? --Lgd (d) 5 janvier 2012 à 23:00 (CET)

Réponse du comte Ɲemoi – Il est parfaitement possible d’obtenir un modèle affichant une carte et facilitant l’accès à tous, en rangeant les coordonnées géographiques dans un zouli tableau permettant l’affichage d’une carte « pour ceux qui trouvent ça utile ». Les infoboîtes v2 génèrent un code html abscons et rarement accessible, il est encore temps que le projet accessibilité formalise une solution pour régler ce problème, avant que ce ne soit fait par d’autres. La seule solution pour éviter les hacks, c’est d’offrir des méthodes pour faire ce que l’on souhaite qui facilitent l’accès à tous, en attendant un avenir meilleur pour la technique. Ce 5 janvier 2012 à 23:21 (CET).

Le problème technique d'accessibilité n'est pas de fournir une pseudo-alternative du type tableau de coordonnées. Sinon, ce serait déjà en place... A ce stade, je laisse d'autres tenter de faire de la pédagogie, je perds mon temps (Pour ceux qui me connaissent personnellement ou professionnellement, il est extrêmement rare qu'en tant qu'expert accessibilité, je dise « non, ça, il n'y a pas moyen ». Si je le fais dans ce cas, ce n'est pas à la légère du tout, du tout, du tout...). Bonsoir, --Lgd (d) 5 janvier 2012 à 23:29 (CET)

Réponse du comte Ɲemoi – Le but d’un atelier d’accessibilité sur Wikipédia, c’est de faire au mieux avec ce qu’on a, pas de laisser une situation moisir en traitant de manière irréprochable 0,1 % des infoboîtes. La solution optimale n’est effectivement pas possible actuellement, mais entre les infoboîtes v2 et elle, il y a une bonne dizaine de pas, que l’on gagnerait à faire. Si ce n’est l’atelier d’accessibilité qui s’en charge, c’en sera d’autres. Ce 5 janvier 2012 à 23:40 (CET).

Le cas Nemoi

Je regrette d'en venir là, mais bon, vu ce qui précède, appelons un chat un chat et ne tournons plus autour du pot.

@Nemoi, d'autres te l'ont fait remarquer dans une discussion similaire il y a peu ici : tu es le seul à te placer à propos de ces modèles d'infobox V3 dans une position systématique d'obstruction, d'opposition, de cafouillages qui partent en discussions stériles avec comme seul résultat que ce travail reste pour le moment en suspens.

Je pose clairement la question aux autres contributeurs qui s'investissent dans ces problèmes d'amélioration de l'accessibilité : quelle solution pouvez-vous apporter à ce problème ?

Pour ma part, je suis frappé du décalage complet entre les discussions de ce type ici et ce qui se fait malgré tout ailleurs aujourd'hui même avec d'autres intervenants. Et très simplement incertain quant à la suite à donner à ce que je peux faire dans ce domaine avec vous. Dans tous les cas, il est évident que cela n'ira pas loin sans que quelque-chose ne se décide. Et je ne ferai pas les choses à la place d'autres personnes à cet égard.

Après mes premiers tests dans ce domaine en 2008, il a fallu repousser et attendre 2 ans avant de pouvoir enfin amorcer cette amélioration des infobox, à cause d'un problème similaire. Je ne le ferai pas deux fois.

Cordialement, --Lgd (d) 5 janvier 2012 à 23:47 (CET)

Réponse du comte Ɲemoi – On voit quelqu’un qui refuse toute amélioration concrète des infoboîtes telles qu’elles sont actuellement sous prétexte que l’avenir serait radieux. Sauf qu’en l’état, il y a de plein d’infoboîtes de créées et d’améliorées, qui ont des codes catastrophiques, et rien n’est fait à ce sujet. Ta pratique de ces modèles est très limitées, comme le démontre le modèle : Tapis persan qui donne comme rendu sur la moitié des articles où il est placé ceci… génial, je suppose que c’est toi qui va corriger, n’est-ce pas ? Pour ma part, j’attaque une vraie refonte des infoboîtes dans le mois ; ça signifie que le plus gros du problème d’accessibilité est réglé d’ici mars, si personne ne me met de bâtons dans les roues. Ce 6 janvier 2012 à 00:03 (CET).

Il t'es venu à l'esprit que tu pouvais (apparemment depuis quelques temps au moins) signaler ce problème ici ? Dans ma page de discussion ? Dans la page de discussion du modèle ? Quelque-part ? Parce que la solution est triviale (si quelqu'un peut prendre la liste des pages liées, regarder le cas échéant pour un bot ? Fait).

Ou bien c'est juste une variante du piratage de compte administrateur auquel tu t'étais livré et qui était aussi, sans doute, une manière collaborative de faire les choses ? Bon, bref, moi, je suis usé par ce genre de choses et de pratiques. --Lgd (d) 6 janvier 2012 à 00:37 (CET)

Réponse du comte Ɲemoi – Une attaque personnelle de plus, et encore pour masquer ton incapacité à régler correctement le problème des infoboîtes. Il est vrai que quand je vois qu’est notée par toi en V3 l’infoboîte Bataille Rome antique, tu te situes bien pour parler des hacks de modèles. Il serait préférable que je me charge de ce dossier, comme je me suis chargé des hiddenStuctures, ce que tu n’avais réussi à faire depuis 2008, tu dis ? quelle efficacité… Ce 6 janvier 2012 à 00:53 (CET).

Résumons : ma pratique des modèles est très limitée, je suis incapable de régler correctement le problème des infoboîtes, Modèle:Bataille Rome antique est apparemment un mauvais modèle hacké, j'ai été incapable de régler le problème des hiddenStuctures. Il faut indéniablement se poser la question, mais je laisse la réponse éventuelle à d'autres contributeurs : je suis manifestement incompétent à tous égards. Dès lors, dois-je continuer à intervenir dans ce genre de choses  ? Pourquoi ne pas laisser Nemoi régler à lui seul en un mois le plus gros du problème d’accessibilité, comme il le propose ? --Lgd (d) 6 janvier 2012 à 08:17 (CET)

S'il gère « l'accessibilisation » des modèles comme il a réglé le problème du modèle:Infobox Tapis persan, alors cela va être très efficace et très rapide. Udufruduhu (d) 6 janvier 2012 à 10:08 (CET)

Pour modèle:Infobox Tapis persan, je me suis effectivement trompé au mois d'août dernier, en retirant trop vite le code temporaire qui évitait l'erreur de rendu, croyant avoir effectué les corrections dans les articles. En fait, j'avais oublié ces corrections que je n'avais apparemment pas notées dans ma page de suivi. My fault, donc. Mais s'agissant d'à peine une trentaine d'articles et d'un projet très peu actif, il n'y a apparemment eu aucun signalement d'erreur nulle part. Bref, je suis repassé ce matin dans les articles concerné, c'est réparé à présent, mes excuses pour cette erreur. --Lgd (d) 6 janvier 2012 à 10:21 (CET)

Pas de souci, j'avais bien compris. Je signifiais juste qu'étant donnée la solution simple au problème, je ne comprends pas que Nemoi avec ses grandes capacités ne l'ait pas trouvée et résolu le problème directement… Udufruduhu (d) 6 janvier 2012 à 10:49 (CET)

Réponse du comte Ɲemoi – Car quitte à faire 18 éditions, il aurait été intelligent de renommer l’infoboîte, et de la passer en paramètres nommés, de lui écrire une documentation, et de passer tout dans les articles ; l’infoboîte a été corrigée par Ju gatsu mikka, mais cela n’est même pas répercuté dans les articles malgré les éditions de Lgd, qui — je confirme — n’a pas une pratique des modèles, c’est-à-dire ne songe absolument pas à comment il vont être introduits et maintenus dans l’espace encyclopédique. Je ne suis pour ma part pas partisan du travail vite fait mal fait. Ce 6 janvier 2012 à 13:07 (CET).

Techniquement je suis une truffe, par contre cela fait longtemps que je suis les interventions des uns et des autres. J'admire votre niveau de connaissance dans ce domaine, ce qui est rare sur Wikipédia. Je témoigne simplement que Lgd sait parfaitement travailler en binôme, avec modestie et efficacité, quand c'est au sein d'un dialogue ouvert et consensuel. On s'en fiche de savoir qui est le plus fort en codage : deux cerveaux valent toujours mieux qu'un ! L'important c'est de faire progresser l'accessibilité et - selon l'avis de la plupart des intervenants ici - d'avoir des infobox V3 irréprochables sur ce point. Mais, Nemoi, on ne peux pas affirmer à quelques lignes d'écart que « Le but d’un atelier d’accessibilité sur Wikipédia, c’est de faire au mieux avec ce qu’on a, pas de laisser une situation moisir en traitant de manière irréprochable 0,1 % des infoboîtes » et dans la section en dessous « Je ne suis pour ma part pas partisan du travail vite fait mal fait ». Cela me semble tout à fait contradictoire et àmha il vaudrait peut-être mieux, dans ces conditions, utiliser tes compétences et ton expérience à l'amélioration et l'entretien des infobox V2 qui seront encore pendant longtemps largement en usage. --Amicalement, Salix ( converser) 6 janvier 2012 à 14:22 (CET)

Modèle:Infobox subdivision du Népal

La récente conversion à moitié de cette infobox au format V3 par Nemoi n'aide vraiment pas : faute d'utiliser le modèle approprié pour l'image, le résultat n'est pas accessible. Prendre le temps de bien faire les choses, de demander de l'aide au besoin, ce serait vraiment préférable. Là encore, je ne sais plus par quel bout prendre ce genre de contribution. C'est désarmant, cette manière d'ignorer complètement ce qui est dit, écrit, expliqué, répété… --Lgd (d) 14 janvier 2012 à 13:32 (CET)

Réponse du comte Ɲemoi – Ben écoute, tu n’as qu’à la remettre dans une version avec des hiddenStructure, si ça te fait plaisir. Ce 14 janvier 2012 à 13:45 (CET).

District de Dhading
धादिङ जिल्ला

Légende de la carte

•       District de Dhading
•       Autres districts de la zone de la Bagmati
•       Autres zones de la région Centre
•       Autres districts, zones et régions

Bon, essayons une solution faute de mieux. Est-ce que tu pourrais, en guise de minimum d'effort pour participer de manière collaborative:

• signaler ici les modèles que tu convertis ?
• demander de l'aide en cas de difficulté ?

Voici un point de départ pour corriger le code que tu as produit (résultat ci-contre) :

{{Infobox V3/Début|background=#e0e0e0|text=District de Dhading<br><span lang="ne" class="lang-ne" style="font-size:90%;">धादिङ जिल्ला</span>}}
{{Infobox V3/Image|image=Dhading district location.png|alt=Localisation sur la carte du Népal}}
{{Infobox V3/Titre Bloc|class=hidden||text=Légende de la carte}}
<ul class="legend" style="text-align:left; border:1px solid #ccc; margin:0.3em auto; padding: 5px;">
<li style="list-style:none;"><span style="border: 1px solid black; background-color: red;">    </span>  District de Dhading</li>
<li style="list-style:none;"><span style="border: 1px solid black; background-color: #c0c0c0;">    </span>  Autres districts de la [[Bagmati (zone)|zone de la Bagmati]]</li>
<li style="list-style:none;"><span style="border: 1px solid black; background-color: #f2f2f2;">    </span>  Autres zones de la [[région de développement Centre|région Centre]]</li>
<li style="list-style:none;"><span style="border: 1px solid black; background-color: #fcf5e3;">    </span>  Autres districts, zones et régions</li>
</ul>
{{Infobox V3/Fin}}

Quelques conseils :

• Ne pas utiliser la syntaxe *<li> (c'est de là que venait le div excédentaire généré par mediawiki pour la légende) ;
• Ne pas ajouter xml:lang dans les modèles : il est automatiquement généré par mediawiki en présence d'un lang ;
• Ne jamais inclure l'image d'une infobox V3 avec un paramètre {{{image}}} et des image=[[Image:Dhading district location.png|250px|Localisation du district de Dhading]] dans les articles : cela casse l'accessibilité de l'image.
  Utiliser uniquement le modèle {{Infobox V3/Image}}. S'il faut modifier la manière dont l'image est indiquée en paramètre dans les article, il y a un code temporaire pour cela qui permet de faire les modifications via un bot ou à la main selon les besoins, puis de basculer sur le modèle d'image accessible :

  {{#ifexist:Media:{{{image|}}}|{{Infobox V3/Image|image={{{image|}}}|legend={{{légende|}}}}}|<div class=center>{{{image|}}}</div>}}

• Ne pas mette d'attribut style="list-style:none;" sur un span : il ne sert à rien
• Prendre le temps de faire les choses proprement.

--Lgd (d) 14 janvier 2012 à 14:03 (CET)

Réponse du comte Ɲemoi – L’infoboîte ne sera pas accessible de toute façon, elle utilise une légende basée sur la couleur… Quant à la modification que tu proposes, elle impose de passer sur tous les articles (ai rédigé avant ton édition de correction) ; n’hésite pas, c’est ton code, le mien date d’octobre, une époque où je n’avais pas encore réalisé complètement les embêtements que représentent les infobox v3. Ce 14 janvier 2012 à 14:22 (CET).

Oui, il faut passer dans les articles pour mettre à jour le paramètre image et ensuite enlever le code temporaire et le remplacer par le modèle {{Infobox V3/Image}} simple. Cela peut se faire à la main dans les infobox peu employées ou via un bot, comme cela a déjà été fait lors de nombreuses conversions… --Lgd (d) 14 janvier 2012 à 14:31 (CET)

Bon, bref. J'ai corrigé l'infobox (qui comportait une autre erreur, d'ailleurs, sur l'affichage de la population), un bot va passer mettre à jour les articles. Si on pouvait éviter de rejouer ça trop souvent, ce serait mieux. --Lgd (d) 14 janvier 2012 à 16:07 (CET)

Réponse du comte Ɲemoi – Ça n’en reste pas moins qu’une infoboîte v3 intrinsèquement non accessible comportant un hack pseudo-html et un hack incompréhensible par une majorité de personnes (et qui donc sera très certainement corrigé d’une autre manière — peut-être accessible — si quelqu’un édite le modèle). Enfin, elle a gagné en propreté du code, c’est certain ; plus que quelques milliers comme ça… Ce 14 janvier 2012 à 16:27 (CET).

Si tu veux poursuivre dans cette voie avec moi, je veux bien, au contraire : cela sera peut-être utile pour améliorer ce ou ces modèles. Mais dans ce cas, merci de détailler précisément ici le ou les critères WCAG2 non respectés, l'impact, les solutions potentielles, leur faisabilité, ainsi que les éventuelles contraintes tierces. Si tu souhaites discuter sérieusement et utilement d'accessibilité, il faut le faire rigoureusement. --Lgd (d) 14 janvier 2012 à 16:35 (CET)

Et comme c'est une bonne occasion de réfléchir à ce souci, voici mon analyse :

• le problème que tu sembles soulever (plus haut) est celui de la carte, mais encore faut-il le préciser : l'utilisation de la couleur sans motif ou hachures dans les différentes zones n'est pas conforme à WCAG (critère 1.4.1) : les zones, bien que délimitées par un contour ce qui est déjà bien, ne sont différenciées que par leur couleur.
• une remarque : l'information dispose cependant d'une alternative partielle dans la page (selon l'état d'avancement de l'article), via l'introduction et la section géographie. Bien que cette information ne soit pas directement présente dans le contexte immédiat de l'image (dans l'infobox), ce n'est pas négligeable.
• la solution pour une accessibilité optimale serait la modification de la carte, pour y utiliser des hachures par exemple en complément de la couleur.
• mais la faisabilité n'est pas des plus évidentes : adopter une convention accessible pour des cartes de ce type est même extrêmement complexe dès qu'on dépasse le stade de la correction d'une ou deux cartes isolées et simples.
• en outre, cela dépend de contraintes tierces : les cartes en question obéissent à des usages/conventions qu'on ne va pas aller modifier d'un claquement de doigt et la question dépasse le seul site fr.wikipedia.org puisqu'elles sont utilisées sur d'autres projets.

Donc, l'amélioration a été poussée au mieux et répond entièrement à l'objectif fixé pour ces refontes V3, qui est essentiellement le problème de la sémantique HTML (structure de tableau, de listes, etc.) et la question des alternatives d'images.

Pour l'histoire du ou des « hacks », par contre, je n'ai pas compris à quoi tu faisais allusion. Là aussi, une explication précise et rigoureuse aiderait. --Lgd (d) 14 janvier 2012 à 16:55 (CET)

Réponse du comte Ɲemoi – Côté code html : une infoboîte qui commence par une carte avec alternative générale et sa légende (qui n’apporte rien) suivies d’une section « Administration » qui reprend la légende en sens inverse (sachant que les infos principales de situation, on les a dès l’intro de l’article…), c’est un coup à donner envie de sauter l’infoboîte en entier. On a vu pire, et offrir un lien pour sauter les sections incriminées est très dangereux à suggérer sur un site collaboratif, mais je trouve pas que la solution actuelle « offre une alternative présentant la même information ».

Mais c’est du pinaillage. Je suis pour ma part beaucoup plus inquiété par la maintenance du code wiki ; le fait de laisser traîner des trucs que (presque) personne ne comprendra comme :

{{Infobox V3/Titre Bloc|class=hidden||text=Légende de la carte}}

ne me semble pas du tout une bonne idée, pour ce que ça risque fortement d’être copié à droite à gauche sans maîtrise, genre sans légende après… Moins grave, mais méritant autant d’attention (note : et c’était valable y compris pour ma version d’octobre), il en va de même pour le code pseudo-html, qui va être copié (erreurs comprises… il en restait même après ton passage ) probablement à divers endroit, avec autant d’adaptations que de risques d’évolution vers un code non accessible ; c’est pourquoi — mais cela se sait — je pense qu’il serait bien mieux de créer le modèle correspondant, afin de garder une certaine maîtrise sur les utilisations, et pouvoir rapidement passer à des trucs mieux foutus dès que l’occasion s’en présenterait (y compris pour une hypothétique équipe « cartes hachurées »), plutôt que d’avoir à courir partout à ce moment-là. Ce 14 janvier 2012 à 21:08 (CET).

On ne parle plus d'« infoboîte v3 intrinsèquement non accessible », donc ?

Sinon :

• Je vois mal le problème de maintenance avec {{Infobox V3/Titre Bloc|class=hidden|text=Légende de la carte}} ?
• « Code pseudo-html » ? Tout à l'heure, c'était « hack pseudo-html » : je suppose que tu parles de la même chose, mais je ne sais toujours pas en quoi ce serait un « hack » ?
• Sinon, un modèle à la place du code wiki HTML de la légende en dur : oui, tout à fait (d'ailleurs, il y a peut-être bien, déjà, un modèle de ce type à utiliser/améliorer il existe, mais devra être amélioré: {{Légende}}). Donc, un modèle de légende, pas un modèle de brique V3. Dans ce cas, n'hésites pas.

--Lgd (d) 14 janvier 2012 à 21:25 (CET)

Oubli: il ne faut surtout pas se mettre à ajouter des liens du type « passer ce contenu ». Ce genre de choses est réservé à des cas très spécifiques de contenus. --Lgd (d) 14 janvier 2012 à 21:31 (CET)

Réponse du comte Ɲemoi – Tant que les yeutants ont plus d’informations que les non-yeutants, « on » parlera d’« infoboîte v3 intrinsèquement non accessible ». Sinon :

• Un hack pseudo-html est un code pseudo-html suffisamment compliqué pour que le wikicontributeur moyen ait toutes les chances de ne pas le comprendre, et donc de le recopier en croyant bien faire mais en faisant n’importe quoi.
• Le problème de maintenance de {{Infobox V3/Titre Bloc|class=hidden|text=Légende de la carte}} est que peu de personnes comprennent de quoi il s’agit, et que c’est autant de chance de le voir maltraité ; avec le modèle : Légende tel qu’il est conçu, il serait préférable à mon avis d’en faire un {{titre de la légende}}.
• Mais plus globablement, il serait bien mieux que l’on n’ait pas à y penser (à cette ligne de titre de légende) ; car « que l’on ait à y penser » signifie que cette ligne va être oubliée, souvent, très souvent… Il y a diverses solutions pour cela, qui reviennent toute à dire « si vous avez besoin de faire une légende de carte, utilisez ça », ce ça en question pouvant être un paramètre particulier « légende de carte » dans le modèle : infobox V3/Image, ou un modèle qui encadre toujours {{Légende}} (qui n’affiche rien lorsqu’en infoboîte, mais qui fabrique une jolie boite-grise en dehors), un modèle supplémentaire d’infobox V3, etc. Ce 16 janvier 2012 à 21:21 (CET).

La notion d'accessibilité totale n'est pas vraiment un objectif opérationnel pertinent. Je t'invite à consulter cette conférence qui t'en dira plus sur le sujet (voir ce qui y est dit sur le niveau AAA vers 6:45). Ici, la question de l'accessibilité de l'information véhiculée par les images de contenu/d'illustration d'une manière générale est particulièrement difficile à résoudre dans Wikipédia, et ne se traitera ni localement ni à brève échéance. Le cas des cartes n'en est qu'une illustration. Faire de cette question un critère impératif pour qualifier les améliorations d'accessibilité serait une erreur aujourd'hui.

Pour un modèle générique {{Légende de carte}} : oui, mais si on parvient à gérer la présence / absence du texte masqué « Légende ... » selon qu'on est dans une infobox ou non (entre autres problèmes à résoudre). --Lgd (d) 17 janvier 2012 à 08:25 (CET)

Réponse du comte Ɲemoi – Si la notion d’accessibilité « totale » n’était pas l’objectif (ce que je conçois tout à fait, au demeurant ; et je n’ai pas besoin de voir deux guignols-malgré-eux sur scène pour cela ), pourquoi ton obstruction quant au module : Carte des Infobox v3 ? c’est le même niveau d’accessibilité que celui dont on est en train de parler : celui d’avoir une carte qu’une personne non-zeutante ne peut comprendre directement, avec l’espoir que ce sera explicité ailleurs…

Concernant le masquage de {{Légende de carte}}, c’est un problème à régler en CSS. La partie difficile me semble de réussir à faire des classes génériques, qui puissent être utilisées pour d’autres cas que celui-ci en particulier. Ma logique de code voudrait :

• que les infoboîtes portent la classe boite-grise ;
• que la classe boite-grise annule son effet lorsqu’imbriquée (permettant de gérer le modèle : Portail en pur CSS) ;
• que la légende forme une « boîte », portant la classe boite-grise, pouvant être placée dedans ou dehors des infoboîtes ;
• et qu’il y ait une classe particulière pour gérer les textes qui sont les « titres de boite-grise lorsque la boîte est indépendante », masqués à l’affichage lorsque la boîte grise est imbriquée.

Je te fais les classes approximatives si tu n’as pas compris l’idée. Ce 18 janvier 2012 à 19:09 (CET).

Le guignol va commencer par attendre des excuses. En fait non, je vais plus simplement passer à autre chose que de tenter de faire quoi que ce soit avec toi. Définitivement. --Lgd (d) 18 janvier 2012 à 19:15 (CET)

Modèles de légende améliorés ?

Suite à la suggestion de Nemoi, pour un essai de modèles de légende améliorés (mise en liste LI), voir Utilisateur:Lgd/Légendes. C'est à tester, mais ça semble jouable (laisser à mediawiki le soin de générer automatiquement le UL n'est pas très rassurant a priori, mais c'est ce qu'il fait de toute façon avec la syntaxe wiki des listes). Avis bienvenus. --Lgd (d) 15 janvier 2012 à 12:20 (CET)

Finalement, j'ai tenté le coup. --Lgd (d) 15 janvier 2012 à 20:06 (CET)

Réponse du comte Ɲemoi – Il me semble que mettre un retour à la ligne après le </li> limiterait l’obligation d’entourer de <div></div>, non ? Ce 16 janvier 2012 à 21:21 (CET).

Apparement non, au moins pas dans les cas que j'ai rencontrés (tester Utilisateur:Lgd/Légende dans Concessions étrangères de Tientsin et Championnat de RDA de football 1990-1991 par exemple). --Lgd (d) 17 janvier 2012 à 08:08 (CET)

Attributs de mise en forme HTML v. styles inline

Bonjour,
La prochaine version de mediawiki (1.19) devrait, selon ce qui est prévu aujourd'hui, modifier l'utilisation des attributs de mise en forme HTML.

Exemple-type : <div align=right> dans la source wiki :

• donne aujourd'hui <div align=right> dans le HTML final.
• donnerait avec mediawiki 1.19 <div style="text-align: right"> dans le HTML final.

C'est une excellente chose, mais qui est susceptible d'avoir un effet de bord dans quelques cas. Le passage des attributs de mise en forme aux styles inline modifie en effet la priorité du paramètre de mise en forme :

• l'attribut align=right est écrasé par les styles de common.css appliqués via des classes (ou id).
• le style="text-align: right;" écrase les styles de common.css appliqués via des classes (ou id).

Illustration:

<div align=right class="center">
Code actuel : la classe center écrase le align.

<div style="text-align:right" class="center">
Code prévu dans mediawiki 1.19 :
le style text-align:right écrase la classe center.

On pourrait donner un exemple similaire pour les articles où figure un tableau avec la classe wikitable ou sortable et des bgcolor.

Autrement-dit, des attributs de mise en forme HTML présents par erreur dans des modèles où ils n'ont actuellement aucun effet pourront parfois, une fois transformés en styles inline, modifier le rendu du code dès lors qu'une classe est présente.

Bonne incitation à se mettre dès aujourd'hui à la chasse à ces attributs au moins dans les modèles, mais aussi dans les tableaux présents directement dans les articles, pour :

• les remplacer, s'ils sont nécessaires, par un style inline
• les supprimer s'il s'agit de la situation décrite ci-dessus.

Ce qui serait encore mieux, ce serait de nettoyer enfin et pour de vrai les pages d'Aide syntaxique de toute mention de ces attributs...

--Lgd (d) 9 janvier 2012 à 22:40 (CET)

Sinon, bonne nouvelle : la réparation des liens d'accès directs « Aller à : Navigation, recherche » est enfin prévue (ces liens de navigation clavier fonctionnent tant bien que mal sur fr.wp après que les ai un peu réparés, mais c'est loin d'être optimal, et ce n'est pas du tout le cas ailleurs ) --Lgd (d) 9 janvier 2012 à 22:49 (CET)

Pour aider, il faudra un petit tableau des codes à remplacer et de ceux à utiliser dans ces corrections. Je me le note, mais si ça dit à quelqu'un de le faire ?

Le Projet:Correction syntaxique est aussi à sensibiliser là-dessus, c'est en plein dans son champ d'action. --Lgd (d) 10 janvier 2012 à 08:35 (CET)

<soliloque /> La fonctionnalité n'est apparemment pas activée sur le wiki de test 1.19. Elle ne le sera sans doute pas sur fr.wikipédia avant quelques temps, une fois faite la mise à jour (j'ignore où en est exactement son développement, mais l'idée est bien d'anticiper la chose qui va tout à fait dans le sens des règles d'accessibilité WCAG ). --Lgd (d) 15 janvier 2012 à 11:56 (CET)

Éventuelle PDD sur le rendu des appels de notes & références, avis bienvenus

Il s'agit davantage d'ergonomie que d'accessibilité à proprement parler. Mais des avis seraient bienvenus pour permette d'avancer la suggestion de formulation actuelle qui envisage le retour à l'affichage des crochets ou l'adoption de parenthèses dans ces liens.

La discussion (un peu confuse parfois) porte pour le moment sur la question de s'en tenir dans un premier temps à cette seule proposition, ou bien d'inclure déjà dans cette PDD d'éventuelles exceptions permettant au contributeur de choisir au cas par cas s'il va utiliser des parenthèses, des crochets ou rien.

Cordialement, --Lgd (d) 14 janvier 2012 à 12:33 (CET)

C'est pas plutôt à voir avec les mathématiciens et autres utilisateurs de codes spécialisés ? Car pour les autres wikipédiens cela se résumerait à un choix purement esthétique, pas forcément judicieux. Faut-il vraiment une PDD générale pour une si petite chose ? --Amicalement, Salix ( converser) 15 janvier 2012 à 12:50 (CET)

Disons que l'usage actuel (ne pas utiliser de crochets) est ancien et bien enraciné sur fr.wp et que la question touche à des susceptibilités typographiques, chose toujours très délicate ici (d'où le passage en PDD). Une si petite chose, mais de grandes passions . --Lgd (d) 15 janvier 2012 à 13:01 (CET)

Raison de plus, dans ce cas, pour accumuler un maximum d'arguments en faveur des crochets avec les projets les plus concernés. En cours de vote, ce ne sont pas deux ou trois spécialistes qui pourront faire pencher la balance si les arguments esthétiques ou littéraires pèsent déjà si lourd au regard de la majorité. --Amicalement, Salix ( converser) 15 janvier 2012 à 16:02 (CET)

Longueur des alternatives textuelles

Bonjour,
J'ai finalement formalisé une bonne pratique sur la longueur des alternatives textuelles d'images (suite à l'évolution de certains documents normatifs sur le sujet). Relectures bienvenues. Cordialement, --Lgd (d) 19 janvier 2012 à 10:55 (CET)

Monobook etc.

Bonjour, c'est volontaire que Aide:Monobook soit incompréhensible au commun des mortels ? Je voudrais indiquer un bouton bien pratique mais j'ai la sensation qu'il manque un bout de code. Pour ajouter un bouton à la toolbar, j'ai trafiqué sur ma page Commons.js les codes qu'on m'avait donnés, bêtement copiés/collés, et qui fonctionne très bien mais la façon de les organiser n'est indiquée en clair nulle part. Comment lire et utiliser les pages MediaWiki:Common.css et MediaWiki:Common.js ? Et puis entre vector.js, monobook.js et commons.js que faut-il préférer ? et pourquoi MediaWiki:Monobook.js est déplacé (sur commons.js) mais pas MediaWiki:Monobook.css ? Un courageux pour créer une page d'aide et peut-être actualiser cette page sur un monobook un peu dépassé ? --Amicalement, Salix ( converser) 26 janvier 2012 à 12:54 (CET)

Ma todolist est un peu pleine pour le moment, hélas. Allez... Un autre courageux ? Cordialement, --Lgd (d) 28 janvier 2012 à 11:48 (CET)

Ah, si on avait une page d'aide .js et .css pour les nuls... (soupir) --Amicalement, Salix ( converser) 28 janvier 2012 à 19:16 (CET)

Texte et traduction en vis-à-vis

Bonjour, une question bête : quelle est la façon la plus accessible de mettre un texte et sa traduction en vis-à-vis ? Est-ce qu'un tableau minimal du style

{|
| Texte
| Traduction
|}

est approprié ? – Swa cwæð Ælfgar (d) 26 janvier 2012 à 20:23 (CET)

Le tableau convient. Il peut être comme ci-dessus (simple tableau de mise en forme inoffensif dans ce cas), soit, éventuellement, sous la forme d'un tableau de données explicite :

{|
|+ Versions originale et française de la charte klingon
|- 
! scope=col | Texte original en klingon
! scope=col | Traduction
|-
| Texte
| Traduction
|}

Il faut en revanche éviter les mélanges entre les deux types de tableaux (retirer le titre ou remplacer les ! scope=col par de simples | dans le tableau de données). --Lgd (d) 27 janvier 2012 à 14:13 (CET)

Merci à Od1n pour la correction de mon énorme bourde de syntaxe dans l'exemple ci-dessus . --Lgd (d) 28 janvier 2012 à 11:45 (CET)

Confusions, homonymies et autres

Bonsoir. Je propose de passer les petite icônes des modèles du type {{homonymie}}, {{confusion}}, {{homophonie}} dans la feuille de style CSS, comme cela a été fait avec les bandeaux de section. Pour cela, je pense qu’il faudrait :

• Ajouter dans la feuille de style css commune les classes .homonymie, .homophonie, .confusion, parmi les

.indentation, /* pas d’image correspondante */ .loupe, /* loupe, voir le [[modèle : Article détaillé]] */ .general, /* flèche pour le [[modèle : Article principal]] */ .accessibilite, /* symbole handicap, pour le [[modèle : Encart]] */ .incomplet, /* cône de chantier pour le [[modèle : …]] */ .sources, /* livre ouvert du [[modèle : Section à sourcer]] */ .important, /* triangle rouge : mise en garde */ .en-travaux, /* triangle jaune : en construction */ .wikispecies, .metawiki, .wikiversity, .wikipedia, .wikibooks, .wikinews, .wikiquote, .wikisource, .commons, .wikimedia, .wiktionary{} de la partie bandeaux ;

• Rajouter le code .hr {border-bottom: 1px solid gray;} pour gérer les bordures optionnelles en bas de ces modèles
• Rajouter les classes

.homonymie { background-image:url("//upload.wikimedia.org/wikipedia/commons/thumb/3/3e/Disambig_colour.svg/17px-Disambig_colour.svg.png"); background-position:1px 0;} .confusion { background-image:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/6f/Confusion_colour.svg/17px-Confusion_colour.svg.png"); background-position:1px 0;} .homophonie { background-image:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/63/Homoph_colour.svg/17px-Homoph_colour.svg.png"); background-position:1px 0;}

• Et enfin modifier tous les modèles affichant une icône d’homonymie en conséquent, à savoir selon le schéma <div class="(homonymie|confusion|homophonie) {{#if: {{{nohr}}}||hr}}">Texte</div>. On en profiterait pour supprimer les {{{1}}} qui ne servent à rien et sont souvent dupliqués sur la même page.

Qu’en pensez-vous ?

Cordialement --Pic-Sou 29 janvier 2012 à 22:31 (CET)

Ces icônes ne posent actuellement pas de problème d'accessibilité : ce sont des liens vers l'aide, avec l'alternative textuelle appropriée. Ce lien est présent également sous forme textuelle dans une partie des usages d'{{Homonymie}}, mais pas dans tous et pas dans {{Voir homophones}} ni {{Confusion}}.

La modification proposée reviendrait donc à supprimer le lien d'aide. Bien qu'il ne soit pas présent sous une forme très explicite (beaucoup d'utilisateurs ignorent sans doute sa présence), sa suppression ne va pas de soi. Donc, à mon avis, ce n'est pas à décider ici.

Remarque : cela fait très longtemps que je souhaiterais voir systématiquement utilisée une icône d'aide unique et explicite dans tous les cas où figure un renvoi à une page d'aide, que ce soit depuis un modèle, depuis l'interface liée aux messages systèmes, etc. C'est encore un de ces chantiers qui attend d'avoir le courage de s'y attaquer . Cordialement, --Lgd (d) 31 janvier 2012 à 09:29 (CET)

Pourtant, c’est plus un truc décoratif qui ne devrait pas être visible dans un navigateur texte ou audible lors d’une synthèse vocale qu’une image nécessaire à la compréhension du contenu. Et, oui, j’ignorais que ce lien existait. Peut-être vaudrait-il mieux que le lien vers la page Aide:Homonymie soit sur le mot « homonyme » que sur l’icône ? Cordialement --Pic-Sou 31 janvier 2012 à 10:20 (CET)

Il me semble que le terme « homonyme » (ou équivalent) n'est pas présent dans toutes les déclinaisons de ces modèles et qu'il n'y a donc pas toujours de quoi fournir un lien textuel.

Sinon, pour préciser un autre point plus général : quand une image est purement décorative (pas de lien, pas d'info etc.), elle peut être gérée soit en image HTML avec un alt vide, soit en image CSS avec un résultat identique du point de vue accessibilité. C'est pour d'autres raisons (performances, industrialisation du code, etc.) qu'on la passe souvent en image CSS. Mais ce n'est pas toujours nécessaire ni profitable. C'est un peu compliqué et à voir à chaque fois selon le contexte. Ici, si ce n'était pas des images-liens, ce serait en effet profitable. Cordialement, --Lgd (d) 31 janvier 2012 à 12:29 (CET)

OK, merci pour les informations ! Cordialement --Pic-Sou 31 janvier 2012 à 19:35 (CET)

Réponse du comte Ɲemoi – J’avais regardé à faire ça, mais arrêté, n’ayant pas trouvé de solution propre pour gérer tous les problèmes. Le lien d’aide cité par Lgd est le principal obstacle ; il faut préciser que certains « liens d’aide » n’aident pas du tout, comme celui sur le modèle : Autre qui envoie vers l’aide : Redirection… Un second est la complexification du code html : pour quel intérêt ? quelle logique sous-jacente ? je n’aime pas trop ça. Bref, c’est l’un des trucs qui traîne depuis assez longtemps dans mes tests, mais je n’ai pas de solution propre qui évite d’ouvrir plein de discussions partout. Ce 1 février 2012 à 01:28 (CET).

Refonte des palettes et boîtes déroulantes, faire une première phase de tests rapides

Bonjour,
Les modèles de palettes de navigation et de boîtes déroulantes posent depuis longtemps des problèmes de sémantique, d'accessibilité, de scripts redondants etc. Je me suis un peu attaqué au souci en tirant parti de ce qui était à présent possible via la dernière mise à jour de mediawiki (1.18).

Je n'en suis pas encore au stade où il s'agit d'une proposition de refonte finalisée : différents modèles de variantes ne sont pas couverts, le résultat des palettes n'est pas encore géré dans les vieilles versions d'Internet Explorer (6 et 7), les boîtes déroulantes sont pour le moment en version minimale, les options de mises en couleur de tout cela sont réduites au minimum et il reste d'autres bricoles à traiter.

Mais des essais en prévisualisation dans diverses palettes de navigation seraient nécessaires à ce premier stade, surtout si vous avez en tête des palettes de navigation un peu spéciales (je laisse de côté le test des autres boîtes déroulantes pour le moment).

Si vous voulez bien vous prêter au jeu (en sachant que vous allez certainement rencontrer de la casse, le but est justement de la détecter), voici les indications nécessaires pour tester :

1. ajouter au tout début du common.css personnel la ligne:

   @import "//fr.wikipedia.org/w/index.php?title=Utilisateur:Lgd/Palettes/palettes_V2.css&action=raw&ctype=text/css";

2. ajouter au tout début du common.js personnel la ligne:

   importScript('Utilisateur:Lgd/Palettes/palettes V2.js');

3. actualiser le cache de votre navigateur ;
4. Pour tester une palette de navigation en prévisualisation uniquement, aller sur la page du modèle de palette concerné (par exemple Modèle:Palette GP Formule 1 2011) et remplacer la ligne :

   {{Méta palette de navigation

   par

   {{Utilisateur:Lgd/Palettes/Méta palette de navigation V2

   puis cliquer sur « prévisualiser ».

Le rendu que vous obtiendrez n'est pas le rendu final après la mise à jour définitive des palettes, mais un rendu de transition entre une étape de mise à jour automatique et la finalisation manuelle dans chaque palette (les explication sont dans Utilisateur:Lgd/Palettes/Méta palette de navigation V2 pour les curieux). Le besoin est de vérifier que ce rendu transitoire n'est pas cassé de manière problématique, même s'il peut comporter des imperfections (par exemple, perte d'un alignement, etc.)

Dans vos retours, pensez à bien indiquer quel est le modèle de palette et si besoin votre navigateur, sa version et votre système d'exploitation (ne faites pas de retour pour Internet Explorer 6 et 7, ce n'est pas prêt pour ceux-ci).

J'espère avoir expliqué ça de façon à peu près humaine, mais sinon, passez simplement à autre chose .

Cordialement, --Lgd (d) 31 janvier 2012 à 12:23 (CET)

bonjour !

Voila mon retour : Chrome 16.0.912.77 m sous Vista et sur la palette Modèle:Palette GP Formule 1 2011. Le v pour voir la palette est centré sur le trait d'encadrement de la palette sinon tout le reste me semble bien rendu et bien passé. (je sais pas si je t'aide là ...) --TaraO (d) 6 février 2012 à 16:47 (CET)

Même chose sur Modèle:Palette Penguins de Pittsburgh mais avec en plus, la perte de l'alignement du texte à gauche. --TaraO (d) 6 février 2012 à 16:50 (CET)

Avec chrome sous Ouindose XP (pourquoi changer un truc qui marche?) je n'ai rien noté d'étrange en testant plein de palettes au hasard. Sauf pas pu voir ce que ça donne pour Modèle:Palette Patrimoine mondial en France et trouvé un record (?) de longueur : Modèle:Palette Cathédrales en France. --Amicalement, Salix ( converser) 6 février 2012 à 22:11 (CET)

Firefox sous windows 7 : Pas problème particulier à part celui de la perte d'alignement à gauche souligné par TaraO (Modèle:Palette Blackhawks de Chicago par exemple). Pour le v centré sur le trait d'encadrement, il semble que ce soit le cas pour tous au vu de Utilisateur:Lgd/Palettes/Méta palette de navigation V2. --'toff ^[discut.] 7 février 2012 à 04:41 (CET)

Edit : à priori, l'alignement à gauche sera possible avec class=left. Question : faudra-t-il à chaque liste rajouter le sous-modèle liste pour l'alignement ? --'toff ^[discut.] 7 février 2012 à 04:49 (CET)

Merci pour vos retours. Le souci d'alignement de la {{Tnavbar}} (que je n'ai pas dans mon rendu) est sans doute dû à une petite rencontre inattendue entre les styles de la palette et mes autres styles personnels, ce qui fait que j'aurai pu longtemps passer à côté . Je vais arranger ça.

Pour Modèle:Palette Patrimoine mondial en France : c'est normal, c'est une de ces rares palettes à utiliser un modèle intermédiaire, Modèle:Méta palette Patrimoine mondial. Ce qui me fait penser qu'il faudra les recenser...

@'toff : Cela va dépendre de ce qui se décidera quant à la conservation ou non des paramètres de mise en forme actuels des palettes (stylegroupe, styleliste, etc). Dans tous les cas, le passage systématique au modèle de liste dans chaque palette constituerait une seconde phase (longue et manuelle) d'amélioration. Vous pouvez d'ailleurs déjà aider en utilisant systématiquement l'actuel {{Liste éléments}} dans les palettes. Cordialement, --Lgd (d) 7 février 2012 à 05:33 (CET)

Si je vois bien la facilité de passer de {{Liste éléments}} à un autre sous-modèle, je ne suis pas persuadé de l'intérêt d'un tel sous-modèle quand il est si facile et moins complexe de coder en dur ? --'toff ^[discut.] 7 février 2012 à 06:54 (CET)

Si par « coder en dur » tu veux dire les multiples variantes de fausses listes actuelles à base de caractères typos, l'intérêt est justement de les remplacer par de véritables listes structurelles . Sinon, c'est que j'ai mal compris la question ? Cordialement, --Lgd (d) 7 février 2012 à 06:59 (CET)

Au temps pour moi, je viens effectivement de me rendre compte de ma profonde bêtise... T'es pas à l'aube de laisser l'atelier à des blaireaux comme moi Yapukafokon ! J'ai bon ? --'toff ^[discut.] 7 février 2012 à 07:20 (CET)

PS : Sur ce coup là, t'as le droit de taper même sur la tête ! --'toff ^[discut.] 7 février 2012 à 07:20 (CET)

Rien de spécial pour moi (pas de comportement non désiré), mais je pense qu’il faudrait par défaut que les textes soient alignés à gauche, et que les différents sous-groupes devraient être mieux distingués (en gros, sur Utilisateur:Pic-Sou/Brouillon 3, qu’il y ait une séparation visible entre les première, deuxième et troisième ligne). Cordialement --Pic-Sou 7 février 2012 à 09:19 (CET)

C'est le cas une fois la seconde phase effectuée, c'est à dire une fois le modèle de liste utilisé. Il est normal que ce ne soit pas visible dans ces tests, donc. --Lgd (d) 7 février 2012 à 09:33 (CET)

Titres dans des tableaux

Que penser de ce type de tableaux ?

Ltrl G, le 31 janvier 2012 à 15:59 (CET)

C'est un cas typique de tableau complexe où des en-têtes de colonne ne s'appliquent qu'à certaines lignes, ingérable avec scope. A éclater en autant de tableaux simples successifs qu'il y a de blocs (les en-têtes actuels en colspan devenant les titres de tableaux). L'autre solution disponible est AMHA à éviter à tout prix dans les articles vu la complexité et la fragilité de sa syntaxe. Cordialement, --Lgd (d) 31 janvier 2012 à 23:13 (CET)

Un truc comme ça ?

=== Information ===
{| class="wikitable alternance"
|+'''1xx'''
|-
! scope="col" | Code
! scope="col" | Message
! scope="col" | Signification
|-
| 100 || {{lang|en|''Continue''}} || Attente de la suite de la requête
|-
| 101 || {{lang|en|''Switching Protocols''}} || Acceptation du changement de protocole
|-
| 102 || {{lang|en|''Processing''}} || [[WebDAV]] : Traitement en cours (évite que le client dépasse le temps d’attente limite).
|-
| 118 || {{lang|en|''Connection timed out''}} || Délai imparti à l'opération dépassé
|}

=== Succès ===
{| class="wikitable alternance"
|+'''2xx'''
|-
! scope="col" | Code
! scope="col" | Message
! scope="col" | Signification
|-
| 200 || ''OK'' || Requête traitée avec succès
|-
| 201 || {{lang|en|''Created''}} || Requête traitée avec succès avec création d’un document
|-
| 202 || {{lang|en|''Accepted''}} || Requête traitée mais sans garantie de résultat
|-
| 203 || {{lang|en|''Non-Authoritative Information''}} || Information retournée mais générée par une source non certifiée
|}

ou, pour les titres, peut-être inverser : === 2xx === et |+'''Succès''' ? --'toff ^[discut.] 1 février 2012 à 05:20 (CET)

Fait selon la solution de 'toff ?

@'toff : sur un wikitable, il est inutile de mettre les caption en gras.

Ltrl G, le 17 février 2012 à 23:46 (CET)

C'est (à priori) vrai maintenant. Mais il y a quelques temps, ce n'était pas le cas sous tous les navigateurs. Une vieille habitude --'toff ^[discut.] 18 février 2012 à 00:32 (CET)

Tableau construit avec le modèle légende

Bonjour,
J'ai fait le tableau suivant. Un utilisateur l'a modifié par ce tableau construit avec le modèle {{légende}}. J'avoue que je trouve que le 2^e tableau à l'avantage de ne pas prendre une espace beaucoup trop grand dans l'article, mais je me demandais si c'était correct au niveau accessibilité. Merci! — Riba ^(discuter) 6 février 2012 à 16:39 (CET)

C'est pratiquement indifférent (le second étant une liste en un seul bloc et non un tableau, malgré ce que suggère le rendu). Cordialement, --Lgd (d) 6 février 2012 à 16:46 (CET)

Images dans un tableau qui apportent du sens

Je tombe aujourd'hui sur un article de sport qui utilise dans un tableau un modèle pour mettre une image de croix. La présence ou non de ce "truc" apporte une information utile, mais est-ce que en l'état, ces tableaux sont "accessibles" ?
Comment les améliorer si besoin ?
(pas plus de 50 en main pour l'instant)
Merci de vos avis, --MGuf (d) 7 février 2012 à 21:18 (CET)

Maintenant, ça devrait aller mieux. --Pic-Sou 7 février 2012 à 21:25 (CET)

Si jeune mabuse, ta modif ne change rien, car il y avait déjà une syntaxe "non" dans le modèle, en "légende".

Ma question va plus loin : un lecteur normal peut (peut-être) le sens d'avoir cette croix dans une case ou pas, mais qu'en est-il dans la vraie accessibilité, puis que le sens de la croix n'est pas "non", mais "cette épreuve n'existait pas à cette époque". On va améliorer, notamment grâce à une légende, mais je souhaite un avis autorisé et argumenté de spécialistes. Merci. --MGuf (d) 7 février 2012 à 21:36 (CET)

@Pic-sou : il y a en fait deux syntaxes possibles pour l'alternative d'image : explicite sous la forme [[Fichier:Exemple.jpg|alt=texte de l'alternative]] et implicite sous la forme [[Fichier:Exemple.jpg|texte de l'alternative]]. Les deux produisent le même attribut alt de l'image. La seconde produit en plus le tooltip (bulle d'aide) au survol du lien. --Lgd (d) 8 février 2012 à 05:28 (CET)

Une légende sera en effet nécessaire d'une manière générale. Si elle a plusieurs entrées, le modèle {{Légende}} peut éventuellement servir. Par ailleurs, j'ai corrigé le modèle {{Non g}} pour qu'il permettre de saisir l'alternative de son choix. Il faudrait donc, dans ces articles, corriger sous la forme {{Non g||alt=épreuve inexistante à cette date}} (attention au double pipe). --Lgd (d) 8 février 2012 à 05:25 (CET)

Couleurs d'un portail.

Bonjour,
Pouvez-vous me dire si les couleurs du portail:Calvados, correspondent au normes d'accessibilité ?
Merci,--AM 23 (d) 10 février 2012 à 19:52 (CET)

Colour Contrast Analyzer (utilitaire gratuit, téléchargeable, sans installation) donne :

Pour le texte noir sur le fond : ok

Pour le texte bleu (liens) sur le fond : pas bon (mais je tempère : je suis deutéranope et je n'ai pas de problème avec ce portail)

Pour le texte noir sur fond bleu dans les titres : pas bon (mais comme au-dessus, c'est pas rédhibitoire àmha)

Pour le texte bleu (liens et bouton [modifier]) sur fond bleu : pas bon (et àmha, améliorable : je pense qu'il faudrait éclaircir le bleu)

Ce n'est qu'un avis perso et celui d'un utilitaire. Voir avec des spécialistes de la question. --'toff ^[discut.] 11 février 2012 à 00:18 (CET)

Bonjour AM 23. A vue de nez les bandeaux de titre ne sont pas top, surtout quand il y a un lien bleu (ferme à demi les yeux et vois ce que ça donne ou recule de ton écran de quelques mètres). Quoi qu'il en soit, un Portail:Calvados ça s'arrose ! --Amicalement, Salix ( converser) 11 février 2012 à 01:04 (CET)

Dans un autre domaine, les listes non structurées dont les élément sont séparés par des ~ (qui seront amenées à prendre de l’ampleur, j’imagine), c’est pas top. Je ne parle pas des couleurs, parce qu’avec mes préférences, je cherche un peu les ennuis de lisibilité… Ltrl G, le 17 février 2012 à 22:57 (CET)

Pour ce qui est des couleurs, le fond bleu #2288CC pose un gros problème de contraste avec le bleu des liens. Les autres combinaisons de couleur ne posent pas de problème de contraste notable.

Pour les listes, vous devriez en effet regarder du côté du modèle:Liste éléments : il ne produit pas encore actuellement le code qui conviendrait, mais son utilisation permettra de régler automatiquement le problème lors de sa prochaine mise à jour. Cordialement, --Lgd (d) 18 février 2012 à 07:36 (CET)

Modèle de liste en ligne

Plutôt que d'utiliser un modèle comme Liste éléments, dont la définition est à la fois limitative (pourquoi à 155 éléments ?) et lourde (combien de tests à chaque emploi ?), peut-on imaginer définir une classe listeligne à l'intérieur de laquelle les listes non ordonnées seraient affichées en ligne ? Du point de vue utilisateur, on écrirait en code wiki

{{liste en ligne|
* des choses
* et d'autres}}

Dans le modèle « Liste en ligne », on placerait le contenu dans un <span class="listeligne"> et dans le Commons.css, on définirait en inline les tags .listeligne > ul. Non ? Ambigraphe, le 18 février 2012 à 11:01 (CET)

C'est justement le rôle du modèle {{Liste éléments}}, qui le fait le fera une fois mis à jour de manière plus robuste que ce que ferait le type de modèle que tu proposes (jongler dans un modèle avec un mélange de syntaxe wiki HTML - ul - et de syntaxe wiki wiki - * - pour les listes réveille parfois de vieilles fragilités du parseur). Il ne pose pas par ailleurs de problèmes de performances. Cordialement, --Lgd (d) 18 février 2012 à 11:42 (CET)

Ambigraphe n’a pas proposé un tel mélange, il me semble : il propose d’englober la liste dans un <span> dans un <div> avec une classe particulière qui permettrait de rendre inline la ou les listes qui se trouvent à l’intérieur en appliquant via common.css cette propriété sur les <ul> du code HTML. Ltrl G, le 18 février 2012 à 12:11 (CET)

Utiliser un conteneur de type <div class="inline_list">...</div> autour de la liste cassera l'imbrication de listes (le problème se pose déjà avec les listes des références). C'est pourquoi la classe doit être appliquée sous forme d'un <ul class="inline_list">...</ul> dans le modèle. Cordialement, --Lgd (d) 18 février 2012 à 12:18 (CET)

OK, j'ai vu le problème. L'interprétation de l'astérisque en début de ligne est plus compliquée que je ne me l'imaginais. Merci pour les réponses, je reviendrai quand j'aurais de meilleures idées. Ambigraphe, le 18 février 2012 à 14:03 (CET)

Codes CSS pour les mathématiques

J'ai deux questions à peu près indépendantes mais qui concernent toutes deux le code CSS et le projet Mathématiques.

1. J'ai créé pour certains portails de mathématiques une sous-page /Style (telle que « Portail:Mathématiques/Style ») qui définit notamment les couleurs à employer pour le portail. Est-ce satisfaisant d'un point de vue accessibilité ?
2. Certains contributeurs souhaitent voir s'afficher les théorèmes, propriétés et définitions dans les articles dans des cadres colorés. Il n'y a pas de consensus à ce sujet, voire une opposition du gros des troupes, mais je pense qu'on pourrait autoriser ceux que ça intéresse de redéfinir des attributs de style dans leur propre css. Pour cela, il faudrait peut-être (je suis néophyte sur le sujet) que ces classes soient définies globalement. Si c'est bien le cas, comment faire ?

Merci d'avance, Ambigraphe, le 17 février 2012 à 14:40 (CET)

Pour le deuxième point, cela pourrait rejoindre àmha l’idée soulevée un peu plus haut d’un modèle encadrant les formules pour les indenter. Ltrl G, le 17 février 2012 à 23:20 (CET)

Bonjour,

1. Cela n'a pas d'impact en tant que tel du point de vue accessibilité. Après, tout va dépendre des styles en questions, le risque principal se situant du côté d'éventuels choix de couleurs d'arrière-plan. Pour le moment, pas de souci, donc.
2. Pour que des modèles soient plus aisément personnalisables, il faut en effet les doter d'une classe, mais sans que cela nécessite forcément de définir leur détail dans Mediawiki:Common.css. Par exemple, un modèle du type :

   <div class="foo" style="background: yellow">...</div>

   Sera personnalisable via le common.css personnel avec quelque-chose comme

   .foo {background: pink !important;}

   Cordialement, --Lgd (d) 18 février 2012 à 07:36 (CET)

Merci pour ces réponses.

En ce qui concerne le style du portail, idéalement j'aimerais utiliser une sous-page « Portail:nom_du_portail/Style.css » qui serait appelée automatiquement par le serveur (comme la feuille de style personnalisée) pour chaque portail, ou mettre les classes des cases du tableau (bordure et espacement) dans le commons.css.

Pour les indentations de formules, je pense que le mieux est d'utiliser une syntaxe du genre :

{{bloc|<math>\int_a^b\frac{\mathrm d x}{x} = \ln\left(\frac{a}{b}\right)</math>}}

Ambigraphe, le 18 février 2012 à 09:30 (CET)

Utiliser une sous-page d’un portail pour une feuille de style css n’est pas une bonne idée. Un vandale peux très facilement s’amuser à blanchir artificiellement toute les pages l’utilisant via un petit body { display:none; } ou quelque chose du genre. Il faut donc qu'elle soit au moins semi-protégé. De plus, l’espace Mediawiki: est là pour cela. Tpt (d) 18 février 2012 à 09:57 (CET)

Ah, je n'avais compris le rôle de la sous-page de portail. Indépendamment des questions de vandalisme, cela me semble en effet à éviter car disperser les styles dans divers espaces compliquerait considérablement leur suivi et leur maintenance. D'autre part, c'est à vérifier, mais il ne me semble pas possible d'obtenir l'export au format css d'une page de ce type. Enfin, plus généralement, il n'existe pas actuellement de mécanisme d'inclusion de CSS conditionnelles dans mediawiki (selon la manière de mettre en oeuvre ton idée, la css ne sera pas appelée ou bien elle sera quelle que soit la page comme si les styles étaient dans Common.css, donc sans aucun avantage).

C'est un manque en effet, mais mieux vaut éviter de bricoler : ce serait une évolution de mediawiki à gérer nativement. Cordialement, --Lgd (d) 18 février 2012 à 11:56 (CET)

L'utilisation d'une page « Mediawiki:Projet:Mathématiques.css » au lieu de « Projet:Mathématiques/Style.css » me conviendrait presque aussi bien, à ceci près que faire des essais dans l'espace Mediawiki est moins aisé pour moi que dans l'espace Portail.

Quant au mécanisme d'inclusion conditionnelle de CSS, il est déjà appliqué pour la personnalisation CSS, non ? (Ou bien je n'ai rien compris au film, hypothèse vraisemblable). Ambigraphe, le 18 février 2012 à 14:08 (CET)

Il n'y a aucune inclusion conditionnelle en fonction de l'espace de nom de l'article ou de la page auquel s'appliquerait la css en question (pour les CSS éditables, c'est à dire en dehors de celles du noyau et des extensions). Une CSS personnelle est systématiquement chargée quelque-soit la page consultée, dès lors que l'utilisateur l'a créée.

D'autre part, externaliser les styles d'un portail dans quelque-chose comme Mediawiki:Common.css/Mathématiques.css n'aura qu'un intérêt très limité, surtout si tu n'es pas admin et que tu ne peux pas modifier une page dans cet espace : il faut alors, pour que cette CSS soit prise en compte, recourir à un @import dans Mediawiki:Common.css, ce qui est pénalisant en terme de performances, pour le coup. Je l'ai fait récemment avec MediaWiki:Common.css/taxobox v3.css sur laquelle travaille Hexasoft afin de lui simplifier la mise au point des styles de taxobox V3, mais ce sera un @import temporaire, très probablement (voir ici).

Il est peut-être possible que mediawiki 1.19 change un peu la donne, mais c'est à voir (Je n'ai pas regardé en détail ce qui est annoncé sur ce sujet, ce n'est pas très clair). Cordialement, --Lgd (d) 18 février 2012 à 16:02 (CET)

Merci pour ces précisions. La raison de mon acharnement est la définition du style pour toutes les cellules d'un tableau. Si je pouvais définir ce style dès le haut de table, ça m'irait, mais je n'ai pas trouvé comment faire. Du coup, la solution utilisée actuellement consiste à définir ce style à chaque cellule du tableau, ce qui est un peu laborieux. Pour gérer ce style globalement, j'ai eu recours à la création d'une page de style incluse à chaque cellule. Mais je n'ai pas l'impression que ce soit très propre. Ambigraphe, le 18 février 2012 à 20:12 (CET)

En revanche, je n'ai toujours pas compris pourquoi d'une part on peut « systématiquement [charger une page nom_utilisateur/common.css] dès lors que l'utilisateur l'a créée » et d'autre part on ne peut pas systématiquement charger une page nom_du_portail/style.css dès lors qu'elle est créée. Ambigraphe, le 19 février 2012 à 13:33 (CET)

As-tu une page précise pour le tableau ? (le cas échéant sur ma pdd, on déborde un peu du champ de l'atelier accessibilité).

Pour la seconde question : simplement parce que le mécanisme n'existe pas côté mediaWiki. Il existe un mécanisme qui gère le fait que l'utilisateur soit connecté et la prise en compte de ses css/js personnels, ce qui est très simple. Il n'existe pas actuellement de mécanisme mediaWiki gérant le fait que la page X est affichée quelque-part et qu'il existe un(e) css/js Z qui y serait associé(e) (et encore faudrait-il définir cette association de manière exploitable par le CMS). Ce sont fonctionnellement deux choses très différentes. Cordialement, --Lgd (d) 19 février 2012 à 13:55 (CET)

En raison du caractère formater et automatique de tout ce qui n'est pas "contenu" dans les pages :

Les feuilles de style css sont chargé dans l'ordinateur client par un ligne situé au début du code de la page a afficher.

Sur un site personnel que l'on bidouille soit même page après page, il est donc assez facile de décider qu'une page va comporter des feuilles de style supplémentaires. Mais sur un site comme wikipédia, où la création de page peut se faire à la volée, il est important de garder une interface toujours similaire et, donc, que toute la partie concernant notamment les feuilles de style soit automatisée.

Par conséquent, nous ne pouvons pas décider d'ajouter une feuille de style sur une page en particulier et il n'est pas envisageable non plus de la mettre dans le code automatique, ce qui forcerait sont chargement même quand elle n'est pas nécessaire et donc un diminution conséquente et inutile des capacités. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 19 février 2012 à 13:51 (CET)

Non, ça ne pose pas de problèmes de cet ordre (l'association de CSS à des pages spécifiques via un CMS est une chose courante, que ce soit sur de petits sites personnels ou sur des sites plus complexes que Wikipédia). En revanche, le besoin n'a pas été identifié sur Wikipédia pour le moment (cela viendra sans doute). --Lgd (d) 19 février 2012 à 13:58 (CET)

Lang dans poem

Bonjour,

Si on veut de l'italique entre des balises <poem>, il faut répéter les deux apostrophes au début de chaque ligne. Faut-il faire de même avec {{lang}} ?

<poem>''{{lang|ang|Ða se eorl ongan for his ofermode}}
''{{lang|ang|alyfan landes to fela laþere ðeode}}.</poem>

Ou bien est-ce qu'il suffit de l'ouvrir au début et de le fermer à la fin ?

<poem>''{{lang|ang|Ða se eorl ongan for his ofermode
''alyfan landes to fela laþere ðeode}}.</poem>

– Swa cwæð Ælfgar (d) 17 février 2012 à 23:00 (CET)

Un petit test avec le gadget accessibilité suffit pour dire que la syntaxe « simple » fonctionne même si le code produit (en prévisualisation) est étonnant [édit] est bien complexe ! cf ci-dessous pour une autre solution plus simple — pour la langue comme pour l’italique. Ltrl G, le 17 février 2012 à 23:07 (CET)

Une solution plus simple (pour le code produit) :

''<poem lang="ang" xml:lang="ang">
Ða se eorl ongan for his ofermode
alyfan landes to fela laþere ðeode.
</poem>''

Peut-être un modèle ({{poème étranger|ang|…}} ?) pour le <poem lang="ang" xml:lang="ang"> ?

Ltrl G, le 17 février 2012 à 23:26 (CET)

Juste une précision: il est inutile d'écrire le xml:lang : il est automatiquement produit par mediaWiki. Cordialement, --Lgd (d) 18 février 2012 à 07:36 (CET)

Effectivement, mais comme j’étais parti du code HTML, je ne l’avais pas remarqué… Ltrl G, le 18 février 2012 à 11:39 (CET)

En fait, la syntaxe suivante est largement suffisante (je suis bête de ne pas y avoir pensé alors qu’il me semble l’avoir déja utilisée) :

''{{lang|ang|<poem>
Ða se eorl ongan for his ofermode
alyfan landes to fela laþere ðeode.
</poem>}}''

Ltrl G, le 18 février 2012 à 11:50 (CET)

Adopté. Merci ! – Swa cwæð Ælfgar (d) 18 février 2012 à 16:30 (CET)

J’ai essayé de créer {{poem}}, mais ça déconne… --Pic-Sou 18 février 2012 à 17:16 (CET)

Il faut utiliser {{#tag:}}. --Lgd (d) 18 février 2012 à 17:26 (CET)

Rhaaah le gland ! Le pire, c'est que je devais le savoir… Bon, tout est corrigé, donc maintenant on peut même faire :

{{poem|Ða se eorl ongan for his ofermode
alyfan landes to fela laþere ðeode.|ang}}

Cordialement --Pic-Sou 18 février 2012 à 17:44 (CET)

Je ne connaissais pas {{#tag:}}, ça a l'air intéressant. Mais est-ce qu'on n'aurait pas plutôt pu modifier le modèle {{Vers}} plutôt que de créer {{poem}} (dont la dénomination laisse un peu à désirer) ? Ambigraphe, le 18 février 2012 à 20:15 (CET)

Insérer un lien dans un aricle

Bonjour,

Je voulais modifier un article et y ajouter un liens mais je ne l'ai pas publié car je n'ai pas réussi à ajouter un lien. Donc ma question aujourd'hui est comment ajouter un lien dans un article ? Voilà merci aurevoir !

--Chaussettes12 (d) 29 février 2012 à 12:12 (CET)

Il existe plusieurs types de liens : Aide:Liens. JackPotte ($♠) 29 février 2012 à 13:16 (CET)

Au-delà des apparences, le compte qui a créé cette section relève a priori plus du vandalisme (peut-être gentil et innocent, genre ado) qu'autre chose.

Dans tous les cas, ce n'est pas le lieu. Pour les questions de cet ordre, aller sur WP:Questions techniques. --Lgd (d) 29 février 2012 à 13:20 (CET)

Balises math

Bonjour, quelle tuile ! depuis hier soir tous les symboles "ordinaires" entre balises maths (typiquement : $a$), qui truffent le corps du texte des articles de maths, sont "forcés en png" (je crois que c'est comme ça qu'on dit), en tous cas : sont trop gros. Est-ce temporaire ou définitif ? (svp, ne me répondez pas qu'il suffit de modifier mes préférences ou css ou je ne sais quoi, réservé aux initiés) Anne (d) 1 mars 2012 à 09:14 (CET)

Je vais tâcher de regarder plus en détail dans la journée pour le souci de taille des images, mais c'est lié en effet à la mise à jour de mediawiki (voir le bistro du jour). A priori, c'est durable (rien n'est définitif en la matière ) et, désolé, cela entraîne que choisir une autre option nécessite de cocher une case dans les préférences du compte (ce qui n'est tout de même pas vraiment un truc d'initié, on a beaucoup plus barbare dans le genre, hélas : en fait, le système des options à cocher dans les préférences du compte sont ce que Wikipédia ou n'importe quel autre site pourrait offrir de moins geek ). Cordialement, --Lgd (d) 1 mars 2012 à 09:29 (CET)

Merci, mais pas trouvé quelle case il fallait cocher dans les préférences pour retrouver l'apparence que ça avait « avant ». Oui, je sais, je suis niaise, mais probablement pas la seule, et puis faut penser aux lecteurs lambda, qui n'ont même pas de compte. Anne (d) 1 mars 2012 à 10:18 (CET)

C'est en effet absolument épouvantable. Quel est le cheminement de prise de telle décision ? Y a-t-il eu consultation d'auteurs d'articles, au moins sur la Wikipédia en anglais ? La réponse vis-à-vis des préférences du compte ne me satisfait pas : je ne me préoccupe pas de la question comme lecteur mais comme auteur d'articles, et ne puis cocher les préférences des comptes de mes lecteurs (particulièrement de ceux, nombreux, qui lisent non connectés). Touriste (d) 3 mars 2012 à 11:49 (CET)

Le choix semble désormais réduit à image png (défaut) ou laisser code tex (cf Préférences/Apparence/Rendu des maths)

Cantons-de-l'Est nous indique dans RAW 40 que « Le rendu de LaTeX en MathML étant trop primaire, cette option est abandonnée. Parmi les deux options qui restent (voir dans le bas de cette page), une seule donne un résultat intéressant pour les navigateurs qui montrent les images - « Toujours produire une image PNG » -, l'autre est pour les navigateurs en mode texte (Lynx par exemple). » (il serait intéressant de trouver le texte original pour voir la raison de l’abandon de HTML simple). Je crois qu’il faudra donc faire avec les images png…

Ltrl G, le 3 mars 2012 à 12:02 (CET)

Réponse partielle à ma question : des échanges sur le Bistro des matheux anglophones me renvoie à [2], une "Request for Comments" sur le site de mediawiki (que je n'ai pas encore lue). Touriste (d) 3 mars 2012 à 12:05 (CET)

Sur le fond : le rendu de <math> et de ce type de contenus est une vieille épine très difficile à gérer dans les contenus Web (et pas seulement dans le cadre très limité des projets basés sur mediawiki)... Désolé, mais je doute que cet atelier y soit très utile. Son rôle se borne à aider les contributeurs à utiliser de manière « accessible » les solutions en place dans ces projets, et parfois à améliorer l'accessibilité de celles-ci. Il n'intervient pas sur des questions très en amont et sans rapport immédiat avec l'accessibilité, telles que « est-ce ou non un souci que MathML ne soit plus géré ».

Le choix récemment fait de ne plus gérer MathML me semble assez brutal, a priori, cela dit. Mais, à l'usage, cela fait longtemps que j'ai constaté que, quand on parle de « navigateurs texte » dans le développement de mediawiki, c'est qu'on va d'abord dire et ensuite faire des sottises... C'est un bon signal d'alerte, connu par ailleurs. Cordialement, --Lgd (d) 3 mars 2012 à 12:08 (CET)

Complément : le développement de mediawiki s'oriente apparemment vers l'implémentation prochaine de MathJax (voir [3]). --Lgd (d) 4 mars 2012 à 10:47 (CET)

{{lang}}

Bonjour, deux questions à propos de ce modèle :

• faut-il absolument utiliser le code : {{Lang|''code-langue''|texte=''texte''}} et non plus {{Lang|''code-langue''|texte}} ?
• est-il possible de créer un gadget pour la barre de modification (celle classique) pour ajouter le code de ce modèle automatiquement (en un clic) ?

Merci de vos réponses, Prosopee (d) 4 mars 2012 à 09:54 (CET)

Le code explicite (« texte=texte ») n'a aucun caractère obligatoire. Il n'est que rarement nécessaire à vrai dire. Je corrige la documentation du modèle sur ce point.

L'ajout de ce bouton se fait déjà via certains scripts d'utilisateurs. Mais ceux-ci rencontre un souci temporaire lié à la dernière mise à jour de Mediawiki, qui devrait être résolu dans les jours qui viennent.

Je réfléchis par ailleurs à une solution plus générique et plus simple pour les contributeurs que ces scripts personnels, sans pour autant multiplier les gadgets très spécifiques dans les préférences... Cordialement, --Lgd (d) 4 mars 2012 à 11:01 (CET)

Le script que j’utilise actuellement fonctionne toujours mais risque d’être un peu difficile à repérer au milieu du reste (très pratique : une fenêtre me demande le code de langue puis le modèle est inséré… hop, on peut passer à la suite). Ltrl G, le 4 mars 2012 à 11:11 (CET)

[edit] En gros, c’est insertTags('{{lang|'+prompt('Code de langue ?\n')+'|', '}}') dans un lien… Ltrl G, le 4 mars 2012 à 11:17 (CET)

Merci de vos réponses, je suis fixé. Pour le gadget : ce serait super ca rles scripts ce n'est pas trop mon truc... A voir donc. Prosopee (d) 4 mars 2012 à 19:58 (CET)

L'article Websourd est proposé à la suppression

Bonjour, L’article « Websourd » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). Après avoir pris connaissance des critères généraux d’admissibilité des articles et des critères spécifiques, vous pourrez donner votre avis sur la page de discussion Discussion:Websourd/Suppression. Le meilleur moyen d’obtenir un consensus pour la conservation de l’article est de fournir des sources secondaires fiables et indépendantes. Si vous ne pouvez trouver de telles sources, c’est que l’article n’est probablement pas admissible. N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

ConradMayhew (d) 4 mars 2012 à 12:44 (CET)

Si vous connaissez cette association ou pouvez juger de son intérêt, n'hésitez pas à participer au débat de suppression ConradMayhew (d) 4 mars 2012 à 12:44 (CET)

Pour s'en tenir à l'important, l'article est très évidemment « beaucoup et encore au-delà à améliorer ».

Cela dit, vue comme ça au premier coup d’œil, la proposition de suppression est cocasse (pas tout à fait dans certains détails, mais ils ont été masqués). Puis, à mieux y regarder, on s'aperçoit que c'est juste l'effet mécanique des... modèles : {{admissibilité à vérifier}} suivi de {{suppression}} avec un petit coup de pouce du folklore des « Patrouilleurs » qui conduit à des choses beaucoup trop formelles et irréfléchies.

Ce n'est pas grave, cela dit : la conservation de l'article est assez prévisible. Pire : sa suppression éventuelle ne conduira qu'à son inévitable recréation plus tard sous une rédaction plus obéissante aux usages et plus dissuasive pour les pistoleros de la maintenance. C'est ça qui est génial, au fond, avec Wikipédia .

Mais c'est marrant, quand même, de supprimer un article sur un des acteurs majeurs de l'accessibilité Web en France . Cordialement, --Lgd (d) 4 mars 2012 à 14:51 (CET)

Je ne sais pas le raisonnement de Lgd. TiboQorl ne s'est pas enregistré comme patrouilleur, donc je ne vois pas quel est le rapport entre sa demande de suppression et la patrouille?

Si l'on parle de mon intervention (j'étais effectivement patrouilleur), elle a uniquement consisté à notifier cet atelier et le projet handicap afin que des gens qui connaissent le domaine puissent donner leur avis sur un sujet qui est dans leur périmètre. ConradMayhew (d) 4 mars 2012 à 20:08 (CET)

Ma remarque n'avait aucun rapport avec ton intervention pour avertir de cette PàS, qui était au contraire bienvenue, même si cet atelier n'a pas pour propos la rédaction et le suivi des articles sur le sujet. Cordialement, --Lgd (d) 4 mars 2012 à 21:03 (CET)

Ca marche. Je reconnais bien évidemment avoir utilisé pour cette annonce un espace qui n’est pas prévu pour cela. Désolé mais je plaide les circonstances atténuantes : c'était pour la bonne cause! Je suis un fervent défenseur de la patrouille, mais aussi un fervent adversaire de la suppressionnite aigüe : on ne devrait supprimer un article qu'après avis de ceux qui connaissent le sujet, sinon on dégomme tout et n'importe quoi juste parce qu'on n'y connait rien! En lisant ton commentaire plus haut, je pense qu'au final on se rejoint assez bien sur cette conclusion… Cordialement, ConradMayhew (d) 4 mars 2012 à 22:22 (CET)

Articles-galeries

Bonjour, un article comme Sporophore est-il acceptable sur Wikipédia à condition d'y ajouter simplement des « alt » ? --Amicalement, Salix ( converser) 4 mars 2012 à 13:10 (CET)

Ps. C'est pour savoir si on peut encourager ce type d'article qui semble bien pratique mais qui repose essentiellement sur des images ou s'il vaut mieux trouver une autre solution (pas pour servir d'argument à une suppression ). Est-ce totalement indigeste pour un lecteur d'écran ou améliorable ? Faut-il demander l'ajout de texte explicatif ? Faut-il limiter la longueur des galeries ? Faut-il préférer l'externalisation des galeries sur des pages Commons avec descriptif là-bas ? Tout à la fois ? Bref peut-on multiplier ce type d'article ? --Amicalement, Salix ( converser) 4 mars 2012 à 17:16 (CET)

Les questions liées à l'accessibilité sont les mêmes que pour tout autre article, quel que soit sa forme. Les images de galerie nécessitent des alt, comme pour toute autre galerie. Et si on ne pouvait pas en mettre, ce défaut d'accessibilité ne devrait pas pour autant peser dans le choix éditorial d'encourager ou non ce type d'article .

Mon avis est un poil plus que psychorigide sur ce genre de choses, mais c'est totalement assumé : l'accessibilité est un outil au service des contenus, rien de moins mais rien de plus. Ce sont donc les contenus et leur pertinence ou leur besoin qui tranchent .
D'ailleurs, c'est pourquoi, à vrai dire, on ne parle sagement jamais ici de certains modèles très employés, à l'accessibilité littéralement dramatique... mais totalement irremplaçables en matière de contenu : il serait absurde pour l'encyclopédie de supprimer les feuilles de match, par exemple... Cordialement, --Lgd (d) 4 mars 2012 à 18:28 (CET)

Certes, mais je ne voudrais pas être celle qui naïvement irait encourager leur multiplication si d'autres mises en forme plus accessibles existent ou que certaines astuces ou restrictions permettent de limiter les dégâts. C'est là que les conseils éclairés de cet atelier s'avèrent utiles . --Amicalement, Salix ( converser) 4 mars 2012 à 18:52 (CET)

{{lang}} toujours...

Salut à toutes et tous,
Je relis actuellement un article de musique anglophone. La contributrice principale a pris soin d'utiliser {{lang}} pour tous les termes anglais, y compris ceux existant en français tels : single, mix, etc. Veuillez observer ce diff pour constater que l'utilisation constante de ce modèle pour des termes qui sont entrés en français est peut-être à revoir ? Son usage alourdit l'article, en plus de demander un travail important.

Peut-on considérer que des emprunts à l'anglais (mix, single, pop rock, etc.) ne soient pas formatés par le modèle {{lang}} ?

Bien cordialement. Prosopee (d) 12 mars 2012 à 08:41 (CET)

C'est un vieux serpent de mer. Du strict point de vue de la conformité aux normes d'accessibilité, la langue doit impérativement être précisée « sauf pour un nom propre, pour un terme technique, pour un mot dont la langue est indéterminée ou pour un mot ou une expression faisant partie du langage courant de la langue utilisée dans le contexte immédiat » ([4]). Plus précisément : il n'est pas interdit d'indiquer la langue dans ces différents cas, mais il n'y a pas d'obligation. Surtout, le point essentiel est qu'en dernier ressort, ce qui tranche est le rendu du terme ou de l'expression concernée quand elle prononcée à la manière de la langue du contexte (ici, le français) : si le résultat est difficilement compréhensible, l'usage du modèle {{lang}} est évidemment recommandé. Cordialement, --Lgd (d) 16 mars 2012 à 20:47 (CET)

Certes il n'est pas interdit d'indiquer la langue, mais encore faut-il indiquer la bonne ! Si le mot français « single » est utilisé dans une page de la Wikipédia en français, on ne voit pas pourquoi on l'affublerait du modèle {{lang}} qui n'est destiné qu'aux passages écrits dans une autre langue que celle de l'article. Notez l'exemple explicite donné par le W3Org concernant le mot français "podcast" dans un texte français (exemple 3 dans [5]). Touriste (d) 16 mars 2012 à 20:58 (CET)

D'un autre coté, dans le cadre d'une prononciation, "single" se prononce toujours en français − il me semble − "si-ngeul" et non pas "single" (comme "tringle" ). Hexasoft (discuter) 16 mars 2012 à 21:02 (CET)

En l'absence de mention de la langue, la prononciation par défaut de single dans les lecteurs d'écran où je viens de faire le test est similaire à celle de tringle... La recommandation suivante peut donc s'appliquer dans ce cas : « If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text. » ([6]).

@Touriste : ce modèle et cet attribut n'ont aucune autre portée que le fait de fournir une information nécessaire aux outils logiciels (lecteurs d'écran, traducteurs, robots d'indexation). Les considérations plus théoriques sur le fait de savoir si un terme est réputé français ou non n'entrent pas vraiment en ligne de compte. Cordialement, --Lgd (d) 16 mars 2012 à 21:07 (CET)

Ta première remarque, je l'avais aussi notée, et c'est pour cela que j'ai recherché si les mots français et anglais tous deux écrits "single" se prononçaient ou non de la même façon ; les sources que j'ai consultées m'ont confirmé que non. Si ton lecteur d'écran n'a pas un dictionnaire français aussi complet que le TLFI, qu'y puis-je...

La deuxième je ne la comprends tout simplement pas : certes il faut donner une information aux outils logiciels, mais il vaut mieux leur donner une information exacte ! Si on leur dit que le mot est anglais, ils n'iront jamais prononcer le ə qui fait partie de sa prononciation correcte, ou du moins répertoriée par un dictionnaire auquel j'ai accès. Prononcer les mots français à l'anglaise n'est pas une bonne idée (sauf dans les hypothèses où les mots anglais et français sont homophones, genre « c'est top »). Touriste (d) 16 mars 2012 à 21:17 (CET)

Cela ne fonctionne pas vraiment comme cela. D'une part, la démarche est essentiellement pragmatique : fournir aux outils les données qui leur sont nécessaires en l'état de l'art et des implémentations. D'autre part, il s'agit de permettre l'accès au sens (et pas seulement pour une synthèse vocale, cf la question des traducteurs automatiques), pas d'optimiser la prononciation. En fait, « trop » vaut mieux que « pas assez » dans ce domaine.

Mais bon, si Wikipédia en est à se poser la question de la pertinence du modèle {{lang}} dans ce genre de cas limites, ce n'est pas vraiment un souci et le choix fait spécifiquement pour tel ou tel terme n'est pas l'essentiel : le seul fait d'en être à ce niveau de question est déjà révélateur d'une situation très encourageante, voire satisfaisante, sans ce genre de souci le plus souvent . Cordialement, --Lgd (d) 16 mars 2012 à 21:23 (CET)

Tout à fait, comme tu le fais remarquer, on le prononce à la française avec un ə ("eu" dans ta transcription), voyelle qui n'est pas présente dans le mot anglais d'où dérive ce mot français. (Sources : le TLFI pour la prononciation du mot français, le "Grand Larousse Anglais-Français" (exemplaire papier) pour la prononciation du mot anglais). Touriste (d) 16 mars 2012 à 21:12 (CET)

La difficulté plus générale avec les mots étrangers (ici anglais) introduits en français est que le respect de la prononciation n'est en général pas complet. Ainsi on prononce bien /sin.gœl/ mais contrairement à l'anglais on ne dit pas (il me semble) des /sin.gœlZ/ (le Z est de moi, hein) quand on utilise le pluriel. Pas certain dans ces cas-là qu'une méthode uniforme puisse couvrir tous les cas.

D'un autre coté il n'est possible de se reposer sur un dictionnaire complet (en terme de prononciation "en français") que dans la mesure où il n'y a pas d'homonyme. Le prénom français Roger et le terme miliaire Roger ("rodjeur") s'écrivent pareil, seul la contextualisation d'un {{lang}} peut aider un outil automatique à faire la part des choses. Hexasoft (discuter) 16 mars 2012 à 22:29 (CET)

Pour une prononciation d'anglais à la française, on utilisera « {{lang|en-fr|single}} ». Visite fortuitement prolongée (d) 16 mars 2012 à 23:13 (CET)

En théorie, oui. Mais « en-FR » n'a aucun impact sur les synthèses vocales actuellement (comme la plupart des précisions de région). Cela me semble plus une source de confusion potentielles pour les contributeurs qu'autre-chose (il est d'ailleurs préférable de respecter l'usage de l'écriture du tag de région en capitales, pour limiter ce souci). --Lgd (d) 16 mars 2012 à 23:18 (CET)

Bon, le mieux reste de ne pas utiliser lang avec les mots étrangers empruntés ? Prosopee (d) 17 mars 2012 à 08:09 (CET)

S'il faut absolument adopter une règle formelle aussi simple que possible, on peut retenir celle-là (bien que la notion de mot étranger emprunté ou de terme entré dans l'usage puisse prêter à débats comme le montre cette discussion ). Mais encore une fois, le mieux est encore une approche pragmatique au cas par cas, telle que recommandée par WCAG : s'il y a un doute sur la facilité à comprendre le terme prononcé « à la française » (single prononcé avec un ɛ̃ comme tringle), mentionner le changement de langue. Cordialement, --Lgd (d) 17 mars 2012 à 08:33 (CET)

Excusez ma naïveté, mais si l'objectif du modèle {{lang}} est l'indication d'une langue autre que le français, il n'a pas à être utilisé sur les mots entrés dans la langue française. Si son objectif est l'indication d'une prononciation autre que la prononciation française standard, alors il faut aussi l'utiliser pour « football », « cutter » et bien d'autres. Dans ce deuxième cas, il vaudrait mieux le renommer {{vocal}} par exemple ({{prononciation}} est déjà pris). Ambigraphe, le 17 mars 2012 à 10:03 (CET)

arf, c'est compliqué, décidément, à ce niveau de détail .

D'abord, il ne s'agit pas seulement de prononciation : {{lang}} joue un rôle tout aussi important pour les traducteurs automatiques et pour l'indexation linguistique des contenus.

D'autre part, concernant la prononciation, ce dont il est question ici est justement la zone grise où un terme :

• peut être formellement considéré comme étant entré dans les usages (single, football), notamment parce que tel dictionnaire de la langue en question le mentionne ;
• mais ne sera pas pour autant pris en compte de manière pertinente par les outils logiciels en fonction de leurs propres dictionnaires.

« football » ne pose pas de problème, qu'il soit ou non balisé avec un modèle {{lang}} : il fait partie des termes reconnus par les aides techniques. En revanche, « single » pose apparemment un problème de rendu vocal s'il n'est pas balisé.

Deux points clés, à ce stade:

1. Il est évident qu'on ne va pas regarder au cas par cas en testant dans les aides techniques pour trancher.
2. Il n'y aura aucune réponse entièrement satisfaisante pour la gestion de cette zone grise. Jamais. C'est le principe même de ce genre d'épine dans le pied.

Partant de là, il y a au moins deux approches possibles :

1. celle que propose Prosopee, qui est l'approche formelle : dès lors que le terme est réputé être entré dans les usages en français (par ex. présence dans un dictionnaire type Académie française, TLFI etc.), on ne met pas le modèle {{lang}}, quelles que soient les conséquences mesurables sur le rendu effectif ;
2. celle que recommande WCAG, qui est l'approche pragmatique : il n'y a pas d'obligation à utiliser le modèle {{lang}} dans ce cas, mais le bon sens prévaut : s'il y a un doute, on utilise le modèle {{lang}}.

Je privilégie pour ma part la seconde voie, qui ne pose généralement pas de problèmes du côté des équipes éditoriales. Et j'avoue que les difficultés apparentes à comprendre cette approche pragmatique m'échappent un peu, là. Mais peut-être est-ce moi qui l'explique mal ? En tous cas, si l'approche plus formelle est jugée préférable ici, ce n'est pas un souci : couper les cheveux en huit pour savoir si un terme comme « single » doit ou non être accompagné du modèle {{lang}} n'est vraiment pas une question majeure. L'idée majeure est plutôt que des choses beaucoup plus évidentes utilisent de plus en plus systématiquement ce modèle, ce qui est déjà énorme en terme de sémantique et d'accessibilité. A ce stade, l'erreur serait de se perdre dans des détails de surqualité. Cordialement, --Lgd (d) 17 mars 2012 à 10:34 (CET)

J'aurais tendance à suivre l'approche formelle, mais j'espère savoir me montrer pragmatique : si certains mots ne sont pas bien lus a priori par les synthèses vocales, je suis tout à fait d'accord pour qu'on leur adjoigne l'information utile. Par exemple, je ne verrais pas d'inconvénient à ce qu'on écrive {{vocal|en|single}} pour indiquer qu'il vaut mieux prononcer ce mot à l'anglaise.

Prenons par exemple les sigles « FBI » et « États-Unis », représentant tous deux des mots en anglais. Le premier se prononce à l'anglaise tandis que le deuxième se prononce en général à la française. Ambigraphe, le 17 mars 2012 à 13:25 (CET)

LgD a parfaitement résumé le dilemme. Mais je me contente de suivre l'avis des experts techniques, sans vouloir imposer un point de vue. Si j'ai posé la question c'est surtout au regard du temps énorme que prend l'usage du modèle dans un article comme celui dont je parle au début de cette discussion. Sans parler du poids de l'usage répété du modèle. Ma demande visait à déboucher sur un consensus technique permettant d'économiser du temps de travail, tout en satisfaisant au bon sens. J'en viens à une autre interrogation : si on met de côté les deux approches, revenant ainsi à dire que tout terme étranger, prononciation française ou pas, utilisés - et relativement récurrent dans son usage - doit être accompagné de {{lang}}, est-il envisageable d'automatiser l'ajout du modèle ? Je pense à l'énorme travail pour tout uniformiser, travail qu'aucun relecteur ou contributeur ne pourra faire. Prosopee (d) 17 mars 2012 à 19:01 (CET)

À LgD : Avec ces deux « approche », le mot « rover » devra être indiqué comme anglais car absent des dictionnaires. Visite fortuitement prolongée (d) 17 mars 2012 à 22:29 (CET)

À Prosopee : Il y a une quatrième « approche » : ne jamais mettre {{lang}} lorsque le mot est dans une phrase ne français, par exemple « FBI », « CIA », « orbiter » ou « rover ». Visite fortuitement prolongée (d) 17 mars 2012 à 22:29 (CET)

À tous : entre interdire totalement et rendre obligatoire pour tous les cas, il y a un grand nombre de politiques éditoriales possibles. Visite fortuitement prolongée (d) 17 mars 2012 à 22:29 (CET)

J'ai l'impression qu'aucun des participants à cette discussion n'a pour objectif d'interdire totalement ou de rendre obligatoire quoi que ce soit. Il y a essentiellement deux questions en suspens :

1. Quel est l'usage intelligent du modèle {{lang}} ? Trois possibilités sont présentées (je n'arrive pas au chiffre de 4 comme l'avance Visite fortuitement prolongée) :
   1. Uniquement pour les mots hors de la langue française (officielle ou d'usage).
   2. Pour tous les mots dont la prononciation ne ressemble pas à celle du français.
   3. Uniquement pour les mots étrangers mis en exergue (par exemple dans « Les mathématiques, du grec máthēma ») et dans les phrases citées en langue étrangère.
2. Comment donner l'information utile aux logiciels de synthèse vocale ?

La première question est théorique : chaque option est un choix qui se justifie en fonction des divers points de vue. J'étais plutôt partisan de la première solution, mais la troisième me semble plus pertinente.

La deuxième question est pratique : seuls ceux qui connaissent ces systèmes peuvent nous faire avancer là-dessus. En particulier, j'aimerais bien savoir si l'on peut renseigner la prononciation de « single » en début d'article et compter que le logiciel s'en souvienne dans la suite du texte. Ambigraphe, le 18 mars 2012 à 10:28 (CET)

Je réponds un peu vrac:

@Prosopee : la question de l'automatisation revient régulièrement. A ce jour, aucune solution d'automatisation fiable n'a pu être proposée. Il y aurait des possibilités en ce sens, mais avec des développements lourds qui dépassent largement les capacités des gadgets.

Plus généralement, il faut garder en tête un autre aspect clé de l'accessibilité et plus largement de la qualité Web : c'est un processus d'amélioration continue. Autrement-dit, on sait très bien qu'à un instant T (au terme d'une relecture par exemple), on aura encore une marge d'amélioration importante. Il ne faut donc pas que ce type de critère « pèse trop » au détriment du processus de relecture : le relecteur fera au mieux afin d'améliorer l'article sur ce point, sans se contraindre à ne pas améliorer d'autres aspects parce qu'il aurait mis tous ses moyens et son temps sur ce seul critère.

@Ambigraphe :

• Avant tout, il faut être attentif à ne pas réécrire le critère tel qu'il est formulé (et soigneusement pesé) par la spécification WCAG : « la langue de chaque passage ou expression du contenu peut être déterminée par un programme informatique sauf pour un nom propre, pour un terme technique, pour un mot dont la langue est indéterminée ou pour un mot ou une expression faisant partie du langage courant de la langue utilisée dans le contexte immédiat. » La difficulté est que le propre de cette spécification est d'avoir un haut niveau d'abstraction, et donc de nécessiter qu'on produise une méthode d'application adaptée à tel ou tel contexte (dans le contexte des articles de Wikipédia, la méthode d'application en chantier est Wikipédia:Atelier accessibilité/Bonnes pratiques ). Les clés de celle-ci me semblent :
  • l'usage du modèle {{lang}} (ajouter un modèle supplémentaire du type {{vocal}} ou renommer sous cette forme n'est pas nécessaire) ;
  • ne pas se déterminer en fonction de types arbitraire de contenus, tels que « les mots étrangers mis en exergue » : le critère WCAG est indifférent à ce genre de distinction ;
  • si l'application formelle du critère est retenue, choisir un dictionnaire de référence unique qui permettra aux contributeurs de vérifier simplement et immédiatement s'ils doivent ou non appliquer le modèle à tel ou tel terme. Les noms propres et les termes dont la langue est indéterminée ne posent pas difficulté. Les soucis avec les termes techniques semblent rares. Le souci essentiel est celui des « mots ou une expressions faisant partie du langage courant ». Le dictionnaire où on ira simplement chercher la présence ou l'absence des termes concerné peut être le TLFI. Dans le cas d'autres méthodes d'application, il s'agit le plus souvent du dictionnaire de référence « national » (dictionnaire de l'Académie pour le RGAA par exemple). Le tout est qu'il permette une lecture immédiate de la réponse attendue.
• enfin, sur le dernier point : non, les outils ne peuvent pas déterminer la langue d'un terme ou d'une expression à partir d'une mention précédente dans le code de la page. Un mécanisme de ce type existe pour les abréviations et acronymes, mais il n'existe pas pour la mention de la langue : chaque occurrence doit être renseignée.

Pour conclure, il est évident que la bonne pratique est à améliorer, pour donner des guides plus opérationnels. Si les éléments ci-dessus vous semblent pertinents, je vais tâcher de vous proposer quelque-chose.

Cordialement, --Lgd (d) 21 mars 2012 à 09:29 (CET)

Merci pour ces réponses. Du coup j'ai lu le passage que tu cites dans la spécification WCAG, pour lesquelles j'ai eu besoin d'un peu plus d'explications. Sans doute ai-je moins de hauteur de vue que toi sur le sujet, mais je relève quand même que « les mots [occasionnant un changement de langue de façon isolée] devraient être considérés comme relevant de la langue du texte environnant sauf si le changement de langue est clairement intentionnel ». Le fait d'être mis en exergue ne correspond-il pas précisément à ce cas ?

Par ailleurs, le modèle {{lang}} apparait dans l'édition du texte, pas dans le rendu de la page où c'est la balise <lang> qui est en jeu. En l'absence d'une balise HTML de prononciation, j'ai bien compris que l'information à ce sujet passe par la balise HTML de langue. Mais je ne vois pas pourquoi il n'y aurait pas d'intérêt à utiliser un modèle spécifique renseignant non seulement la synthèse vocale, mais aussi le lecteur lambda qui souhaite voir la prononciation d'un mot.Ambigraphe, le 21 mars 2012 à 09:57 (CET)

L'explication que tu cites est liée à l'exemple précis du terme « rendezvous » qui est devenu un terme d'usage en anglais. C'est pour cette raison que, dans un texte en anglais, il n'a formellement pas à être balisé comme étant en français. Dans la plupart des cas, c'est donc sans rapport avec la notion de mise en exergue. Mais l'explication entre davantage dans les subtilités en précisant qu'un auteur pourrait aussi avoir employé le terme tout en le mettant spécifiquement en relief, de manière à insister sur le fait qu'il s'agirait alors du terme français original et non du terme entré dans les usages (par exemple, un romancier fait parler un personnage qui use particulièrement de termes en français. C'est amusant le hasard : j'ai justement en tête le cas d'un thriller de Preston et Child où, pour une version en e-book accessible, on a eu à traiter exactement le cas de cette expression parmi d'autres du même ordre ): dans ce cas, il faudrait indiquer le changement de langue pour faire ressortir cette nuance. Mais est-ce que l'usage dans Wikipédia, par les contributeurs, des divers type de mise en exergue (guillemets, etc.) entre vraiment dans ce cas très particulier ? Il me semble que non : ce genre d'effet de style est sans doute très rare ici.

Pour {{lang}} et {{vocal}}, à vrai dire, je ne suis pas sûr de bien comprendre le besoin. Le modèle {{lang}} permet d'indiquer la langue d'un terme, d'une expression ou d'un passage (il produit le code HTML approprié, qui est un attribut lang sur un élément span). Cette information est notamment destinée à permettre la prononciation la plus intelligible possible par une synthèse vocale, mais pas seulement : elle a un rôle plus large, qui concerne d'autres outils (indexer des termes, aider la traduction automatique, afficher la bonne police ou taille de caractères, etc.). Dès lors, un modèle {{vocal}} me semblerait plus une source d'erreur de compréhension sur le fond ?

En outre, {{lang}} est entré dans les usages wikipédiens, avec un succès à vrai dire inattendu. Il serait risqué de réparer ce qui n'est pas cassé en le renommant, je crois.

Cordialement, --Lgd (d) 21 mars 2012 à 10:16 (CET)

Je crois comprendre − Ambigraphe me corrigera si je me trompe − que derrière {{vocal}} se cacherait une idée différente : non pas indiquer une autre langue, mais indiquer une prononciation non standard d'un terme français. Un exemple est single, qui est présent dans les dictionnaires français, et n'est donc pas un mot anglais dans un contexte normal, mais a une prononciation qui n'est pas déterminable sans se référer à des données spécifiques (dictionnaire précis intégrant la prononciation « presque à l'anglaise », ou indication spécifique de la prononciation).

L'ambiguïté de cette démarche est que ça revient à faire le travail des « dictionnaires », à savoir indiquer comment doit se prononcer un mot français. L'intérêt de cette démarche est qu'elle permettrait de ne pas amalgamer un mot anglais dans un texte français et un mot français se prononçant comme un mot anglais (toutefois cette différenciation ne serait qu'au niveau du code wiki, puisqu'il n'existe pas − il me semble − de balise HTML spécifique pour ça, donc ça ne se verrait pas coté lecteur). Hexasoft (discuter) 21 mars 2012 à 11:33 (CET)

Comme tu le soulignes, on n'indique en fait rien du tout, puisque le résultat est identique dans le contenu produit. Le tout au prix d'une complexité accrue de la syntaxe wiki, qui ne sert pas à être exploitée en propre pour d'éventuelles informations qu'elle porterait : elle sert juste à produire le contenu qui, lui, est exploité. Autant ne pas rendre les choses plus compliquées pour les contributeurs pour une nuance d'information inexploitable.

Ou alors, si veut aller au bout de l'idée : on définit un micro-format HTML wikipédien, avec un nom de classe spécifique, par exemple lang="en" class="wp-mf-vocal". Mais c'est bien la première fois que je vois passer cette idée : est-elle vraiment susceptible d'avoir une exploitation quelconque ? Autrement-dit, une sémantique  ? Cordialement, --Lgd (d) 21 mars 2012 à 11:39 (CET)

Oui, en l'état ça n'aurait pas d'application pratique, et ça ajoute une couche d'édition. Ça aurait un sens si par exemple il était prévu à plus ou moins long terme un tag ayant cette sémantique dans le HTML, auquel cas une simple mise à jour du modèle permettrait de coller aux bonnes pratiques, tout en préparant dès à présent le terrain.

En dehors des évolutions prévues par les normes HTML, y a-t-il des consignes, tentatives… de la part de ceux qui font les outils d'aide (lecteurs de pages, par exemples) ou de ceux qui les utilisent pour pousser en ce sens ? Si oui, se rapprocher de ces groupes pour offrir un tag wikipédien aux lecteurs aurait éventuellement un sens.

En l'absence de toute visibilité sur une éventuelle apparition d'une sémantique correspond à ce « besoin » ça reste effectivement wiki-centré, puisque ça n'aide pas plus les lecteurs et ça complique la vie aux rédacteurs.

Reste que sur le fond il est sémantiquement faux d'écrire « Ce groupe de rock a classé son {{lang|en|single}} à la troisième place du TOP50 » (oui, le top50, je sais, je commence à être vieux… ). Hexasoft (discuter) 21 mars 2012 à 13:01 (CET)

A ma connaissance, non, cette distinction n'est pas envisagée. Il se peut, par contre, que des questions comme celle-ci, posée à large échelle sur des sites comme Wikipédia, puisse nous servir en ce sens par la suite. Sans le savoir, les projets wikimedia ont un impact assez notable sur l'évolution de ces normes. On en a eu l'exemple dans un autre cas pour le HTML5 sur des questions d'alternatives d'images : le cas « Wikipédia » avait été l'un de ceux cité en exemple pour appuyer une proposition d'évolution du HTML... Les mentions de langues peuvent donner lieu à une étude du cas Wikipédia, considéré comme exemplaire.

Sinon, ton exemple n'est pas « sémantiquement faux ». Il est juste sémantiquement moins précis qu'on pourrait le souhaiter. Avec une question de fond, au moins par précaution, sur le besoin d'un tel niveau de précision. Cordialement, --Lgd (d) 21 mars 2012 à 13:35 (CET)

Je confirme à Hexasoft qu'il a parfaitement résumé ma pensée (ce qui ne veut pas dire qu'il y aurait incompréhension entre Lgd et moi, bien sûr, mais comme il est beaucoup plus avancé que moi sur le sujet, ma comprenette met peut-être parfois du temps à le suivre). Ambigraphe, le 21 mars 2012 à 13:38 (CET)

Il me semble que tous les principaux intervenants sur cette question sont sur la même longueur d'onde. Cordialement, --Lgd (d) 21 mars 2012 à 13:43 (CET)

Titre de section avec modèle: siècle

Bonjour. Il m'arrive parfois de rencontrer des titres de section du genre « XIX^e siècle ». Est-ce que ça pose problème au niveau accessibilité générale et si oui, de quelle manière les corriger ? Père Igor (d) 7 avril 2012 à 12:22 (CEST)

Ces modèles ne posent pas de problèmes d'accessibilité proprement dite. Au contraire, ils ont été adaptés pour être des améliorations d'accessibilité, il y a déjà quelques temps. Le fait de les employer spécifiquement dans un titre de section n'en pose pas non plus.

Par contre, cela rend moins facile l'utilisation d'un lien direct vers cette section (une ancre). Mais le problème n'est pas bloquant et des améliorations pourraient être apportées techniquement.

Au bout du compte, tout bien pesé : s'il est pertinent d'avoir un siècle dans un titre de section, il vaut mieux que ce soit fait avec le modèle, même si c'est améliorable. Cordialement, --Lgd (d) 7 avril 2012 à 14:58 (CEST)

Merci pour l'avis. Père Igor (d) 7 avril 2012 à 19:37 (CEST)

Modèles de titre : ménage de printemps

Bonjour,
Malgré le suivi aussi régulier que possible de leurs usages, un petit ménage de printemps serait nécessaire dans les utilisations des modèles de titre ({{Langue du titre}}, {{Titre mis en forme}}, {{minuscule}})

Il y a en effet une erreur qui ne peut pas être détectée automatiquement via des catégories de maintenance, et qui a fini par s'accumuler : l'usage simultané de plusieurs de ces modèles dans le même article (les limites techniques imposées par mediawiki font en effet qu'ils ne sont pas cumulables. Si plusieurs sont utilisés dans un article, seul le dernier dans l'ordre du code est pris en compte).

A l'aide de catscan, j'ai obtenu la liste des pages comportant le doublon {{Langue du titre}} + {{Titre mis en forme}} : Utilisateur:Lgd/Doublons modèles de titre. Il y a 136 articles à corriger comme dans cet exemple, (peut-être pourrait-on recourir à un bot, mais je n'ai pas regardé le détail des articles).

Il faudrait regarder également du côté de {{minuscule}}. Et comme toujours, s'assurer qu'il n'y a pas de titre en français dans les articles utilisant Langue du titre (cela arrive régulièrement à la suite d'un renommage)...

Des courageux ? Des idées ? Cordialement, --Lgd (d) 10 avril 2012 à 10:31 (CEST)

Ceci ne devrait-il pas éviter des problèmes futurs ? Yapuka virer les {{titre mis en forme}} des articles concernés !

Cordialement --Pic-Sou 10 avril 2012 à 11:12 (CEST)

Avant tout, il vaut mieux prendre le temps de proposer et de s'assurer qu'il n'y pas de souci, plutôt que de modifier inopinément un modèle tout de même assez utilisé (un peu plus de 3000 pages à ce jour).

Sur le fond : l'idée avait déjà été longuement évoquée, et la conclusion était qu'il n'y avait pas de consensus. Le rôle de l'italique, du point de vue des usages typographiques, est l'objet de nombreuses discussions sur Wikipédia, et de plusieurs désaccords. Certains contributeurs considèrent qu'il n'y a jamais lieu de mettre en italique les titres d'articles, même s'il s'agit d'expression en langue étrangère. D'autres considèrent que seuls les titres d'articles qui sont des titres d'oeuvres sont à mettre en italique. Pour d'autres, ce sont les seuls titres dans un langue étrangère. D'autres encore sont en faveur de l'italique systématique, que ce soit pour les titres d'oeuvres ou pour les titres en langue étrangère, etc.

D'autre part, selon qu'il s'agit ou non d'un titre d'oeuvre (pour un titre de page en langue étrangère), le balisage approprié pour l'italique peut différer : ce n'est pas nécessairement ''...''.

Enfin, {{Titre mis en forme}} est utilisé par les modèles de taxobox pour gérer à la fois l'italique et la langue (c'est un cas où un consensus local a émergé à l'échelle d'un projet précis) : si cette modification de {{langue du titre}} est effectuée, il y a des choses à voir et à prévoir de ce côté.

J'ai donc annulé cette modification un peu trop hâtive. Cette solution n'est pas exclue dans l'absolue, mais elle nécessiterait plus de préparation. Merci de ta compréhension, cordialement, --Lgd (d) 10 avril 2012 à 11:34 (CEST)

OK, je ne connaissais pas ces discussions. Par contre, je pense qu’un modèle {{titre italique}} serait utile, étant donné que la majorité des usages de {{titre mis en forme}} consiste à mettre le titre en italique. Cordialement --Pic-Sou 11 avril 2012 à 11:03 (CEST)

Une fois retiré les appels à {{titre mis en forme}} effectués directement par les modèles de taxobox, l'usage le plus fréquent est actuellement pour les mises en exposants. Cordialement, --Lgd (d) 11 avril 2012 à 11:09 (CEST)

Je passais par là avec AWB... (même pas capable de faire une regex qui fonctionne ce matin, pfff...) Il ne doit pas en rester beaucoup mais au moins deux :

• Villa Maria : je vois pas la différence de prononciation entre le latin et le français ? àmha, faudrait peut-être carrément enlever les modèles ?
• Papilio demodocus : pas trouvé le modèle mis en forme du titre et pourtant il est listé dans les modèles utilisés ??? --'toff ^[discut.] 14 avril 2012 à 20:22 (CEST)

Pour Papilio demodocus, c'est le modèle:taxoboxoutils titre en italique qui l'utilise. Nodulation (d) 16 avril 2012 à 09:11 (CEST)

Bien vu, j'avais pas pensé au modèle inclus dans un modèle. Du coup, j'ai supprimé le doublon. --'toff ^[discut.] 16 avril 2012 à 09:55 (CEST)

Question sur les modèles d'infobox V3

Bonjour, je suis entrain d'essayer de modifier l'infobox des footballeurs afin de passer au modèle V3, cependant, j'ai un petit problème avec les modèles : Modèle:Infobox V3/Tableau Ligne entêtes et Modèle:Infobox V3/Tableau Ligne données.

Est-il possible de faire en sorte que les entêtes et les données soient alignées de la même façon (à gauche par exemple) ou même avoir des largeurs de colonne ou des alignements différents pour chaque colonne ?

Exemple sur lesquels je travaille : Utilisateur:CONCACAF-Footballeur/Souleymane Camara et Utilisateur:CONCACAF-Footballeur/InfoboxV3.

Merci d'avance pour vos réponses.

CONCACAF-Footballeur (d) 11 avril 2012 à 09:38 (CEST)

La question avait été évoquée à propos de l'infobox rugbyman : les modèles {{deux colonnes}} et {{trois colonnes}} doivent être adaptés avant de convertir ce type d'infobox. J'avais commencé à préparer cela (voir ici), mais je n'aurai pas le temps d'y revenir dans l'immédiat. Le mieux serait d'attendre un peu...

Cordialement, --Lgd (d) 11 avril 2012 à 09:52 (CEST)

La question n'est pas là, en fait est-il possible de gérer les alignements et largeurs de colonne des modèles infobox V3 cités précédemment ou pas, car après, ce n'est pas difficile d'adapter l'infobox ?

Mon problème c'est qu'à défaut, les entêtes sont alignées à gauche et les données sont centrées, ce qui n'est pas très logique.

CONCACAF-Footballeur (d) 11 avril 2012 à 10:27 (CEST)

Si, la question à régler en priorité est là, car adapter l'infobox n'est pas si évident. L'infobox footballeur est actuellement utilisée dans plus de 18 000 articles avec les modèles {{deux colonnes}} et {{trois colonnes}}. Comment envisages-tu concrètement le passage de cette infobox à une nouvelle version n'utilisant pas ces modèles, si c'est bien l'idée que tu proposes ?

Sinon, pour ce qui est de l'alignement, il n'est pas modifiable au cas par cas (c'est à dire aligner à gauche/droite/centrer individuellement chaque colonne). Il y a deux types d'alignements, illustrés par les exemples de Modèle:Infobox V3/Tableau Ligne entêtes :

• Par défaut, les colonnes de ce type de tableau sont centrées (en-têtes et données) ;
• Dans le cas d'un tableau à double entrée, la première colonne est alignée à gauche et les autres sont centrées.

L'infobox footballeur est dans le premier cas.

Cordialement, --Lgd (d) 11 avril 2012 à 10:46 (CEST)

Je suis entrain d'y réfléchir justement, mais par contre, tu dis qu'à défault, les en-têtes sont centrées, mais c'est faux, dans le modèle infobox V3, les en têtes sont à défaut aligné à gauche ... CONCACAF-Footballeur (d) 11 avril 2012 à 11:08 (CEST)

Je pense qu'il y a une confusion. Je parlais ci-dessus des en-têtes de colonnes (modèle {{Infobox V3/Tableau Ligne entêtes}}) qui sont centrés par défaut, sauf pour celui de la première colonne dans le cas d'un tableau à double entrée qui est aligné à gauche. De même, la première cellule de {{Infobox V3/Tableau Ligne données}} est centrée par défaut, mais alignée à gauche avec l'option tableau à double entrée (elle devient alors une cellule d'en-tête).

Parlais-tu des en-têtes de ligne de {{Infobox V3/Tableau Ligne mixte}} ? Eux sont en effet alignés uniquement à gauche, mais ils ne sont pas concernés ici, si j'ai bien suivi. Cordialement, --Lgd (d) 11 avril 2012 à 11:26 (CEST)

Je suis d'accord avec CONCACAF-Footballeur, je ne comprends pas pourquoi les entêtes et les données des colonnes ne sont pas alignées. C'est typiquement le cas dans ton premier exemple où Foo et Bar sont alignés à gauche et lorem et ipsum sont centrés. C'est un choix que je ne comprends pas et que je trouve inesthétique. Que l'alignement ne soit pas modifiable (ce que je déplore) admettons mais à défaut il serait bien de mettre le même alignement pour tous les éléments du tableau. J'avais déjà soulevé le problème l'année dernière mais tu étais parti pour quelques mois juste après et ça et j'avais oublié de te relancer à ton retour. Udufruduhu (d) 11 avril 2012 à 11:21 (CEST)

Dans ce cas, il s'agit sans doute d'un problème lié à un navigateur en particulier, qui devrait être aisé à résoudre. Quel navigateur/version utilisez-vous ? Cordialement, --Lgd (d) 11 avril 2012 à 11:27 (CEST)

Firefox 11, mac, monobook. Udufruduhu (d) 11 avril 2012 à 11:36 (CEST)

Surprenant, j'ai le résultat correct sous les yeux avec la même configuration (et d'autres). Il faudrait chercher du côté des paramètres propres à vos comptes (commons.css, gadgets)...

Mais on va faire plus simple : je vais surcharger le style correspondant dans Commons.css, pour qu'on soit aussi certains que possible d'obtenir l'alignement centré des en-têtes dans tous les cas. Cordialement, --Lgd (d) 11 avril 2012 à 11:48 (CEST)

C'est ailgné maintenant. Merci ! Udufruduhu (d) 11 avril 2012 à 12:00 (CEST)

Je voudrais bien avoir un avis sur l’accessibilité ou non de l'infoboxV3 que j'ai réalisé sur cet exemple : Utilisateur:CONCACAF-Footballeur/Souleymane Camara. Pour éventuellement réfléchir à une méthode (utilisation d'un bot ?) pour l'appliquer de manière plus générale. (Attention je ne travaille qu'à titre prospectif pour le moment, j'informerai le projet foot et demanderai leur avis avant tout modification de masse). CONCACAF-Footballeur (d) 11 avril 2012 à 11:57 (CEST)

Pense à actualiser le cache de ton navigateur pour le problème d'alignement.

Pour Utilisateur:CONCACAF-Footballeur/Souleymane Camara, je ne comprends pas très ce que tu veux faire ? Il ne s'agit pas d'utiliser des appels au modèle directement dans les articles ? Ni de créer un modèle supplémentaire ? La mise à jour de l'infobox peut se faire beaucoup plus facilement, sans nécessiter de modifier les appels dans les articles (la tâche ne sera pas du tout évidente pour un bot), juste une fois faite l'évolution des modèles {{deux colonnes}} et {{trois colonnes}} comme je l'ai expliqué ci-dessus. Je suis désolé que cela impose un peu de retard, mais je vais faire au mieux pour finaliser ceux-ci, puisqu'il y a un besoin.

Sinon, il y a des soucis mineurs avec des tableaux vides qui ne devraient pas être générés (on le les voit pas à l'affichage, mais l'entête est généré dans le code). Il faut utiliser autrement les {{#if}} pour rendre l'ensemble du tableau conditionnel. Mais là aussi, on était en train de se dire qu'on pouvait faire évoluer les modèles existants pour simplifier ce genre de choses : je propose d'attendre un petit peu, que ces différentes évolutions soient faites. Le travail sur cette infobox et d'autres similaires sera alors beaucoup plus facile. Cordialement, --Lgd (d) 11 avril 2012 à 12:19 (CEST)

Il n'y a pas de souci Lgd, c'est juste de la prospection, je viens de regarder ce que tu as fait sur les modèles deux et trois colonnes dans le bac à sable, c'est pas mal, par contre, je pense qu'il risque d'y avoir des problèmes de collisions avec les largeurs des colonnes si il n'est pas possible de gérer indépendamment ces dernières, car avoir les mêmes largeurs pour les clubs et les stats risques de générer des retours à la ligne pas très esthétique. Enfin, si tu as besoin d'un coup de main (puisque tu sembles avoir de nombreuses occupations), hésite pas, je me ferai un plaisir de t'aider (que ce soit sur le foot, ou sur un autre domaine). CONCACAF-Footballeur (d) 11 avril 2012 à 12:27 (CEST)

Oui, la question des largeurs était dans ce qui restait à régler pour ces modèles. Je suis parti initialement dans l'idée de modèles où le nombre de paramètres de rendu était aussi réduit que possible, pour en faciliter l'utilisation et favoriser une certaine uniformisation apparemment souhaitée en général. Cela dit, c'est une démarche à évaluer et à adapter si nécessaire, il ne faut pas que ce soit bloquant.

Merci pour l'offre. Si tu te sens à voir comment faire évoluer les modèles, n'hésite pas. Il est justement important que la Communauté se les approprie . Cordialement, --Lgd (d) 11 avril 2012 à 12:50 (CEST)

Modèle de citation incomplète ?

Si je ne me suis pas trompé, il n'existe pas de modèle pour citer un extrait de citation, en utilisant le traditionnel signe de césure : (...). On a un peu de tout dans les articles : des points de suspension sans espaces insécables, des crochets, des tirets parfois... Il serait peut-être bon d'harmoniser en se calant sur les règles du Lexique et en créant un modèle de type : {{modèle|début de la citation tronquée|fin de la citation tronquée}}, le modèle générant automatiquement entre les deux extraits le signe de césure... San svouloir ajouter encore à notre arche de Noé des modèles, je pense surtout à rendre plus aisé les citations partielles. Cordialement, Prosopee (d) 12 avril 2012 à 09:03 (CEST)

Je ne pas sûr d'avoir bien compris, mais il me semble que l'usage de « [...] » directement saisi dans la citation est correct et ne nécessite pas de modèle ? (exemple très récent, le hasard est amusant). Dans ce cas, ou plus généralement, il s'agirait plus en tous cas de renforcer les usages que de créer un modèle ? Cordialement, --Lgd (d) 12 avril 2012 à 09:52 (CEST)

Je n'ai pas le Lexique en ce moment, donc je ne sais pas si l'usage du signe de césure (crochets ou parenthèses) nécessite des espaces insécables ou pas mais même sans ce détail, je trouve qu'un modèle permettrait justement de renforcer l'usage (en fait c'est comme cela que je découvre les règles : je pars du modèle comme cadre règlementaire). Bref, je posais juste la question pour avoir ls opinions de chacun, mais oui Lgd : il s'agirait plus de renforcer les usages. Prosopee (d) 12 avril 2012 à 10:09 (CEST)

Je suis d'accord avec Prosopee, je pense que {{extrait citation}} renforcerait l’harmonisation… Il m'est déjà arrivé de ne savoir que faire dans ce genre de cas, je pense qu'un modèle m'aurait aidé… Cordialement --Pic-Sou 12 avril 2012 à 15:02 (CEST)

Est-ce qu'une indication quelque-part te disant juste qu'il te suffisait d'écrire « [...] » (ou (...)) dans ta citation aurait répondu à ton besoin ?
Pour aller au plus direct : il est probable que je vais pour ma part résister jusqu'au denier poil de Grenadier de la Garde à un éventuel modèle qui semble inutile et, s'il est créé, va entraîner un surcroît remarquable de complexité pour le contributeur et pour la gestion techniques des modèles... Convenir qu'on écrit ceci ou cela pour signaler une coupure dans une citation n'en demande pas tant, mais sera remarquablement compliqué à gérer via des modèles, sans profit évident pour le rédacteur. Cordialement, --Lgd (d) 12 avril 2012 à 15:18 (CEST)

[conflit] Et si la citation est coupée plusieurs fois ? Un modèle de ce type n’est pas adapté àmha. Ltrl G^☎, le 12 avril 2012 à 15:21 (CEST)

 Bien vu !

Lgd: je ne comprends donc pas : tu es contre tout modèle novateur en gros ? --Pic-Sou 12 avril 2012 à 15:47 (CEST)

Usage du « : » pour indenter

Bonjour, dans votre « Petite liste de choses à faire » je découvre : Corriger les mauvais usages de la syntaxe « : » pour indenter un contenu. Est-ce à dire que ce « : » est réservé aux listes de définitions ? Dans les articles de maths il y a plein de « : » qui servent juste à mettre en retrait, sans la centrer, une ligne de formule au milieu d'un texte. Ces « : » sont-ils fautifs et si oui, par quoi les remplacer ? Anne Bauval (d) 20 janvier 2012 à 20:18 (CET)

La syntaxe « : » devrait en effet être réservée aux seules listes de définition (ou description).

On peut créer facilement un modèle du type t. a. b. remplaçant l'usage de « : », mais avant d'envisager cela, une question à tout hasard : l'indentation des formules est-elle systématique (hors cas de centrage) ? Dans ce cas, on pourrait l'automatiser dans les navigateurs récents, sans que les contributeurs n'aient plus aucune syntaxe à saisir : tout paragraphe (ligne en wiki) ne comportant qu'une formule (non centrée) serait automatiquement mise en retrait. Par exemple, la saisie suivante indenterait :

Sa [[bijection|réciproque]] est 

<math>f^{-1}(x) = - \frac{dx - b}{cx - a}</math>

Le nom provient de ce que si on rajoute à...

Les saisies suivantes n'indenteraient pas :

• rendu sans retour à la ligne :

Sa [[bijection|réciproque]] est 
<math>f^{-1}(x) = - \frac{dx - b}{cx - a}</math>

Le nom provient de ce que si on rajoute à...

• rendu avec retour à la ligne:

Sa [[bijection|réciproque]] est<br>
<math>f^{-1}(x) = - \frac{dx - b}{cx - a}</math>

Le nom provient de ce que si on rajoute à...

Cordialement, --Lgd (d) 20 janvier 2012 à 21:13 (CET)

Merci, c'était pour m'assurer que je ne faisais pas de bêtise, avant de publier ce genre de rectif dans Transformée en Z. Il y reste encore un vilain truc dans cette section (dans la dernière des 4 boîtes déroulantes) :

:----0-1-1-2-3-5-8 etc

Quand on vire le « : », ça donne une horreur.

Je ne sais pas répondre à ta question (je constate seulement que c'est systématique dans les vieux articles de maths sur WP.fr), je vais la poser au Thé.

Anne Bauval (d) 20 janvier 2012 à 23:20 (CET)

Depuis des années que j'en parle… La proposition de Lgd me semble parfaitement sensée et réalisable. Le problème est toujours le même : il faut intervenir sur Mediawiki et, pour cela, réussir à faire bouger les développeurs… En tout cas si besoin j'ai une ou deux expressions régulières qui feraient le boulot et dont je me sers déjà depuis des années. — Florian, le 25 janvier 2012 à 19:27 (CET)

C'est a priori réalisable plus simplement avec juste l'ajout d'une règle CSS dans Common.css, pour les navigateurs modernes (sous réserve que mes suppositions ci-dessus soient exactes quant aux usages de syntaxe envisageables dans ces articles). Cordialement, --Lgd (d) 25 janvier 2012 à 19:36 (CET)

Il ne faut pas oublier le problème des formules qui sont écrites sans <math>, qui ne seraient pas détectées et qu’il faudrait réécrire.
Ltrl G, le 25 janvier 2012 à 20:19 (CET)

Dans ce cas, si vous souhaitez corriger ce problème :

• solution 1 : créer un modèle d'indentation et modifier tous les articles concernés, qu'ils utilisent ou non <math> ;
• solution 2 : mettre en place la solution CSS d'indentation automatique de <math>, créer également un modèle balisant les formules qui n'utilisent pas <math> et modifier les seuls articles concernés par ce cas ;
• solution 3 : ne plus indenter.

Il n'y aura pas de solution « magique » si les contenus ne sont pas balisés d'une manière systématique (qu'il s'agisse d'une solution locale ou mediawiki). Cordialement, --Lgd (d) 25 janvier 2012 à 20:36 (CET)

(je redescend cette section car il n’y a pas eu d'activité depuis quelques temps)

@Lgd: comment cette solution pourrait-elle être mise en place ? Y a-t-il une class appliquée à toutes les formules <math> ? Je suis favorable à ce que le retrait se fasse automatiquement si l'on fait un saut à la ligne ; visuellement c'est bien mieux ! Cordialement --Pic-Sou 12 avril 2012 à 15:53 (CEST)

Bonne question. Sur le moment, j'avais une solution CSS qui faisait la différence entre un <math> isolé et un autre <math> au fil du texte, mais là, comme ça, hop, je ne l'ai plus. Quoi qu'il en soit, la réponse des contributeurs a été négative, donc... Cordialement, --Lgd (d) 12 avril 2012 à 17:25 (CEST)

Plus sérieusement : il y a quelques indicateurs simples en matière de gestion qualité appliqués à WP. 1. la valeur ajoutée pour le lecteur (ici, elle existe indéniablement, mais ce n'est pas prioritaire et de loin par rapport à d'autres choses). 2. La valeur ajoutée pour le contributeur (ici, elle était à évaluer plus précisément à voir les réactions spontanées) et 3. La mayonnaise est-elle susceptible de prendre quoi qu'il en soit si on ne demande pas leur avis aux gens ? (et là, la réponse était non). Bref, on oublie. Cordialement, --Lgd (d) 12 avril 2012 à 17:59 (CEST)

Donc on reste avec la solution peu accessible actuelle ? --Pic-Sou 12 avril 2012 à 18:00 (CEST)

Oui. Froidement: oui, on garde la solution non accessible pour le moment. Améliorer l'accessibilité nécessite de déterminer où faire porter efficacement les améliorations à un moment donné . Cordialement, --Lgd (d) 12 avril 2012 à 18:03 (CEST)

Comme je suis un indécrottable formateur en dépit des apparences, un cas plus pédagogique : il n'a jamais été question de remettre en cause les usages des modèles du type carte de géolocalisation (dans les infobox en particulier), qui sont pourtant non seulement un immondice quant à leur code d'un point de vue général, mais aussi un déni immédiat d'accessibilité. Tout simplement parce qu'on ne peut pas fournir une autre solution robuste accessible et admissible par les contributeurs pour le moment. Veux-tu lancer une PDD proposant de supprimer tous les contenus reposant sur ces modèles ? Non, n'est-ce pas ? Donc, on fait avec du contenu peu ou plutôt pas accessible (et même pire). Pour le moment. Et sans souci. Cordialement, --Lgd (d) 12 avril 2012 à 18:09 (CEST)

OK. Sinon, peut-on avoir recours à une fonction TeX qui produise un retrait ? --Pic-Sou 12 avril 2012 à 18:48 (CEST)

A ma connaissance, non. Et de toute façons, ce sera à revoir une fois déployé MathJax. Cordialement, --Lgd (d) 12 avril 2012 à 18:58 (CEST)

D'acc merci --Pic-Sou 12 avril 2012 à 19:23 (CEST)

Syntaxe wiki dans les alternatives textuelles des images

Bonjour.

Je remarque que de nombreuses images ont une alternative textuelle contenant de la syntaxe wiki (liens, modèles, mise en forme, etc.). Cela a-t-il un quelconque intérêt ? En effet, en regardant le rendu HTML, cette syntaxe est interprétée par MediaWiki pour donner du texte pur. Donc tous ces liens, modèles, mises en forme disparaissent.

Mais peut-être cela a-t-il un intérêt pour quelqu'un qui extrairait ces alternatives textuelles du code wiki (je n'arrive pas trop à imaginer dans quel but, mais bon) ? Donc cet usage est-il à encourager / à décourager / osef ?

Pour info j'ai trouvé plusieurs centaines d'articles concernés en cherchant dans un dump récent. — Hr. Satz 21 avril 2012 à 17:37 (CEST)

Argh.

Une alternative textuelle est un attribut HTML, dans lequel il ne peut et ne doit y avoir aucun balisage. Ce qui se traduit par : aucune syntaxe wiki (modèle, mise en forme etc.) ne doit être employée dans une alternative textuelle.

En fait, c'est un problème connu mais qu'on n'a pas encore vraiment regardé en détail étant donné qu'il reste en principe assez limité (quelques centaines d'articles, disons, en effet). Mais il est sans doute temps de voir cela de plus près. Bien vu  !

Il va falloir faire du ménage, regarder si on peut prendre des mesures préventives pour que les contributeurs soient informés ou que des modèles soient corrigés et enfin voir quel moyen de suivi pourrait être mis en place.

Pourrais-tu nous donner la liste des articles concernés d'après ta requête sur le dump ?

Cordialement, --Lgd (d) 21 avril 2012 à 17:49 (CEST)

Cela dit, mediawiki neutralise l'utilisation des syntaxes de liens et de modèles dans le contenu final (je n'ai regardé le reste). Cordialement, --Lgd (d) 21 avril 2012 à 18:31 (CEST)

Merci pour ta réponse !

J'ai mis la liste dans Utilisateur:Herr Satz/alt. Je ne suis pas un grand expert des expressions régulières, donc il y a probablement des faux positifs et des faux négatifs (c'est pour cette raison que j'étais resté assez évasif en disant « plusieurs centaines ») ; mais en tous cas pour les quelques articles que j'ai vérifiés la détection était correcte.

Effectivement, vis à vis de ton deuxième message, je me demandais s'il faut vraiment corriger dans la mesure où MediaWiki convertit (il le fait aussi pour le gras et l'italique). La seule chose à faire c'est peut-être d'informer les contributeurs qu'ils n'ont pas besoin de s'enquiquiner à mettre en forme leur alternative textuelle dans la mesure où ce sera perdu ? je ne sais pas. — Hr. Satz 21 avril 2012 à 19:22 (CEST)

Le beau tableau pas accessible

Voir Résultats détaillés de l'élection présidentielle française de 2012. On le rend accessible comment ? Je dirais qu'il faudrait le séparer en plusieurs tableaux (3 ou 4), afin de faire des vrais en-tête de tableaux. Genre "départements de A à G"... Mais y'aurait pas une méthode sémantique pour répéter les mêmes en-têtes dans un tableau ? On peut bien le faire pour répéter les en-têtes en début et fin de tableau, alors... Dodoïste ^{[ dring-dring ]} 22 avril 2012 à 13:02 (CEST)

Oui, plusieurs tableaux (la méthode en question existe, mais il ne serait pas réaliste de la promouvoir en raison de sa complexité). Mais, comment dire... Pour le moment, il est très bien comme cela, ce tableau. L'accessiblité n'y est sans doute vraiment pas la priorité des contributeurs et il s'agit d'un cas isolé et plutôt anecdotique : il n'y a pas d'urgence . Cordialement, --Lgd (d) 22 avril 2012 à 15:30 (CEST)

Hm, je pensais pas à la techniques des ID. Mais je me suis dit que durant l'année ou j'ai lâché le fil de l'accessibilité, il y aurait peut-être une nouveauté en cours de standardisation. Par exemple, ce serait pratique d'avoir un attribut "repeatheaders:X" qui répète les en-têtes tous les X lignes. Bref, je rêvasse. XD Dodoïste ^{[ dring-dring ]} 22 avril 2012 à 18:39 (CEST)

Il y a surtout urgence à ne pas se précipiter : je dirais d’attendre fin mai pour se lancer, le temps que les esprits se calment un peu. Sinon, en accord avec le titre de cette section, je vous soumets ce cas très intéressant, que j’ai commencé à corriger sur mon bac à sable personnel. Mais je ne pense pas avoir le temps de m’y remettre. Si quelqu’un voulait me griller la politesse, je ne m’en offusquerais pas Litlok (m'écrire) 22 avril 2012 à 23:10 (CEST)

Ce qui serait bien en même temps c'est de le rendre triable. Skippy le Grand Gourou (d) 23 avril 2012 à 17:35 (CEST)

Cela n'a pas de rapport avec l'accessibilité, je met un mot explicatif dans la page de discussion en question. Dodoïste ^{[ dring-dring ]} 23 avril 2012 à 17:50 (CEST)

Je sais, mais puisque le tableau sera retravaillé autant que celui ou celle qui s'y colle garde ça aussi à l'esprit — d'autant plus qu'il doit y avoir un overlap entre les ninjas de l'accessibilité et les ninjas des tableaux… Skippy le Grand Gourou (d) 23 avril 2012 à 21:16 (CEST)

US Quevilly

Bonjour, en me documentant sur cet article, je suis tombé sur des tableaux pas accessibles je pense. A vous de voir s'il y a quelque chose à faire. Merci, --2.9.50.76 (d) 30 avril 2012 à 00:54 (CEST)

Merci pour votre message. L'accessibilité des modèles et des tableaux utilisés dans les thèmes sportifs est un peu compliquée. C'est un chantier qui avance tout doucement. Cordialement, --Lgd (d) 6 mai 2012 à 09:38 (CEST)

L'accessibilité du portail Jeu vidéo en cas de consultation sur tétéphone mobile est à revoir.

Bonjour à tous ici.

cf. le titre. Il faut modifier (ou faire modifier!) le logo du portail jeu vidéo. Une refonte de la partie "index thématique" et "portails connexes" est nécessaire.

Pour tous renseignements complémentaires je peux peut-être vous aider... -- Archimëa ✉⇔ 6 mai 2012 à 08:15 (CEST)

Ce n'est pas vraiment dans le champ de cet atelier qui est pour le moment dédié à un autre type de problèmes d'accessibilité. Mais voici quelques éléments (attention, ce n'est pas limpide) :

• le problème n'est pas propre à ce portail : tous les portails sont à revoir pour revoir le code et les éventuels modèles utilisés (retirer les tableaux de mise en forme, notamment, ne pourra qu'aider) ;
• il y a peu de documentation sur l'actuelle version mobile, mais il faut regarder du côté de meta:Mobile Projects/Mobile Gateway. En gros, si j'ai bien suivi, l'idée est de renseigner certains identifiants (pas vraiment documentés) et d'utiliser l'attribut title des div pour parvenir à trier et à « sectionner » le contenu du portail (déjà perdus ? Moi aussi ). Il paraît qu'on peut essayer de comprendre la chose en regardant le code de l'accueil de en.wp ;
• il me semble que ces questions de rendu sur mobile sont en plein mouvement du côté du développement de mediawiki (voir mw:Wikimedia Mobile engineering) : au-delà de quelques corrections ciblées, les améliorations ne dépendent pas vraiment de ce que peuvent faire les contributeurs.

Cordialement, --Lgd (d) 6 mai 2012 à 09:36 (CEST)

Ok, merci pour les éclaircissements, je vois mieux.

Si je peux me permettre de répondre.

• Concernant le point 1, je m'en doutais un peu sans avoir même vérifié. Bon à savoir, mais cela ne concerne ni n'empêche la résolution - ou non - de la problématique soulevée. Une présentation sur une seule colonne! supprime pas mal de soucis en effet.
• Se serait une solution, pouvoir trier les paragraphes/colonnes/partie pour les réorganiser et éviter les problèmes de gestion de largeurs. J'imaginai aussi avec une balise du genre <tag>photo.png<tag>, pouvoir masquer une photo uniquement sur version mobile, même principe avec un attribut pour gérer des largeurs de tableau sur mobile uniquement... Mais je ne sais pas si ca existe.
• Le plus raisonnable semble d'attendre en espérant que ces problèmes soit évoqués et croiser les doigts
  Pour ma part, je pense qu'il est possible de limiter les désagréments même à l'heure actuelle avec les seules possibilités techniques que mediawiki propose ; il faut juste vouloir le faire, c'est pas mon cas pour l'instant ;( . -- Archimëa ✉⇔ 6 mai 2012 à 15:10 (CEST)

Terme défini hors de l'intro

Bonjour !

Je me posais une question : dans Avenue_René-Coty#Historique, je donne les trois noms successifs qu’a eu cette voie du XIV^e arrondissement. Il me semble normal de les mettre en emphase, mais comment ? Est-ce que l’italique que j’utilise ici convient, ou devrais-je plutôt utiliser le gras, voire la balise {{dfn}} ?

Cordialement

Pic-Sou 23 mai 2012 à 18:30 (CEST)

S'en tenir aux usages typographiques en vigueur sur fr.wp est suffisant dans ce cas (guillemets plutôt qu'italique). Cordialement, --Lgd (d) 23 mai 2012 à 20:25 (CEST)

D’accord, merci ! --Pic-Sou 24 mai 2012 à 22:44 (CEST)

MediaWiki : amélioration des images "thumbnail"

Bonjour ! Des gens de Wikimedia Allemagne ont demandé un audit d'accessibilité de Wikipédia, un rapport détaillé semble leur avoir été envoyé. Jusque-là, bien. Mais la société a publié un bref résumé en ligne. Le lien s'est retrouvé à divers endroits, dont entre les mains des développeurs. Là ça sent moins bon, hein ?

Un développeur de bonne volonté a fait un brouillon de modification de MediaWiki, dans bugzilla:34750. Un autre a eu la bonne idée d'en avertir le projet accessibilité EN, mais sans traduire le PHP. Bon. J'étais déjà content qu'il pense à avertir, d'habitude ils font des trucs dans leur coin. Du coup j'ai tenté de temporiser en leur demandant quelques jours de concertation.

Bref, j'ai besoin de super-Lgd ! Au menu, nous avons surtout un remplacement de l'intitulé "enlarge" par "view the media page".

Mais aussi :

• "view the media page" est placé à la fois dans le title du lien, et dans l'alternative textuelle de l'image. Redondance ?
• Je suis pas sûr de ce que ça donne quand l'alternative textuelle est remplie. Le contenu du alt= s'ajoute à "view the media page", ou pas ?
• Un remplacement d'un DIV inutile par un SPAN, mais pas dans tous les cas semble-t-il ?
• La redondance du lien vers la page du média (image + icône) est retirée, mais pas dans tous les cas si je comprends ?

Et, le bouquet : Dans le cas où il n'y a ni alt=, ni légende, le nom du fichier de l'image se retrouve dans l'alternative textuelle. Le retour du grand cauchemar.

Y'a peut-être deux-trois autres trucs que j'ai pas vu. Ça se passe sur #Changes in thumbnail alt text. D'une manière générale, je pense que l'objectif ici est juste de corriger les erreurs, et de s'assurer que la modification soit vraiment une amélioration. Par contre, je ne pense pas que ce soit le moment de ressortir des archives poussiéreuses le "gros changement de gestion des images" qu'on avait imaginé il y a quelques années. Notre gentil développeur a juste l'intention de corriger un petit truc à la sauvette, pas de déplacer une montagne.

Merci de ton attention ! Dodoïste ^{[ dring-dring ]} 4 juillet 2012 à 11:18 (CEST)

Pas sûr d'avoir tout compris, désolé. Il est possible que cela aille plutôt dans le bon sens. Mais il y a un exemple en ligne du résultat ? Une évaluation prévue ? Un endroit où le projet est géré et où faire des retours ?

(Sinon : les « zaudits » semblent vouloir se multiplier, mais sans méthodologie connue ni coordination, ni gestion de projet : pour ce qui me concerne, je préfère me retirer de la chose et attendre de voir ce que ces initiatives vont donner et ce qu'il sera éventuellement possible de faire à partir de là)--Lgd (d) 5 juillet 2012 à 12:21 (CEST)

Ok, alors je vais clarifier. Il n'y a pas de lien direct entre l'audit de Wikimedia Allemagne et la modification de MediaWiki via bugzilla:34750. Un développeur est tombé par hasard sur un résumé de l'audit (publié imprudemment), et a décidé en toute bonne volonté qu'il pouvait faire quelque chose.

Et juste avant de valider la modification de MediaWiki, un dév se dit que ce serait bien d'interagir un peu avec les gars de l'accessibilité qui s'y connaissent un peu mieux... peut-être ?

Bref, j'arrive là-dedans, et je vois des modifications de MediaWiki. Que dois-je en penser ?

En toute honnêteté, j'hésite à leur dire de ne rien faire. D'arrêter tout jusqu'à ce qu'il y ait un vrai projet coordonné. Ce serait peut-être la solution que tu te verrais le plus soutenir ? Dodoïste ^{[ dring-dring ]} 5 juillet 2012 à 19:53 (CEST)

Icône de portail et version mobile

J'ai deux questions liées.

1. Lorsqu'on clique sur une image apparaissant dans un bandeau de portail, on tombe sur le portail lui-même. La source de l'image n'est donc pas accessible, sauf si le portail lui-même contient cette image et que de là on peut accéder au fichier sur Commons. Peut-on légalement se dispenser d'un tel lien sur la page du portail ?
2. Sur la version mobile, l'icône du modèle {{Article détaillé}} n'affiche pas l'icône que l'on voit sur la version normale. Peut-on imiter ce comportement pour les icônes de portail et est-ce souhaitable ?

Merci d'avance pour vos réponses, Ambigraphe, le 4 juillet 2012 à 18:06 (CEST)

1. la question est en principe réglée par le biais des images dans le domaine public et de la page Wikipédia:Crédits graphiques, avec en outre un indispensable zest de bonne volonté intelligente.
2. ce n'est pas une question d'accessibilité. Cela dit, c'est prosaïquement lié à la gestion de l'image sur fr.wp (background CSS aisé à gérer pour les bandeaux de section, ou image HTML plus délicate à gérer pour les bandeaux de portail). On pourrait (avec une classe noprint si je me souviens bien, aussi curieux que cela puisse sembler), mais l'utilité reste à déterminer.

Cordialement, --Lgd (d) 5 juillet 2012 à 12:30 (CEST)

Lang fr ?

Bonjour,

J’ai une question un peu bête : faut-il utiliser le modèle {{Lang-fr}} (et les occurrences du modèle {{lang}} avec le paramètre fr) ? Je viens de le retirer de l’article Gorsedd de Bretagne où je le trouvais inutile, ai-je bien fait ?

Cdlt, Vigneron * ^discut. 7 juillet 2012 à 09:55 (CEST)

Sauf cas extrêmement rares (je ne me souviens pas en avoir rencontré) où un contenu en français serait lui-même enchassé dans un contenu dans une autre langue (par exemple dans une citation en anglais citant un autre texte en français), {{lang}} n'a pas besoin d'être utilisé pour signaler un contenu en français : le contenu entier de chaque page de fr.WP est déjà déclaré comme étant en français par défaut, à un autre niveau. Cordialement, --Lgd (d) 7 juillet 2012 à 10:33 (CEST)

Ok, c’est bien ce que je pensais.

Dans ce cas, ne faudrait-il pas supprimer le modèle {{Lang-fr}} ? (ou au moins, supprimer les utilisations).

Cdlt, Vigneron * ^discut. 8 juillet 2012 à 19:53 (CEST)

Au passage, je signale Wikipédia:Sondage/Utilisation de l'indicateur de langue française. --'toff ^[discut.] 8 juillet 2012 à 21:33 (CEST)

Palette

Je ne sais pas si ça a déjà été évoqué, mais la palette Solarized semble intéressante...

Gonioul (d) 21 juillet 2012 à 00:51 (CEST)

Merci, avant tout, d'avoir signalé cette ressource. Mais elle est en fait peu exploitable.

Cette palette est intéressante du point de vue de certaines questions d'ergonomie un peu pointues, mais elle est sans rapport avec les questions plus « basiques » d'accessibilité : ses illustrations, par exemple, montrent immédiatement de gros soucis d'accessibilité, liés à des questions de contrastes qui ne sont même pas prises en compte.

Pour faire bref : les questions d'accessibilité liées aux choix de couleurs et de leurs contrastes ne sont pas un problème de « palettes ». Quelle que soit la palette, il s'agit pour le moment, en l'état de l'art, de s'assurer plus simplement qu'on se rapproche autant que possible du ratio de contraste/luminosité retenu dans le cadre de la norme internationale d'accessibilité WCAG. Pour cela, il suffit d'utiliser un outil simple, basé sur un algorithme retenu par celle-ci, par exemple le colour contrast analyzer. Il n'est pas parfait, mais il répond bien à ce qui est défini dans la norme d'accessibilité WCAG, pour ce qu'elle couvre en la matière.

C'est donc beaucoup plus souple qu'avec l'adoption d'une palette déterminée . Et plus concrètement, chaque tentative de proposer des palettes accessibles n'a jamais eu comme résultat qu'un immense éclat de rire de la part des graphistes compétents dans ce domaine. Pas parce qu'elles seraient forcément erronées, mais parce que la question n'est pas celle-là et qu'elles sont inutiles : ce n'est pas votre palette qui compte, c'est l'utilisation que vous en faites. Cordialement, --Lgd (d) 21 juillet 2012 à 10:49 (CEST)

Ah tiens, je comprends mieux : je suppose que cela vient de [7], non ? Cordialement, --Lgd (d) 21 juillet 2012 à 14:34 (CEST)

Conseils et commentaires

Bonjour, je viens de découvrir le gadget accessibilité et l’atelier du même coup. Après quelques édition j’ai quelques remarques et questions en rapport, du coup :

J’ai fait un brouillon (pas fini) pour remplacer un tableau par une liste de définition : est-ce réellement plus accessible ?

• avant
• proposition de remplacement

Le remplacement de certains tableaux de formatage par des colonnes (cf. par exemple ce diff me semble mieux s’adapter à la visualisation sous divers terminaux, en particulier les terminaux avec des écrans pas très larges. Est-ce une bonne idée du point de vue de l’accessibilité, ou complètement neutre ou néfaste de ce point de vue ?

Ma dernière question sera sur les recommandation sur les retraits pour les formules de maths, qui sont pas mal utilisé dans les articles. Une des solution c’est de les transformer en liste de définition quand c’est possible, mais ce n’est pas toujours pertinent. Ça "marche" quand on veut ou peut nommer une formule (comme dans ma première question). J’ai vu qu’il existait un Modèle:exemple pour mettre en valeur certaines choses en math, il affiche un titre en retrait. Serait-ce pertinent de l’utiliser (ou une variante) pour mettre en valeur une forule de maths ? Est-il accessible ?

TomT0m (d) 27 juillet 2012 à 17:05 (CEST)

• Les tableaux de mise en forme comme dans cet exemple sont un moindre mal. Le remplacement par des listes de définitions n'apporte pas de gain d'accessibilité et présente des risques d'erreur importants (le résultat actuel de l'essai est en fait moins accessible que le tableau : ces listes ne sont pas aisées à utiliser et ne devraient notamment pas être imbriquées).
• Le modèle {{exemple}} est en revanche nettement préférable à l'utilisation détournée de la syntaxe de liste de définition (à condition cependant de ne pas y utiliser... à nouveau des listes de définitions détournées quand on veut y faire figurer d'autres indentations, donc sans faire comme dans les exemples du modèle ).

Cordialement, --Lgd (d) 29 juillet 2012 à 09:53 (CEST)

l’imbrication n’est pas vraiment un problème, elle est supprimable facilement, par contre l’utilisation d'une liste de définition pour une liste d’axiome ne me semble sémantiquement pas idiote. Si l’imbrication de liste de def est un soucis, par contre, ce serait pas mal de prendre ça en compte dans le gadget accessibilité qui ne semble pas y trouver de réel soucis. Sur quel critère tu te base pour dire que ce n’est pas accessible, les outils spécialisés ne gèrent pas ce cas ? Ça pourrait avoir un sens, une sous définition par exemple.

Effectivement les ":" sont parfois utilisés à l’intérieur du modèle exemple, c’est pas génial. TomT0m (d) 29 juillet 2012 à 19:37 (CEST)

Gadget "Ajout d'un lien" dans la barre de menu lors de l'édition d'une page

Bonjour.

Le gadget qui permet de savoir si un lien interne existe et de l'ajouter lors de l'édition d'une page ne fonctionne plus (en tout cas plus chez moi). Le gadget met systématiquement que la page existe même si ce n'est pas le cas. C'est assez récent comme problème, je dirais une dizaine de jours.

Un tout grand merci d'avance de vous pencher sur mon cas!!

Jerome66 (d) 6 août 2012 à 11:19 (CEST)

J'ai le même problème, --Jacques (me laisser un message) -- 15 août 2012 à 21:34 (CEST)

Ce n’est pas le sujet de cet atelier, allez plutôt voir du côté des questions techniques, en précisant de quel script il s’agit. — Ltrl G^☎, le 15 août 2012 à 22:33 (CEST)

Deux petites questions

Salut. Ca faiaist longtemps que je n'étais pas passé ici mais j'ai deux petites questions :

1. La balise <hr> pour créer une ligne séparatrice dans un tableau est-elle accessible ? (à priori oui ?)
2. Dans un tableau comme celui-ci :

Exemple

Aout 2012	Ven 3	Sam 4
Données	xx	yy

Vaut-il mieux mettre {{Abréviation|Ven|Vendredi}} 3 ou {{Abréviation|Ven 3|Vendredi 3 août 2012}}
Perso, je pense que la meilleure solution est la première puisque l'info du mois et de l'année sont déjà reprises dans le scope=row mais je suis pas sûr à 100 %. --'toff ^[discut.] 6 septembre 2012 à 12:20 (CEST)

1. oui : elle n'a pas d'impact en terme d'accessibilité à ce que je sache.
2. oui mais c'est plus du confort que de l’accessibilité stricto sensu, pour éviter les redites si le lecteur est configuré pour restituer les entêtes systématiquement. Mais surtout, il ne faut pas tomber dans la surqualité  : ce qui est écrit dans la case, c'est bien « Vendredi 3 » et pas « Vendredi 3 août 2012 ».

Litlok (m'écrire) 6 septembre 2012 à 13:34 (CEST)

Merci. --'toff ^[discut.] 6 septembre 2012 à 14:08 (CEST)

usage et explicitation de {{unité}}

Bonjour.
Doit-on exploiter le modèle {{abréviation}} et {{abréviation discrète}} pour définir le terme, souvent une unité, en deuxième paramètre de {{unité}} ? Crochet.david (d) 6 septembre 2012 à 18:58 (CEST)

En théorie, vaut mieux, comme toute abréviation… --Pic-Sou 6 septembre 2012 à 20:47 (CEST)

Et en pratique ? j'peux faire tourner mon copain bot pour commencer à travailler sur ce genre d'amélioration. Crochet.david (d) 6 septembre 2012 à 21:45 (CEST)

Attention à la complexité du code. Qu'envisages-tu de remplacer exactement ? Si on se retrouve avec des {{unité|100|{{abréviation discrète|m|mètres}}}} pour écrire "100 m", ça va devenir difficile à comprendre. Orlodrim ^[discuter] 7 septembre 2012 à 22:48 (CEST)

Peut-être pourrait-on créer des modèles genre {{mètre}}, {{newton par kilogramme}}, {{farad}} et autres ? --Pic-Sou 8 septembre 2012 à 18:25 (CEST)

On n'a pas fini avec toutes les multiples et sous-multiples : mm, cm, km pour ne citer que les plus utilisées pour le mètre... --'toff ^[discut.] 8 septembre 2012 à 18:58 (CEST)

Ou bien {{milli}}, {{centi}}… --Pic-Sou 8 septembre 2012 à 22:00 (CEST)

Lgd nous quitte

Bonjour, avez-vous vu que Lgd a décidé de rendre son tablier (définitivement ?). Cet atelier lui doit beaucoup. Nous ne pouvons que déplorer ce départ qui risque de mettre un frein aux importantes avancées réalisée grâce à lui en matière d'accessibilité. Il a toutefois pensé à laisser quelques cailloux blancs sur sa page d'utilisateur, destinés à ceux qui voudraient reprendre le flambeau. J'en reproduit l'encadré ci-contre à l'attention de ceux qui se sentent capables de prendre la relève. --Amicalement, Salix ^[Converser] 19 septembre 2012 à 16:34 (CEST)

Hélas… dommage pour ce départ… Peut-être nous reviendra-t-il… --Pic-Sou 19 septembre 2012 à 18:05 (CEST)

Ce départ m'émeut, même si il était prévisible et difficilement évitable. Je dois beaucoup à Lgd : des enseignements riches, passionnés, critiques, formateurs. Des projets motivants avec des enjeux humains : les populations handicapées. C'est lui qui m'a introduit à l'accessibilité (et indirectement à l'ergonomie). C'est une entrée en matière qui, par la suite, m'a permis de découvrir ma vocation dans l'ergothérapie. C'est une page qui se tourne, mais aussi une page que je n'oublierai jamais. Merci.

Quand à poursuivre ce travail, oui si j'ai le temps. Ma priorité est mon bachelor. Mais j'aimerais bien reprendre certains projets pour les appliquer sur la Wikipédia en anglais. Dodoïste ^{[ dring-dring ]} 23 septembre 2012 à 02:28 (CEST)

Saison des champignons

Bonjour. Peut-on envisager d'adopter le Modèle:Mycomorphbox sur la Wp française sans nuire à l'accessibilité ? Sinon peut-on l'améliorer ? Merci de répondre sur le projet mycologie, juste ici. --Amicalement, Salix ^[Converser] 26 septembre 2012 à 12:16 (CEST)

utilisation du modèle {{lang}}

bonjour

j'ai dernièrement fait une liste des articles que j'ai crées, traduits ou réécrits entièrement et je suis en train de tous les revoir pour améliorer la wikifaction et autres erreurs que j'ai pû laisser passer. j'ai donc lu Wikipédia:Atelier accessibilité/Bonnes pratiques et je me pose une question sur l'usage du modèle {{lang}} pour les titres d'œuvres: faut-il l'utiliser et si oui quand?

par exemple dans l'article Rockers (bande originale) faut-il l'utiliser pour les titres des chansons? ou bien dans Antiétatisme#Écrits antiétatistes pour les titres d'ouvrages en langue étrangère? et que faire dans les modèles {{ouvrage}}, {{article}}, {{lien web}}, etc. (je parle du modèle {{lang}} pas de la caractéristique "lang=") ?

cordialement, Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 7 octobre 2012 à 16:27 (CEST)

Bonjour,

On doit indiquer le changement de langue pour tout, sauf les noms propres et les mots qui sont passés dans la langue courante en français (comme parking, par exemple, dont la prononciation à l’anglaise serait perturbante...). Si un mot comme parking se retrouve au sein d'une phrase entièrement en anglais toutefois, on ne va pas revenir en français rien que pour lui (c'est l'exception à l'exception ). Litlok (m'écrire) 7 octobre 2012 à 16:34 (CEST)

merci de la réponse rapide.

ça fait du du boulot en perspective! la majeure partie de mes contributions sont des traductions... --Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 7 octobre 2012 à 16:50 (CEST)

je viens d'activer le gadget d'accessibilité et il me semble qu'il n'est pas nécessaire d'ajouter le modèle {{lang}} dans les modèles {{ouvrage}}, {{article}}, etc. où la caractéristique "lang=" est remplie. est-ce bien le cas ou faut il bien ajouter {{lang}} dans les titres de ces modèles? cordialement, Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 9 octobre 2012 à 13:18 (CEST)

Tiens à ce propos, j’ai remarqué qu’il n’y avait pas ce paramètre pour {{lien web}}, il y a une raison ? ça pourrait valoir le coup de l’aligner avec les autres. — TomT0m ^[bla] 9 octobre 2012 à 13:34 (CEST)

effectivement, je pensais faire la demande mais comme plein de fois où j'ai proposé quelque chose j'ai été rembarré par des "experts" ou par des cuistres... j'en finis pas faire mon boulot dans mon coin en essayant d'avoir le moins de contacts possibles avec la "communauté" (je sais, c'est pas sociable, mais je suis pas très sociable non plus... ). Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 9 octobre 2012 à 13:44 (CEST)

ici — TomT0m ^[bla] 9 octobre 2012 à 14:03 (CEST)

merci d'avoir pris le temps de faire la demande, j'espère juste que quelqu'un lit la page de demande de modèles (vous aviez répondu à une de mes demandes là bas 2 mois après et certaines demandes semblent attendre des mois, quand elles sont traitées). cordialement, Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 9 octobre 2012 à 15:09 (CEST)

C’est un maronnier. On verra bien. j’ai cru voir une discussion à propos de l’harmonisation des modèles sur le projet KISS, j’en parle là bas aussi. — TomT0m ^[bla] 9 octobre 2012 à 15:52 (CEST)

traduction

bonjour, j'ai besoin de traduire du vocabulaire d'architecture religieuse français anglais. cette possibilité ne m'est plus possible sur la marge de gauche, pourquoi ? Comment avoir le dictionnaire à disposition ?? merci de me répondre. Cordialement Marie Bullard Marie bullard axworthy Marie bullard axworthy discussion.

bonjour,

Ici il faut poser une question avec le lien en haut de page "Poser une question" sinon ça ne crée pas de nouveau paragraphe, et signer votre article avec quatre tildes (~~~~) ou bien avec le bouton représentant la plume bleue signant en haut de la boite de modification (à côté de G et I) voir la page Aide:Signature.

concernant votre question, je n'ai pas bien compris. si vous souhaitez accéder aux articles dans d'autres langues grâce aux liens situés dans la colonne de gauche, ce n'est possible que lorsque l'article possède des articles correspondants dans d'autres langues (qui ne seront pas forcément des traductions exactes, chaque wikipedia étant indépendant).

pour le dictionnaire, regarder le site http://www.wiktionary.org/ qui est un autre site distinct de wikipedia (dans plusieurs langues avec des liens entre les langues).

si je n'ai pas répondu à votre question, merci de la reformuler ou d'attendre que quelqu'un d'autre comprenne mieux le truc que moi...

cette page concerne l'accessibilité des articles (c'est à dire la syntaxe du code wiki des pages) votre question serait peut être mieux sur Wikipédia:Le Bistro (cliquez sur le bouton "nouveau message" en haut de cette page et n'oubliez pas de signer comme je vous ai montré).

cordialement, --Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 9 octobre 2012 à 11:10 (CEST)

Tablaux triables :Tri1

Le modèle {{Tri1}} pose un problème d’accessibilité. Suite à la dernière mise à jour de MediaWiki, il y a une possibilité pour résoudre ce problème.

Je propose donc de remplacer le code de Tri1 par le code suivant :

<includeonly>data-sort-value="{{{1|}}}"|</includeonly><noinclude>{{Documentation}}</noinclude>

Merci de faire vos remarques sur la page du projet modèle Si vous ne voyez pas d'erreur ou de risque avec ce nouveau code, je ferai la demande de modification à la fin de la semaine.

— Zebulon84 (d) 9 octobre 2012 à 17:21 (CEST)

Suite à la remarque de Orlodrim, on efface tout et on recommence

Nouvelle proposition :

Comme les tableaux triables sont activés et fonctionnent avec javascript, il est possible de s'appuyer dessus. Donc avec le code suivant pour {{Tri1}} ne devrait plus gêner les utilisations actuelles :

<span class=sortkey data-sort-value="{{{1|}}}">&zwj;</span>

note : le &zwj; sert à obliger MediaWiki à conserver le span, sans pour autant afficher quoi que ce soit. Si vous avez une meilleure méthode je veux bien l'adopter.

L'ajout du javascript suivant copie l'attribut data-sort-value dans la cellule contenante :

addOnloadHook(Add_dataSortValue);

function Add_dataSortValue() {
	var dsvRow, dsv, i;
	dsv = getElementsByClassName(document.body, 'span', "sortkey");
	for(i = 0, m = dsv.length ; i < m ; i++) {
		dsvRow = dsv[i].parentNode;
		if (dsvRow.nodeName.toLowerCase() == 'td') {
			dsvRow.setAttribute("data-sort-value", dsv[i].getAttribute("data-sort-value") );
		}
	}
}

Suis-je encore passé à coté d'un élément essentiel ? Pour vos remarques,c'est toujours sur la page du projet modèle.

— Zebulon84 (d) 9 octobre 2012 à 22:21 (CEST)

Suite à mes proposition et aux modifications réalisées par Orlodrim, le modèle {{Tri1}} n'insère plus de texte parasite dans les tableaux, si ce n'est éventuellement un &zwj;.

Pouvez-vous confirmer que les tableaux triables n'ont plus de raison d'être déconseillé du fait d'une mauvaise accessibilité, ou préciser quels sont les problèmes restant ?

— Zebulon84 (d) 18 novembre 2012 à 12:19 (CET)

modèle {{lang}} dans les modèles {{ouvrage}}, {{article}}, etc.

je viens d'activer le gadget d'accessibilité et il me semble qu'il n'est pas nécessaire d'ajouter le modèle {{lang}} dans les modèles {{ouvrage}}, {{article}}, etc. où la caractéristique "lang=" est remplie. est-ce bien le cas ou faut il bien ajouter {{lang}} dans les titres de ces modèles? cordialement, Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 9 octobre 2012 à 17:43 (CEST) (je ressors ça de la discussion ci-dessus pour plus de lisibilité)

Le paramètre langue= présent dans les modèles {{ouvrage}}, {{article}} insère automatiquement le modèle {{lang}}. Il est donc inutile de le rajouter. Ce n'est pas le cas pour le modèle {{lien web}} et cela ne doit pas l'être (pour plus de précision sur ce cas, voir une vieille discussion ici) --'toff ^[discut.] 9 octobre 2012 à 21:48 (CEST)

Je vois personnellement plus de pour que de contre sur ce point. ~Hlm Z. [@] 9 octobre 2012 à 22:11 (CEST)

Je ne suis pas sur d’adhérer aux arguments de lgd (d · c · b). Le paramètre sur lien web ne s’appelle pas libellé mais bien titre, ce que j’interprète comme le titre de la page ... donc localisé. D’ailleurs tous les exemples de la page {{lien web}} sont des titres de page non traduits sans utilisation du modèle {{lang}} pour les signaler ... j’ai comme l’impression qu’on a des progrès à faire en cohérence et en documentation, perso je vois pas de bons arguments pour que ce modèle ne soit pas cohérent avec les autres. C’est une remarque récurrente d’ailleurs. Les usages peuvent justifier, mais les deux cas cohabitent : le titre en VO sans le modèle lang il y a fort à parier, et des "titre" traduits improvisés qui sont plus des libellés ou des intitulés du coup ... bref, pas terrible tout ça :-/ — TomT0m ^[bla] 9 octobre 2012 à 22:17 (CEST)

"tu interprètes", c'est bien là que le bât blesse. Chacun peut-il interpréter différemment ? Probablement. Les exemples ne sont que des exemples (s'ils omettent le modèle lang, c'est une erreur selon mon interprétation) et rien n'oblige un contributeur à ne pas traduire le titre d'un lien web... Je ne dis pas qu'il ne faut pas un paramètre langue signalant la langue de l'article (et donc insérant automatiquement le modèle {{en}}) mais je dis qu'il ne faut pas que ce paramètre ajoute systématiquement le modèle {{lang}} autour du titre puisque ce n'est pas forcément vrai. De plus, sous couvert d'uniformité (ce qui est louable certes), on va se heurter à plusieurs gros problèmes :

1. Si le modèle est modifié pour systématiquement ajouter {{en}} et {{lang}}, comment éviter les doublons dans les articles correctement balisés (j'entends avec ces deux modèles ajoutés au modèle {{lien web}}) ? Les bots vont avoir du boulot...
2. Si on fait appel aux bots, comment vont-ils définir que le titre n'a pas été traduit ? (ça ne me semble pas possible, ça ?)

Que ce modèle ne soit pas bien documenté/utilisé/paramétré, c'est un point de vue qui se défend et je suis d'accord avec l'essentiel des remarques, mais en l'état, on ne peut pas le modifier sans impacter négativement un nombre considérable d'articles malheureusement. --'toff ^[discut.] 9 octobre 2012 à 23:25 (CEST)

Et pourquoi s'embêter à traduire un titre quand le lecteur ne comprendrait pas un traître mot de l'article --Amicalement, Salix ^[Converser] 9 octobre 2012 à 23:30 (CEST)

C’est un faux problème, les articles présents ne seraient pas impactés. Il ne possèdent pas de paramètre lang, et on ne va pas leur rajouter des paramètres lang automatiquement ... donc ils resteraient exactement comme ils sont aujourd’hui, considérés comme titrés en français. Rien à faire avec les bots. La situation ne serait ni meilleure, ni pire. — TomT0m ^[bla] 9 octobre 2012 à 23:39 (CEST)

en fait, comme je ne voyais personne répondre j'ai regardé le code des modèles et je me suis affectivement aperçu que des modèles {{lang}}étaient insérés si on renseignait titre, sous-titre etc. par contre ça ne marche pas partout:

• {{ouvrage}} : ça marche pour "titre=" et "sous-titre=" (pas de problème) ;
• {{article}} : ça marche pour "titre=" mais pas pour "périodique=" ;
• {{chapitre}} : ça marche pour "titre chapitre=" mais pas pour "titre ouvrage=" ni "sous-titre ouvrage=".

concernant le changement du modèle lien web ça serait bien, ajouter des modèles lang dans d'autres modèles complique vraiment la lecture du code. comme dit tomtom, changer le modèle n'apporterait pas de changement vu que les anciennes syntaxes ne possèdent pas de paramètre "lang=". ne rien vouloir toucher à cause des choses existantes "qui marchent très bien comme ça" est réactionnaire : c'est comme si on ne voulait pas faire du super sans plomb sous prétexte que les anciennes voitures ne le supporteraient pas. autant changer les choses rapidement pour avoir le moins à modifier par la suite selon moi, d'autant plus que le modèle lien web ne fait pas du tout la majorité pour l'instant, même dans certains AdQ ou BA. --Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 10 octobre 2012 à 01:21 (CEST)

J'apprécie moyennement de me faire traiter de "réactionnaire", je te suggère de modérer tes propos. Cordialement. --'toff ^[discut.] 10 octobre 2012 à 06:35 (CEST)

bonjour, je ne traite personne de réactionnaire, je parle de la situation qui est réactionnaire, désolé si mes propos ont été mal interprétés. cordialement, --Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 10 octobre 2012 à 14:26 (CEST)

Comment effacer utilisateur dans le titre

Bonjour j'ai créé une page pour ma société Euroshopled, mais le problème est que quand je fais une recherche sur le site wikipedia il m'affiche : "utilisateur:Euroshopled", comment puis-je enlever cela ?

Merci, cordialement--EUROSHOPLED (d) 19 octobre 2012 à 16:04 (CEST)

bonjour, ce n'est pas le bon endroit pour demander ça, cette page concerne l'accessibilité web des contenus de Wikipédia en particulier pour les personnes handicapées, et d'aider les contributeurs qui souhaitent améliorer celle-ci ou en tenir compte dans leur travail quotidien, pour ce genre de question, consulter l'aide ou poser la question sur le bistro par exemple.

mais de toutes façons l'article à été effacé par theoliane car il ne répond pas aux critères en vigueur concernant les entreprises. pour répondra à la question, c'est parce que vous avez créé l'article sur votre page utilisateur, pas dans la partie encyclopédique. pour créer un article il faut taper le nom recherché dans la boîte de recherche en haut à droite et si l'article n'existe pas, il vous sera proposé de le créer sur la page suivante. mais ça ne sert à rien de recréer un article s'il n'a pas de valeur encyclopédique.

cordialement, Ѕÿϰᚁα×₮ɘɼɾ๏ʁ ^{«You talkin' to me?»} 19 octobre 2012 à 17:22 (CEST)

tooltipRef / Reference Tooltips

Hello ,

J'attire votre attention sur cette discussion, où il est question de l'éventuelle activation par défaut d'un gadget combinant les avantages des deux mentionnés dans le titre de cette section.

En particulier, vos avis sur le mode d'activation par défaut sont bienvenus : la Wikipedia anglophone a opté pour une apparition au survol, mais pour moi c'est une erreur.

Amicalement — Arkanosis ^✉ 26 octobre 2012 à 01:38 (CEST)

Wikidata

Pour ceux que ça intéresse, un projet similaire semble avoir été créé sur Wikidata (Wikidata:Accessibility).— Ltrl G^☎, le 31 octobre 2012 à 21:48 (CET)

…qui a été traduit en français : Wikidata:Accessibilité — Ltrl G^☎, le 3 novembre 2012 à 00:22 (CET)

Et il y a du boulot parce que le site ne fonctionne qu'avec JavaScript activé, pour le moment… — Arkanosis ^✉ 3 novembre 2012 à 14:45 (CET)

JavaScript est une technique dite compatible avec l'accessibilité. Il n'est plus nécessaire de fournir une alternative pour qu'un contenu soit accessible, mais il faut s'assurer que le JS est mis en œuvre d'une manière compatible avec l'accessibilité (contrôles clavier/souris, code produit accessible, manière d'ajouter du contenu compatible avec le DOM, etc.). Litlok (m'écrire) 4 novembre 2012 à 00:09 (CET)

Hm, c'est pas vraiment un projet d'accessibilité pour l'instant. C'est un collègue du projet d'accessibilité sur EN qui a simplement posté cette page, comme ça. À vrai dire, je ne sais pas dans quelle mesure l'utilisateur a un impact sur l'accessibilité de Wikidata. Pour autant que je puisse voir à l'heure actuelle, le contributeur ne peut pas faire autre chose que d'envoyer un court texte dans un formulaire. Ce qui est vraiment à évaluer c'est l'accessibilité de l'interface, qui relève des développeurs de MediaWiki. Donc, bon, je sais pas trop à quoi cette page va servir pour le moment. Dodoïste ^{[ dring-dring ]} 8 novembre 2012 à 16:42 (CET)

Je ne suis pas d'accord : il y a un tas de raisons de ne pas avoir JavaScript, que ce soit en utilisant des navigateurs ou des outils qui ne le supportent pas ou mal, des terminaux peu puissants, ou volontairement pour des raisons de sécurité (NoScript, Tor…). Tu me diras, dans ce contexte là on peut se demander ce que le visiteur peut bien faire sur Wikidata, mais il n'empêche : ce n'est pas accessible (et je sais que mon acception d'« accessibilité » n'est pas forcément celle de tout le monde sur cette page — Lgd m'avait déjà fait la remarque).

Amicalement — Arkanosis ^✉ 9 novembre 2012 à 01:29 (CET)

L'approche « accessibilité universelle » est sympathique, mais il s'agit de problèmes et non des vues de l'esprit quand on s'occupe d'accessibilité tout court. Ici, par exemple :

• l'absence d'appui sur des documents normatifs, voire la présence de documents normatifs qui disent le contraire (la présence d'une l'aternative à javascript n'est plus nécessaire). Difficile de communiquer efficacement avec des développeurs sur cette base.
• soutenir la nécessité d'une alternative de principe à javascript est très vague. Cela ne sera une amorce de discours opérationnel que si on parvient à fournir une grille différenciant des multiples situations dans une large palette qui va des applications en ligne dont l'alternative sans js n'a plus aucun intérêt ergonomique et constitue un développement supplémentaire à part entière jusqu'aux détails d'interface dont l'intégration en js non obstructif est trivial.
• mettre en avant cette idée d'alternative à javascript a un énorme défaut à l'usage : cela rend encore plus difficile de faire comprendre ce qui est la première priorité dans ce domaine, c'est à dire que les devs/intégrateurs/etc. fournissent des éléments d'interface js qui soient intrinsèquement accessibles, c'est à dire ne produisant pas d'images sans alt, de fausses icônes simulées en javascript, de l'interaction inutilisable au clavier, ou du DOM généré par un chimpanzé sous LSD. Quand on explique à des développeurs/etc. que oui, certes, leur truc fonctionne de manière accessible si on désactive javascript, mais que non, ça n'est pas la question prioritaire pour la majeure partie des gens concernés chez qui javascript n'est pas désactivé... Cela ne le fait pas ou très péniblement. Cette idée sympathique de l'accessibilité universelle qui s'illustre par le cas du "ça doit le faire sans javascript" est... sympathique, mais truffée d'effets pervers non évalués.

Bref : la priorité n'est pas la question de faire marcher ou non sans javascript. La question est d'abord d'avoir du js correct qui produit un résultat accessible. --94.140.9.43 (d) 9 novembre 2012 à 12:42 (CET)

Il y a méprise, je ne dis nulle part qu'un fonctionnement possible sans JavaScript justifierait qu'on ne s'occupe pas de l'accessibilité avec Javascript.

Mais je n'ai pas besoin d'un document normatif pour constater qu'un site qui dépend de JavaScript est difficilement utilisable sur mon téléphone et inutilisable quand je suis les recommandations d'usage du Tor Browser, par exemple. — Arkanosis ^✉ 9 novembre 2012 à 18:20 (CET)

L'article Modèle:Etc. est proposé à la suppression

Bonjour, L’article « Modèle:Etc. » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). Après avoir pris connaissance des critères généraux d’admissibilité des articles et des critères spécifiques, vous pourrez donner votre avis sur la page de discussion Discussion modèle:Etc./Suppression. Le meilleur moyen d’obtenir un consensus pour la conservation de l’article est de fournir des sources secondaires fiables et indépendantes. Si vous ne pouvez trouver de telles sources, c’est que l’article n’est probablement pas admissible. N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

TED 8 novembre 2012 à 14:14 (CET)

Je préviens l'atelier accessibilité, car l'accessibilité est un argument qui intervient dans la discussion. TED 8 novembre 2012 à 14:14 (CET)

Bof, on se demande ce qu'il gagne à être mal pris en compte dans une discussion par ailleurs aussi confuse. --94.140.9.43 (d) 9 novembre 2012 à 12:14 (CET)

Modèle {{Langue du titre}}

Bonjour, j'ai intégré il y a peu ce modèle dans pas mal de page dont le titre est entièrement en anglais. Ma question est : faut-il intégrer ce modèle {{langue du titre|el}} pour les titres en grec translittéré ou uniquement en grec ? De même pour le russe ? Merci d'avance pour vos réponses. Mith (What ? You're talkin' to me ?) - Angers, le 12 novembre 2012 à 13:15 (CET)

Explication d'abréviation

Salut (ça faisait longtemps que j'étais passé par ici). Une petite question (ou plutôt une confirmation) : si je dis pas de bêtise, les abréviations doivent être expliquées mais il me semble que quand elles le sont une fois il n'est pas utile de le faire à nouveau. Par exemple pour les heures/minutes/secondes (cas qui m'intéresse en l'occurrence) : 10 h 5 min 2 s (abréviation discrète grâce au modèle {{heure}}) suivi de 14 h 15 min 7 s. Est-ce suffisant ? Question subsidiaire : si les deux mentions d'heures sont très éloignées les unes des autres, doit-on à nouveau préciser ou la première mention suffit ? --'toff ^[discut.] 24 décembre 2012 à 11:51 (CET)

---

Ajout du comte Nemoi – Bonjour Supertoff, et joyeux Noël. Tu mélanges deux choses : le fait de simplifier la lecture du texte pour tous, en explicitant une fois les abréviations (abr.) que tu vas utiliser dedans ; et le fait de simplifier la compréhensions d’une personnes utilisant un iPhone lecteur d’écran, en faisant qu’à la lecture, les abr. usuelles utilisées soient correctement lues par l’appareil. Le modèle : Heure doit donc être utilisé systématiquement, pour éviter qu’un iPhone lecteur d’écran ne comprenne pas l’abr. et ne lise « 14 haches 15 mains 7 est-ce » en voyant « 14 h 15 min 7 s ».

Le cas principal des abr. explicitées dans le texte est celui du « abr. » de ma réponse : toutes les abr. devraient être précisés avec le modèle : Abréviation discrète, car on ne veut pas sentir qu’il y a une abr. à la lecture par un appareil. Le problème est au niveau de la définition de l’abréviation, le « abréviations (abr.) », où l’on ne veut pas que le lecteur d’écran nous dise « abréviations ha bée air » ni « abréviations abréviations », on voudrait juste qu’il lise une fois « abréviations ». Pour diverses raisons, la solution actuelle pour gérer le « abréviations (abr.) » est d’utilise le modèle : Abréviation pour rendre « abr. », ce qui convient à la plupart des usages recomandables dans une encyclopédie (voir par exemple cette section avec un seul usage du modèle : Abréviation et un certain nombre du modèle : Abréviation discrète).

Avec sympathie, ce 25 décembre 2012 à 18:51 (CET).