Wikipédia:Demande d'intervention sur un message système/Archives 2011

Pages où apparaît ce message : Méta palette de navigation

Changement proposé : Bonjour,

Je propose quelques projets au sujet de notre bonne veille Méta palette française. En effet celle-ci est basée sur un modèle ancien et devrait être mise à jour au plus vite. Tôt ou tard, les idées que je vais donner ci-dessous vont être forcement utilisées, car se base sur le modèle [[en:]] (inévitable de toute manière).

Voilà les idées en question:

  • Renommer Méta palette de navigation par Métabox (et non Navbox pour quand même garder une certaine originalité).
  • Remplacer "[[Dérouler]]" par <small>[[[[Dérouler]]]]</small>, c'est ce qui permet d'ouvrir la palette ("Dérouler" par [[Dérouler), cela permettra de gagner 2 à 3 pixels (sachant que le tnavbar est par défaut en minimal).
  • Ajouter de nouvelles icônes pour "|dessous =" (icône "portail" présente sur la palette Half-Life), elle pourrait alors remplacer les liens internes (portail, catégorie, livre, projet...).
  • "|stylegroupe = width:100px;text-align:right;"

Pour le "|stylegroupe =", "width" doit être par défaut 100px et non 150px ce qui rendrait la palette d'une part moins lourde et d'autre part l'espace "|listeX =" serait alors agrandi, de même pour "text-align:right;" (moins lourd, plus d'espace pour la liste, de 20 à 50px gagner, amplement bénéfique).

Autres idées:

|stylepair  = background:#F5F5F5;        (modèle en:, point de vue seulement esthétique)
|stylecorps = background:#FFF;           (modèle en:)


Quelques exemples:


Une discussion a déjà été entamée (#) à propos de ce sujet.

~force92i (@) 22 janvier 2011 à 18:26 (CET)Répondre[répondre]

<soupir>
Comme déjà dit précédemment, ce n'est pas un problème de message système, mais de page protégée. Ici n'est donc pas la bonne page pour avoir des avis (avis déjà donné par ailleurs dans la section donnée en lien).
Concrètement :
Il serait beaucoup mieux pour celui qui éventuellement accèdera à ta requête de proposer dans ton espace utilisateur une copie du modèle tel que tu le voudrais (avec éventuellement un js et un css modifié et que tu auras pris soin de tester), plutôt qu'effectuer une requête aussi imprécise que celle-ci.
⇨ Dr Brains ∞ Consultation ∞ 22 janvier 2011 à 19:30 (CET)Répondre[répondre]
C'est Lgd qui m'a dit de poster ici, j'ai l'impression que je suis le seul ou sa pose problème, les modèles [[]] sont dépassées. ~force92i (@) 22 janvier 2011 à 19:52 (CET)Répondre[répondre]
Soupir aussi. Ce que je vous avais expliqué, c'était que si vous aviez une modification des styles CSS appliqués via des classes dans ce modèle, c'était ici qu'il fallait la proposer. Je ne vois rien de tel ci-dessus. Cela dit, vous êtes effectivement le seul à qui les questions que vous abordez à nouveau ci-dessus pose un problème criant. --Lgd (d) 22 janvier 2011 à 19:56 (CET)Répondre[répondre]
|stylepair   = background:#F5F5F5;        (modèle en:, point de vue seulement esthétique)
|stylecorps  = background:#FFF;           (modèle en:)
|stylegroupe = width:100px;text-align:right;

Ceci répond à ton soupir?

C'est dingue comme tu me prends de si bas, c'est pas parce que je ne suis pas admin que tu dois me traiter ainsi... Mon problème est claire, je veux que "|stylegroupe = width:100px;text-align:right;" soit par défaut, malheureusement, je ne peux intervenir. ~force92i (@) 22 janvier 2011 à 20:25 (CET)Répondre[répondre]

La consensualité de ces changements de styles width:100px et text-align:right reste à établir, ce qui ne me semble pas acquis. od†n [dead words] 22 janvier 2011 à 20:33 (CET)Répondre[répondre]
Force92i, j'ai l'impression que tu ne mesures pas les conséquences de ce que tu demandes. Le modèle {{Méta palette de navigation}} est inclus dans pas moins de 16 451 modèles, eux-mêmes inclus dans pas moins de 279 596 pages. Tu devrais être à même, au vu de ces chiffres, de comprendre la réticence à tout changement.
Es-tu capable de dire avec une certitude absolue que les changements que tu proposes sont souhaités/souhaitables dans tous ces modèles ? Pour combien de ces milliers de modèles ces changements poseront problème et rendront une intervention obligatoire ? Est-ce que tu t'engages à réparer ces dommages collatéraux et à porter sur tes seules épaules les critiques qui ne manqueront pas d’être formulées de-ci de-là ? J'en doute.
Et cela n'a rien à voir avec le fait d’être admin ou pas. Le fait est que tu es nouveau sur Wikipédia (du moins sous ce nom), et que visiblement sitôt arrivé tu n'a rien de plus pressé que de modifier l'un des modèles les plus utilisés. Rien d’étonnant à ce que quiconque te demandes de prendre un peu de recul avant de foncer tête baissée.
⇨ Dr Brains ∞ Consultation ∞ 22 janvier 2011 à 21:46 (CET)Répondre[répondre]
Ce ne sont que des idées, je ne vous oblige pas à tout changer, mais il y'a des choses qui me paraissent évidentes. Je reste convaincu que le text-align:right sera tôt ou tard mise en service, je ne vois pas en quoi ceci est contraignant, au contraire !
Enfin bon, ce n'est pas grave je laisse tomber, cela ne sert à rien de continuer en vain sans résultat, pourtant on ne va pas me dire que je n'ai pas tout essayé. ~force92i (@) 22 janvier 2011 à 22:04 (CET)Répondre[répondre]
Concernant un renommage du modèle, ou du moins une redirection, je trouve l'idée intéressante, par contre je ne trouve pas super le nom « Navbox », qui prête trop à confusion avec les infoboxes... Enfin, les discussions et débats sur le modèle devraient se poursuivre ailleurs que sur cette page, qui devrait – du moins idéalement – s'en tenir à des fonctions purement administratives, i.e. l'application de modifications techniquement prêtes et au consensus établi. od†n [dead words] 22 janvier 2011 à 23:38 (CET)Répondre[répondre]
Vu le profil un peu curieux de ce contributeur, le désordre de ses propositions bricolées et les soucis qu'elles suscitent, je pense que cela devrait vraiment se cantonner au moins dans une premier temps dans son espace utilisateur. Voir à ce sujet ce message un peu récapitulatif. Cordialement, --Lgd (d) 23 janvier 2011 à 10:36 (CET)Répondre[répondre]

Pour info : MediaWiki: Common.css, gestion de la couleur des abbrModifier

Bonjour,
Suite à un problème remonté sur l'atelier accessibilité, j'ai étendu à tous les usages de abbr ce qui était déjà le cas pour le modèle {{abbr}} via cette modification de common.css. C'est à dire que le contenu de l'abréviation hérite sa couleur de son parent, au lieu d'être obligatoirement noir par défaut. Ayant testé avant, je n'ai pas rencontré de problème dans les pages de l'interface où l'élément abbr est utilisé, comme la liste des RC par exemple. Je n'ai pas étendu à la couleur de bordure (qui produit le soulignement pointillé) : je ne suis pas certain de l'absence d'effets de bords dans des modèles ou des cas exotiques. Quelqu'un a une idée à ce sujet ? Cordialement, --Lgd (d) 23 janvier 2011 à 10:02 (CET)Répondre[répondre]

Pages où apparaît ce message : Spécial : Pages non catégorisées (l’objectif), d’autres ?

Changement proposé : NEMOI, à 20 heures 33, le 24 janvier 2011. − Mon soucis sur Spécial : Pages non catégorisées, est de ne pas savoir si j’ai « récemment » (dans la journée) rafraîchi la page. Serait-il possible d’inclure dans le message (sur la page MediaWiki:Perfcachedts ? je crois…) la date « actuelle », celle de génération de la page ?

Heu…
Dans la mesure où l'actualisation ne dépend aucunement de toi, et que comme l'indique le message les données sont en cache, c'est à dire qu'elles ne sont pas (plus) générées lors de la requête de la page, je ne vois pas quelle date tu voudrais voir ajoutée au message.
⇨ Dr Brains ∞ Consultation ∞ 24 janvier 2011 à 21:03 (CET)Répondre[répondre]
NEMOI, à 21 heures 33, le 24 janvier 2011. − C’est celle de chargement de la page qu’il me faudrait, en plus de celle d’actualisation des données. Car c’est une page que je sais garder plusieurs jours ouverte, car je ne parcours pas la liste en un jour ; résultat, je me sens obligé de la rafraîchir (les trois quarts du temps inutilement) à période régulière, ne sachant plus quand je l’ai chargé la dernière fois (espérant que le cache ait été mis à jour). Bon, si tu n’as pas compris après ce message, tu classes la demande, on ne va pas non plus perdre du temps là-dessus.
Tu fais 'Fichier > Enregistrer sous ... > xxxx
Et si tu ne sais plus quand tu l'a fait la dernière fois, tu utiles ton gestionnaire de fichiers pour voir la date de "ta" page, non ? TIGHervé 24 janvier 2011 à 21:50 (CET)Répondre[répondre]
NEMOI, à 22 heures 01, le 24 janvier 2011. − Le but est de gagner quelques rafraîchissements de page, pas de perdre du temps.   Bon, ne vous prenez pas la tête, c’est juste un confort d’utilisation, ça changera pas ma vie.

Je ne suis pas sûr d'avoir trop compris, mais cela ne devrait pas gêner d'essayer de mettre le code de date de Wikipédia:Le Bistro/En-tête, à savoir :

<div style="float:left;font-size:0.8em">
(<tt>{{#time:d/m/Y H:i:s|0 days+{{#invoke:Date|CEST|décalage}}hours}} [[Central European {{#ifexpr:{{#invoke:Date|CEST|décalage}}=2|Summer_}}Time|<span style="color:#484436;text-decoration:underline">CE{{#ifexpr:{{#invoke:Date|CEST|décalage}}=2|S}}T</span>]]</tt>)
</div>

et de demander à Nemoi si cela lui convient. C'est très discret. Teofilo 27 janvier 2011 à 15:38 (CET)Répondre[répondre]

C'est surtout sans rapport avec la question, désolé. Outre qu'il ne s'agit pas du Bistro, il ne s'agit pas non plus de cette date-là. Cordialement, --Lgd (d) 27 janvier 2011 à 16:00 (CET)Répondre[répondre]
Laisse Nemoi répondre, et nous dire si c'est cette date là qu'il veut. Mais la meilleure façon pour que Nemoi puisse savoir si cela lui convient ou non, c'est de le laisser faire un essai. Le code présent dans Wikipédia:Le_Bistro/Heure_d'été est un calcul d'heure d'été qui vaut pour tous les pays, et il peut être utilisé ailleurs que sur le bistro. Teofilo 27 janvier 2011 à 16:10 (CET)Répondre[répondre]
Ce n'est pas une question de laisser X ou Y répondre à Z : c'est juste sans rapport avec la question. Techniquement, formellement, ce-que-tu-voudra-ment. Ce que j'expliquais assez gentiment ci-dessus, mais que là, je ré-explique beaucoup moins gentiment parce-ce que tu fais du bruit pour rien et pour le plaisir. Cordialement, --Lgd (d) 27 janvier 2011 à 16:22 (CET)Répondre[répondre]

MediaWiki: Common.css, problème de tableauModifier

Pages où apparaît ce message :

Changement proposé :
Bonjour, après avoir parlé tout seul sur Wikipédia:Questions_techniques/semaine_52_2010#Problème_Webkit, je soumets ma requête ici pour avis et action si cela vous parait correct.

Redite résumé de mon propos sur WP:QT

Avec Webkit, les tableaux centrés ne voient pas les blocs flottants à droite et débordent dessus.

  • Exemple (à faire sous Chrome bien sûr) : Agrandir le tableau à coup de Ctrl+ si votre écran est large pour voir l'effet.
Tableau 1 : Composition en % (massique) de colorants dans le jus de fruit du figuier de barbarie.
Colorants Jus de fruit orangé Jus de fruit violacé
Indicaxanthine 0,245% 0,022%
Bétanine 0,027% 0,307%

D'après un de mes honorables correspondants, le problème vient du margin: 0 auto qui n'a pas l'air de fonctionner avec Chrome. Il semble que l'on puisse hacker le problème en écrivant (attention à vérifier car j'ai adapté son explication pour WP) dans MediaWiki:Common.css

  • après la ligne
    @media screen and (-webkit-min-device-pixel-ratio:0) {
  • la ligne
    table.centre, table.center { margin:1em 0.8em;}


Cordialement - Drongou (d) 5 janvier 2011 à 23:09 (CET)Répondre[répondre]

Bonjour - Souvent quand on parle seul, c'est que la question déborde trop largement les capacités des lecteurs du message. C'est aussi le cas pour moi ici, mais je ne suis pas une référence en la matière.
Attendons plus compétent. TigHervé 6 janvier 2011 à 10:17 (CET)Répondre[répondre]
Bonjour,
Dans la mesure où il s'agit d'un bug de navigateur a priori temporaire et de portée limitée, je ne suis pour ma part pas favorable à l'ajout d'un patch dans Common.css (qu'on oubliera inévitablement de retirer par le suite). Cordialement, --Lgd (d) 6 janvier 2011 à 10:44 (CET)Répondre[répondre]
Avec ce que j'ai compris, c'est aussi l'« impression » que j'ai eue. TigHervé 6 janvier 2011 à 10:51 (CET)Répondre[répondre]
OK merci, finalement je suis assez d'accord sur cette vision des choses.
De plus, j'ai fini par trouver (un peu tard) le bug qui va bien https://bugs.webkit.org/show_bug.cgi?id=47570 ouvert par la WP polonaise ! pour la page Ninhydryna. À suivre donc. Cordialement - Drongou (d) 6 janvier 2011 à 23:17 (CET)Répondre[répondre]

Page où apparaît ce message : Intitulé de Spécial:Ouvrages de référence

Changement proposé : Ouvrages de référence --> Recherche de livre par ISBN

Le terme actuel "ouvrage de référence" est contresens ou un faux sens. Comme l'indique l'article ouvrage de référence cette expression désigne habituellement les encyclopédies et les dictionnaires. On ne peut donc pas l'utiliser pour désigner la plupart des livres (romans, essais, ouvrages scientifiques etc...). Teofilo 27 janvier 2011 à 15:29 (CET)Répondre[répondre]

  Non Demande à traiter via translatewiki.net, outre le fait que le changement demandé serait inconséquent avec le « Rechercher parmi des ouvrages de référence » dans la même page. --Lgd (d) 27 janvier 2011 à 15:33 (CET)Répondre[répondre]
Je ne suis pas du tout d'accord et je dénonce cette attitude sur http://lists.wikimedia.org/pipermail/foundation-l/2011-January/063601.html Teofilo 27 janvier 2011 à 16:30 (CET)Répondre[répondre]
Protéger les contributeurs des projets envers les agressions commises par des projets qui ne sont pas dans le projet... Oui, c'est la fin du monde. Comme d'hab. Cordialement, --Lgd (d) 27 janvier 2011 à 16:38 (CET)Répondre[répondre]


Pages où apparaît ce message : Quand on affiche la différence entre plusieurs versions

Changement proposé : « annuler », cf. Discussion MediaWiki:Editundo (à noter aussi que 3-4 autres messages sont calés sur celui-ci)

Les contributeurs « défont » et les administrateurs « révoquent », les deux opérations consistant à annuler une ou plusieurs éditions précédentes. Est-il vraiment indispensable de changer un terme à présent bien entré dans les usages ? Hum... Cordialement, --Lgd (d) 3 janvier 2011 à 17:03 (CET)Répondre[répondre]
Je sais que ce terme est rentré dans les usages et c'est pourquoi je lance le débat avant d'agir. Quand les administrateurs révoquent on voit dans le résumé « révocation des modifications de ... ». « Undo » ne doit pas à mon avis être traduit littéralement et le piège est que le nom n'existe pas (« défaisage » ??), ce qui engendre une incohérence entre l'action et le résultat de l'action. Certes c'est ce que j'appelle taper une mouche avec un marteau et il y a des débats plus importants mais autant être précis. Wyz (d) 3 janvier 2011 à 17:10 (CET)Répondre[répondre]
Le changement des usages est en effet à faire avec précaution. Si la modification est acceptée, est-ce que tu - Wyz - serais prêt à mettre à jour les pages d'aides qui parlent de ce sujet ? Et à lister les autres messages systèmes qui utilisent ce même terme, afin de corriger de manière cohérente ?
Sur le fond, je suis assez d'accord. « Défaire » n'est pas un terme très courant et intuitif pour ce genre d'actions. Et puis : « défaire, dans le sens défaire en petits morceaux ? » Voir wikt:défaire : ce mot n'est que rarement utilisé dans ce contexte, et est en général associé à d'autres actions. C'est bien « annuler » qui est commun ici.
Donc le changement d'habitude est peut-être délicat à passer. Mais sur le long terme, c'est certain que ce serait plus intuitif. Après, c'est une petite chose parmi d'autres. Mais je suis d'avis que ce sont ce genre de petites choses qui permettent de faire progresser l'ergonomie de Wikipédia, petit à petit. Dodoïste [ dring-dring ] 3 janvier 2011 à 18:26 (CET)Répondre[répondre]
NEMOI, à 20 heures 40, le 3 janvier 2011. − Aucune des définitions sur le wiktionnaire de « défaire » ne correspond à l’action effectuée (sinon la quatrième…), à l’inverse de celle du terme « annuler ». Je suis plutôt pour ce changement, pour lequel je ne vois qu’un seul problème d’usage : comment on appelle le fait de « désannuler » une action, maintenant ?
« Rétablir » ? Marin 3/01/11 20:49
Annuler me parait trop vague. Defaire c'est dans le langage usuel, faire l'inverse de ce qui a été fait, et rétablir dans la situation précédente Ursus (d) 3 janvier 2011 à 20:52 (CET)Répondre[répondre]
Undo est plus proche de défaire que d'annuler (cancel en anglais)... mais bon une fois de plus sur WP, faire et défaire c'est toujours faire quelque chose. --GdGourou - Talk to °o° 3 janvier 2011 à 20:54 (CET)Répondre[répondre]
@Ursus : on ne doit pas avoir le même language usuel. Il y a certes des différences culturelles entre nos deux régions, mais tout de même... Quand un chevalier « défait ses adversaires », il fait l'inverse de ce qu'il a fait, et les rétablit dans la situation précédente ? Non, plus sérieusement, « annuler » est très utilisé et informatique et sur le Web, exactement pour cette action. Défaire n'est jamais utilisé à cette fin, sauf sur Wikipédia et quelques sites assez fous pour copier la traduction imparfaite...
@GdGourou : En l'occurence, la traduction et le terme original n'ont que peu d'importance. Au contraire il faut se détacher de la traduction. Ce n'est pas juste un sens littéraire qu'on traduit ici. C'est des usages, une habitude culturelle, une intuitivité... « Undo » est le terme utilisé dans ce contexte en langue anglaise, il n'y en a pas deux pour annuler une action. C'est « undo ». En français, l'usage en interface informatique est « annuler ». C'est tout ce qu'il est important de prendre en compte. Dodoïste [ dring-dring ] 3 janvier 2011 à 21:04 (CET)Répondre[répondre]
Je me doutais que cela allait faire couler beaucoup d'encre ^^ Merci en tout cas de prendre le temps de donner vos réponses. Personnellement en temps qu'informaticien j'ai fait des bonds en lisant cette traduction. En terme informatique on dit effectivement « annuler » et « rétablir », un exemple parmi tant d'autre étant la suite Office : http://office.microsoft.com/en-us/word-help/undo-redo-or-repeat-an-action-HP001216394.aspx, l'équivalent en français : http://office.microsoft.com/fr-fr/word-help/annuler-retablir-ou-repeter-une-action-HP001216394.aspx. Le site de référence que j'utilise pour les traductions indique aussi « annuler » pour « undo » dans le domaine informatique. [1] S'il faut en passer par là j'accepte d'aller au bout de la modification, à savoir mettre à jour les pages qui y font référence et homogénéiser les autres messages. Je ne suis par contre pas un familier de Wikipédia et je vise plus haut : tous les wikis francophones utilisant MediaWiki... Je pense effectivement qu'un outil bien traduit est important. La synchronisation entre Translatewiki.net et Wikipédia se fait tous les combien ? Wyz (d) 3 janvier 2011 à 21:35 (CET)Répondre[répondre]
Bon pour moi, je soutiens ta suggestion pour « annuler ». Les références que tu indiques donnent du poids à ta suggestion. Ce qui contraste d'ailleurs énormément avec ton premier message trop court et vague. Pense à expliquer, rare ici sont les professionnels en informatique. ;-)
Si tu t'investis dans la suite des corrections à venir, cela me suffit, Wyz. C'est juste que je suis très occupé IRL ces temps, donc je ne peux pas m'atteler à cette tâche tout seul.
Pour la fréquence de synchronisation, je sais pas, il me semble que ce n'est pas régulier. La dernière fois, j'ai eu la synchronisation en une dizaine de jours. Bien à toi, Dodoïste [ dring-dring ] 3 janvier 2011 à 21:48 (CET)Répondre[répondre]
Ok, j'attends un peu les autres réponses (négatives ou positives). Désolé pour le manque d'explication au départ. J'étais au boulot et cette histoire me grattait un peu alors j'ai décidé de lancer le débat... Je ne pense pas qu'il y a pas tant de choses à modifier, surtout si vous avez utilisé {{int:Editundo}} ou {{MediaWiki:Editundo}}. De toute façon on verra bien si cette demande est avalisée. Je devrai avoir le temps de m'occuper des suites. Wyz (d) 4 janvier 2011 à 00:04 (CET)Répondre[répondre]
Dans la plupart des environnements, « Annuler » est la traduction de « Cancel », la commande qui permet de ne pas valider une action entamée (c'est ce que fait par exemple le lien « Annuler » dans la fenêtre d'édition). Ce n'est pas ce à quoi correspond l'annulation d'une modification. Ainsi, remplacer « Défaire » par « Annuler » pourrait induire en erreur dans certains contextes (pour l'historique, ce n'est pas trop gênant, mais pour l'affichage d'un diff, si). Je suis donc contre ce changement. Orlodrim [discuter] 4 janvier 2011 à 00:45 (CET)Répondre[répondre]
Il y a au minimum Aide:Jargon à modifier. Au passage je déplore que Aide:Jargon ait été renommé autre chose que Aide:Jargon. Teofilo 4 janvier 2011 à 00:49 (CET)Répondre[répondre]
En lisant Aide:Jargon je redécouvre le résumé automatique « Annulation des modifications 1234567 de Utilisateur » qui apparait actuellement lorsqu'on clique sur "défaire". Si on veut éviter "annuler" pour les raisons indiquées par Orlodrim, on pourrait remplacer "défaire" par "révoquer" (un autre terme examiné dans Aide:Jargon) et le résumé automatique deviendrait « révocation des modifications 1234567 de Utilisateur ». Teofilo 4 janvier 2011 à 01:26 (CET)Répondre[répondre]
Pour appuyer Wyz, je constate que le barre de menus en haut de l’écran de mon Mac contient un menu «Édition» (et non «Éditer»), dont les deux premiers items se nomment «Annuler» et «Rétablir» (et non «Défaire» et «Refaire»), quelle que soit l’application (en français) dans laquelle je travaille. Ce sont ces termes de facto standards que ceux qui utilisent un ordinateur (pas seulement les informaticiens donc) voient régulièrement. — Il est vrai que « annuler » est aussi utilisé dans d’autres contextes (là où l’anglais utilise « cancel » notamment), il convient donc juste de s’assurer qu’il n’y a pas ambigüité. —C.P. 4 janvier 2011 à 01:24 (CET) — En réalité « annuler (cancel) » et « annuler (undo) » ont presque la même signification en informatique, le premier s’utilisant avant que l’action ne soit faite, et le second après que l’action soit faite, donc il n’y a ambigüité que si l’on s’exprime mal (par exemple « annuler une annulation » au lieu de « ne pas annuler » ou de « rétablir »). —C.P. 4 janvier 2011 à 01:33 (CET)Répondre[répondre]

[retour à la ligne] Souvent l'idée d'annulation en informatique s'emploie pour un contre-ordre qui ne laisse pas de trace, alors que lorsqu'on utilise le bouton "défaire", on laisse une trace dans l'historique. L'action "annuler" associée à l'opération de copier-coller dans les logiciels de traitement de texte ne laisse pas de trace sauvegardée dans le disque dur. Pour cette raison, j'ai l'impression que "révoquer" serait un choix de vocabulaire pertinent pour ce qui nous concerne sur Wikipédia. Teofilo 4 janvier 2011 à 01:46 (CET)Répondre[répondre]

Par rapport à ce que dit C.P., j'ajoute que la commande « Annuler » des éditeurs de texte est dans un menu ou dans une barre d'outils associée à une image classique telle que  , alors qu'un bouton « Annuler », c'est toujours l'endroit on peut cliquer sans risquer de tout détraquer. Si quelqu'un affiche un diff par erreur et n'y comprend rien (par exemple un débutant qui a eu le malheur de cliquer sur 'diff' quand il a reçu son message de bienvenue), il cliquera probablement sur « Annuler » à mon avis. Orlodrim [discuter] 4 janvier 2011 à 08:49 (CET)Répondre[répondre]
Il faut garder la distinction entre le « défaire » (quel que soit le vocable) et la révocation qui signale une action d'admin. Par exemple, il ne serait pas habile de se retrouver face à un double lien « (révoquer | révoquer) » dans un historique vu en tant qu'admin. Actuellement, on a (« révoquer | défaire) ». Cordialement, --Lgd (d) 4 janvier 2011 à 09:17 (CET)Répondre[répondre]
La proposition est d'avoir « révoquer | annuler ». Dans les deux cas les actions suggèrent une suppression pure et simple des modifications mais sont toutefois historisées. C'est aussi le cas pour tout logiciel qui se respecte, il est possible de rétablir une action, c'est donc qu'il y a un historique quelque part... Je répète que, au jour d'aujourd'hui, quand on clique sur « défaire » on voit dans l'historique qu'il y a eu annulation... Wyz (d) 4 janvier 2011 à 10:06 (CET)Répondre[répondre]
@Orlodrim : Le lien dont il est question est soit affiché en regard de chaque version ou à côté d'un lien « modifier » quand on affiche la différence, ça m'étonnerait qu'il y ait confusion. Wyz (d) 4 janvier 2011 à 10:23 (CET)Répondre[répondre]
Ahem, dites : plutôt que de changer le « défaire » (avec des considérations plus ou moins hors-sujet sur les interfaces côté client quand il s'agit d'une interface Web), ne serait-il pas beaucoup plus simple de corriger la rédaction des autres messages systèmes, pour avoir par exemple (je n'ai pas regardé le détail des messages) : « La modification X de Y a été défaite » ? Je ne peux m'empêcher d'avoir l'impression qu'on s'apprête à démarrer un bulldozer pour déplacer de 10cm une simple tulipe...  . Cordialement, --Lgd (d) 4 janvier 2011 à 10:28 (CET)Répondre[répondre]
--CQui bla 4 janvier 2011 à 11:31 (CET) : Juste pour info, le logiciel que j'utilise professionnellement fait la différence entre défaire ce qui a été fait et annuler l'opération en cours... donc Défaire dans le sens actuel n'est pas inconnu de l'informatique. Annuler a pour moi effectivement, comme dit par Orlodrim par exemple le sens d'annuler ce que l'on est entrain de faire, sans autre conséquence que de perdre son propre travail. J'ai du mal a imaginer qu'un débutant fasse la confusion, autant que pour comprendre le but de cette discussion.Répondre[répondre]
Quand a la définition du Wiktionnaire, Défaire définition 1 Ce que l’un fait, l’autre le défait ;).
Ce serait bien d'avoir le nom dudit logiciel ;) Et on peut aussi annuler ce qu'un autre a fait (sans que ce soit irréversible)... Effectivement on peut aussi modifier les résultats des actions en « Défait les modifications de » et « Révoqué les modifications de »... Wyz (d) 4 janvier 2011 à 11:37 (CET)Répondre[répondre]
Bon j'ai fait quelques recherches, il semble que ce sont les canadiens qui utilisent « défaire » et « refaire ». [2] Dans tous les autres cas, même la traduction de projets libres, la convention est d'utiliser « annuler » pour « undo ». [3] [4]. De plus, une interface Web ne doit pas être vue différemment d'un menu. Wyz (d) 4 janvier 2011 à 12:25 (CET)Répondre[répondre]
Selon le Larousse, défaire c'est « Remettre quelque chose à l'état premier, réaliser à l'inverse les opérations précédentes : Défaire une couture ». Donc défaire une modification me semble tout à fait correct.
Après, je ne comprends pas la remarque « une interface Web ne doit pas être vue différemment d'un menu ». Ce que je disais, c'est simplement que l'utilisateur est habitué à :
  • avoir un item "Annuler" dans un menu Édition pour annuler une modification ;
  • avoir un bouton "Annuler" dans une boîte de dialogue pour la fermer sans rien faire. Un lien isolé sur une page web est assimilable à un bouton, pas à un menu, il devrait donc avoir cet effet.
Vu que le mot "Undo" est employé sur Wikipédia dans un contexte différent de celui dans lequel il est employé dans les logiciels usuels (éditeurs de textes), il n'est pas nécessaire de respecter la traduction habituelle.
Orlodrim [discuter] 4 janvier 2011 à 13:03 (CET)Répondre[répondre]
Petite précision : j’avais donc parlé du menu «Annuler» dans n’importe quelle application, pas seulement les éditeurs de texte (Annuler la fermeture de l’onglet, Annuler le déplacement du dossier, Annuler Supprimer la photo de l’album, etc., l’intitulé s’adaptant à l’action à annuler) Mon Mac est un peu plus polyvalent qu’une machine à écrire améliorée.C.P. 4 janvier 2011 à 14:11 (CET)Répondre[répondre]

Autre chose :   Est-ce que quelqu’un pourrait expliquer (à un non-admin) la différence entre les liens « révoquer » et « défaire » qu’on le privilège d’avoir certains ? Parce que pour moi, ces deux termes évoquent exactement la même action... —C.P. 4 janvier 2011 à 14:11 (CET)Répondre[répondre]

« Défaire » permet d'annuler la dernière modification uniquement alors que « Révoquer » permet d'annuler toutes les modifications d'un utilisateur d'un seul coup = retour à la dernière version non modifiée par l'utilisateur. Pour moi l'analogie avec un éditeur de texte est flagrante : chaque page/article peut être assimilée à un éditeur de texte, aussi on peut modifier son texte, enregistrer, annuler les modifications ou les rétablir. De plus l'item « Annuler » d'un menu édition est « Undo » pour une interface en anglais alors que le « Annuler » pour fermer une fenêtre est « Cancel » (un seul terme pour deux mots anglais). La question ici est de conserver la définition du bon sens ou d'utiliser un terme plus propice à l'informatique... Wyz (d) 4 janvier 2011 à 14:22 (CET)Répondre[répondre]
Merci bien. Donc «défaire» et «révoquer» signifient bien tous les deux «annuler», l’ambigüité étant qu’il n’est pas précisé ce qui est annulé.... — C.P. 4 janvier 2011 à 14:46 (CET)Répondre[répondre]
Pour être plus exact :
  • Défaire : chargement de la page d'édition avec le wikitexte tel qu'il était avant la modification que l'on souhaite défaire + résumé déjà rempli. Pour "défaire", il suffit alors de publier. Ce n'est pas automatique et on peut en profiter pour corriger une coquille ou ajouter une explication dans le résumé.
  • Révoquer : annulation en un clic de toutes les modifications du dernier auteur. Pas de passage par la page d'édition : la publication est automatique, de même que le résumé de modif. Cette action est réservée aux sysop mais aussi aux bots me semble-t-il.
Les deux actions ne sont donc pas identiques et il n'est pas souhaitable qu'elles soient désignées sous le même vocable.
Sinon, penser aussi que certaines ressources extérieures peuvent se baser sur les résumés de modif de ces actions pour travailler, je pense en particulier à Salebot ou LiveRC. Ces ressources peuvent évidemment se mettre à jour, mais il serait bien d'y penser avant de changer trop rapidement de vocabulaire.
⇨ Dr Brains ∞ Consultation ∞ 4 janvier 2011 à 19:10 (CET)Répondre[répondre]

Je suis assez en désaccord avec la remarque de Lgd « avec des considérations plus ou moins hors-sujet sur les interfaces côté client quand il s'agit d'une interface Web ». Au contraire, un utilisateur va réutiliser les habitudes apprises sur les interfaces qu'il a utilisées précédemment. Il va tenter de réutiliser une habitude acquise, ou s'attendre à une similarité, lorsque le contexte est sembable, ou que l'apparence d'une interface lui évoque quelque chose qu'il connaît. Là, on est dans un éditeur de texte, bien qu'il y ait énormément de différences avec Word. Si on peut dire qu'il y a un hors-sujet, c'est plus parce qu'on parle d'un lien « défaire » qui est dans un historique qui a l'apparence d'une page Web, et qui ne semble pas très lié avec l'éditeur de texte.

Il y aurait une similarité entre Word et notre lien « défaire » si le lien « défaire » était en fait un bouton dans la barre d'édition du texte wiki. Mais ce n'est clairement pas le cas.

Donc oui, j'arrive à la même conclusion que Lgd (Word et ce cas précis ne sont pas trop comparables), mais pas précisément pour les mêmes raisons je pense. Ou alors la remarque de Lgd était trop vague pour que je la comprenne avec certitude.

À défaut de puvoir se mettre d'accord sur un changement de terminologie, je suis plutôt favorable à la proposition de Lgd. Soit d'harmoniser les terminologies. Ce sera déjà ça de fait. Dodoïste [ dring-dring ] 4 janvier 2011 à 19:12 (CET)Répondre[répondre]

Le « hors sujet » tient au fait que l'on n'est pas ici dans une interface de type applicatif en ligne où les métaphores du côté client seraient présentes (pas de boutons, disons pour simplifier, comme tu le fais remarquer). Cordialement, --Lgd (d) 4 janvier 2011 à 19:38 (CET)Répondre[répondre]
OK, donc on est bien d'accord sur le fond. :-) Dodoïste [ dring-dring ] 4 janvier 2011 à 20:34 (CET)Répondre[répondre]
Le Web permet d'avoir des interfaces plus riches, voire différentes, aussi un bouton peut être remplacé par un lien ;) Si j'ai bien compris le point de vue de tout le monde il vaut mieux s'en tenir à un vocable correspondant à l'action effectuée plutôt que de coller à un langage informatique usité partout ailleurs. Si vous souhaitez ne modifier que le résumé de l'action il faut aussi penser, en effet, que les bots seront peut être perdus... Que fait-on finalement ? Wyz (d) 5 janvier 2011 à 19:15 (CET)Répondre[répondre]
En résumé, le remplacement est plutôt pertinent dans son principe. L'effectuer exige deux conditions : A) le faire partout où cela est justifié. B) Anticiper les effets indésirables et les traiter (par exemple, prévenir les robots).
S'ajoute une condition triviale : quelqu'un assure l'intégralité de ces obligations.
Si ce résumé est mauvais, le corriger, ça suffira peut-être pour conclure à l'impossibilité ou au moins l'incapacité. TigHervé 8 janvier 2011 à 17:24 (CET)Répondre[répondre]

Pages où apparaît ce message :

Changement proposé :

  • Bonjour j'ignore quelles modification apporter au feuilles de style actuellement utilisée sur fr mais je trouve que la police de caractère beaucoup trop petite pour une lecture correcte du code source. Voir l'exemple de code sur la page C sharp. est-ce qu'un as du css pourrait regarder. Merci.--pixeltoo (discuter) 16 février 2011 à 19:17 (CET)Répondre[répondre]
Sous monobook je ne vois aucune différence.
Mais j'ai remarqué que sous vector les textes entourés d'un <tt> étaient tout petits, comme ceci. Si modif il y a à faire, c'est donc plus probablement sur Mediawiki:Vector.css qu'il faut intervenir.
⇨ Dr Brains ∞ Consultation ∞ 16 février 2011 à 19:23 (CET)Répondre[répondre]
C'est amha encore plus petit que ce que tu montres. Je te fais une copie d'écran dès que je peux. :) --pixeltoo (discuter) 16 février 2011 à 23:45 (CET)Répondre[répondre]
Attention, c'est un problème côté client (lié aux polices effectivement utilisées). Il vaut mieux ne pas tenter de le résoudre via les styles de WP. Les lecteurs peuvent le régler via la configuration de leur navigateur ou via leurs vector / monobook ou common personnels. Cordialement, --Lgd (d) 17 février 2011 à 07:25 (CET)Répondre[répondre]
Attention. Non ce n'est pas côté client. J'ai posé la question sur irc... Le lecteur n'est pas forcément un utilisateur avec un compte. --pixeltoo (discuter) 17 février 2011 à 22:28 (CET)Répondre[répondre]
« Côté client » ne veut pas dire « avoir un compte », c'est sans aucun rapport; Cordialement, --Lgd (d) 17 février 2011 à 22:53 (CET)Répondre[répondre]
Je crois que ça vient du font-size: 8pt de Vector sur les <pre>. Marin 17/02
22:42
Ce font-size: 8pt est dans une CSS print, pas screen (ou all ou sans media) : il n'a pas d'effet sur l'affichage à l'écran, uniquement à l'impression. Cordialement, --Lgd (d) 17 février 2011 à 22:52 (CET)Répondre[répondre]
Ce n'est pas la balise pre car je vois la taille du code source en c sharp + petite que celle du Lorem ipsum.--pixeltoo (discuter) 17 février 2011 à 22:56 (CET)Répondre[répondre]
using System;
 
class HelloWorld
{
    public static void Main()
    {
        Console.WriteLine("Hello World!");
    }
}
Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
Sed non risus. Suspendisse lectus tortor, dignissim sit amet, adipiscing nec, ultricies sed, dolor.
Cras elementum ultrices diam. Maecenas ligula massa, varius a, semper congue, euismod non, mi.
Proin porttitor, orci nec nonummy molestie, enim est eleifend mi, non fermentum diam nisl sit amet erat.
Duis semper. Duis arcu massa, scelerisque vitae, consequat in, pretium a, enim. 
Ah, on voit mieux l'éventuel souci, là, effectivement lié aux polices et à leur traitement côté client (mais on peut rendre ça plus robuste côté CSS en effet) : le pre est en font-family: monospace,"Courier New" tandis que ton .csharp.source-csharp est en font-family: monospace; : il prend la même taille que le pre si on lui donne du font-family: monospace,"Courier New". Mais on va éviter : si c'était "Courier New", monospace, déjà, on se sentirait mieux. Problème pour bugzilla, mais pas pour ici. En tous cas, ne bougez pas les font-size, pitié. Cordialement, --Lgd (d) 17 février 2011 à 23:10 (CET)Répondre[répondre]
Alors, le :
font: normal normal normal 1em/1.2em monospace;
Appliqué sur les :
.csharp.source-csharp .de1, .csharp.source-csharp .de2
Peut-être ? Marin 17/02
23:08
Aucune idée mais s'il faut l'appliquer il faut appliquer la même taille pour tout les rendu de code. Ici je parle du csharp mais je pense qu'il en est de même pour le code javascript ou python. --pixeltoo (discuter) 17 février 2011 à 23:12 (CET)Répondre[répondre]
Ça vient bien de là, du code CSS de GeSHI généré directement dans le head. Il faudrait fixer la taille des pre dans notre Common.css (on le fait bien avec les polices sans-serif...). Marin 17/02
23:17
@lgd en attendant que des dev sur Bugzilla traite le problème, est-il possible de trouver une solution temporaire ?(En passant je me vois mal faire une requête sur Bugzilla n'ayant pas compris d'où venais le problème si quelqu'un pouvait s'en charger pliz). --pixeltoo (discuter) 17 février 2011 à 23:22 (CET)Répondre[répondre]
Ce n'est pas un bug, juste la façon dont est configuré le gadget qui permet la coloration du code. Marin 17/02
23:27
Ok je vois. Tu saurais où/comment configuer le gadget ? Sinon à qui s'adresser ou bien c'est au delà de la capacité d'un sysop ? --pixeltoo (discuter) 17 février 2011 à 23:37 (CET)Répondre[répondre]
Ce n'est pas un gadget. C'est une extension. Ça ne se configure pas ici. Ça peut se patcher éventuellement ici, mais encore une fois, ce n'est pas souhaitable dans ce cas. Cordialement, --Lgd (d) 17 février 2011 à 23:41 (CET)Répondre[répondre]
Exact, quiproquo, je voulais dire extension. Mais, après recherche, c'est configurable, et le problème était déjà réglé, mais pour une version antérieure de l'extension ; tout ce qu'il y à faire, pour mettre à jour, c'est remplacer, dans MediaWiki:Geshi.css :
pre.source
Par :
.mw-geshi pre
Et les trucs sous la forme :
pre.source-csharp
Par :
.source-csharp pre
Marin 17/02
23:46
MediaWiki:Geshi.css règle uniquement les couleurs, la graisse et l'italique. Bonsoir, --Lgd (d) 17 février 2011 à 23:57 (CET)Répondre[répondre]
En tout cas, il faut le mettre à jour. Après, ajouter un font-size: normal !important ? Marin 18/02
00:07
1. Non. 2. Non plus, et normal n'est pas une valeur de font-size. Ça suffit, là. --Lgd (d) 18 février 2011 à 00:26 (CET)Répondre[répondre]
1. Pourquoi ? C'est juste mettre à jour la CSS par rapport à l'extension, qui a changé ses classes entretemps. 2. Et inherit ? 3. Pourquoi ça suffit ? Marin 18/02
00:42
désolé, un moment d'impatience, tout de même compréhensible : cette page de maintenance n'est pas le lieu approprié pour te donner un cours de CSS (surtout sur des questions complexes comme celle-ci) et il serait temps que tu t'arrêtes sur le sujet (désolé, je n'aurais pas le temps de te fournir plus d'explications techniques sur les différents points). Sauf si un autre contributeur plus avisé a une proposition concrète et convaincante à faire, ce sujet est a priori clos : il y a effectivement un souci, il est compliqué (très), mais il ne relève pas d'un patch à mettre en place par les admins de WP dans les fichiers qu'ils peuvent modifier. Pour info, à chaque fois que j'ai vu ce genre de patch être réalisé, ça a été une source de soucis par la suite. Cordialement, --Lgd (d) 18 février 2011 à 01:05 (CET)Répondre[répondre]
J'ai posé une question sur WP:QT pour prolonger le débat. --pixeltoo (discuter) 18 février 2011 à 13:53 (CET)Répondre[répondre]

Changement proposé : pourrait-on ajouter une variable de configuration du type noChangeEditsectionLinks à setModifySectionStyle(element) qui permette de désactiver ce changement cosmétique via le common.js personnel ? Par exemple, quelque-chose comme :

    if (noChangeEditsectionLinks == true) {
        return;
    }

Ou mieux, supprimer cette fonction, mais cela demandera une consultation plus large ?

C'est devenu assez pénible avec le nouveau mode de chargement des scripts, mais je préfère en parler plutôt que de le faire moi-même sous le coup d'une légère exaspération quand je clique en cours d'affichage sur du blanc là où il y avait un lien une seconde avant   ? Cordialement, --Lgd (d) 26 février 2011 à 13:22 (CET)Répondre[répondre]

Il faudrait tester si la variable existe, sinon ça risque de provoquer une erreur, non ?
    if(typeof(noChangeEditsectionLinks)!="undefined" && noChangeEditsectionLinks == true) {
        return;
    }
Je suis contre le retrait pur et simple, par contre.
⇨ Dr Brains ∞ Consultation ∞ 26 février 2011 à 13:41 (CET)Répondre[répondre]
Oui, c'était un exemple rapide au fil du clavier pour faire ça proprement ensuite.
Mais est-ce qu'on ne peut vraiment pas envisager :
  • soit de supprimer ce déplacement sur fr.wp (encore une fois, cela passerait par de l'artillerie lourde, type sondage ou PDD) ?
  • soit de proposer sur bugzilla une gestion directe de la position de ce lien (tenir compte de l'internationalisation) ?
fr.wp se distingue et s'alourdit depuis des années avec ce script assez ridicule (dont je trouve le résultat bienvenu sur le fond) alors qu'il s'agirait de bouger les templates une bonne fois pour toute pour appliquer ce que fait fr.wp, ou bien de gérer une option de configuration de l'instance de mediawiki. Cordialement, --Lgd (d) 26 février 2011 à 13:49 (CET)Répondre[répondre]
Pardonnez-moi si je me trompe, mais ce ne serait pas à ça que sert la variable oldEditsectionLinks ? iAlex (Ici ou ), le 26 février 2011 à 14:46 (CET)Répondre[répondre]
zut, démasqué (plus sérieusement, son nommage est à revoir, mais surtout cela laisse ouverte la question de fond). Cordialement, --Lgd (d) 26 février 2011 à 14:59 (CET)Répondre[répondre]
Rah j'ai pas réfléchi, sinon je m'en serais souvenu que ça existait déjà... Je m'a fait eu.
Plus sérieusement :
  1. Si c'est décidé collégialement je ne m'y opposerait pas. Le changement de style de ces liens était surtout utile pour éviter, lorsqu'il y a des images à droite, qu'ils se retrouvent tous en dessous des images et donc bien en-dessous de la section elle-même. Mais apparemment la récente mise à jour de Mediawiki a pallié à ce défaut (exemple). Toutefois, si il est décidé de supprimer ce code, je me réserve le droit d'en faire un gadget.
  2. Ce serait effectivement le plus simple et le plus robuste. Cela dit, ce changement peut-il se faire sur la seule version francophone de WP ? Pas sûr...
⇨ Dr Brains ∞ Consultation ∞ 26 février 2011 à 15:26 (CET)Répondre[répondre]
Proposition : mettre en pratique le compromis suppression du comportement par défaut + gadget si un sondage (à mettre en place, je peux me dévouer) confirme qu'une majorité de gens n'y sont pas désespérément accrochés au point de refuser d'en faire une option de leur compte. D'autres avis ? Cordialement, --Lgd (d) 28 février 2011 à 10:59 (CET)Répondre[répondre]
  Pour que tu lances le sondage   ⇨ Dr Brains ∞ Consultation ∞ 28 février 2011 à 11:16 (CET)Répondre[répondre]
Moi et ma grande... Ok, je fais ça (sans doute le WE prochain). Cordialement, --Lgd (d) 28 février 2011 à 11:19 (CET)Répondre[répondre]


Pages où apparaît ce message : toutes

Changement proposé : Bonjour, le gadget AtlasOff désactive effectivement le WikiMiniAtlas, mais le script est quand même chargé. On pourrait désactiver le script plus en amont dans la chaîne de traitement.

Pour cela, dans le Common.js il faudrait remplacer :

if (wgServer == "https://secure.wikimedia.org") {
  var metaBase = "https://secure.wikimedia.org/wikipedia/meta";
} else {
  var metaBase = "http://meta.wikimedia.org";
}
importScriptURI(metaBase+"/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400")

var wma_settings = { 
  buttonImage: 'http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/Geographylogo.svg/18px-Geographylogo.svg.png'
}

par :

if (typeof no_wikiminiatlas === "undefined" || !no_wikiminiatlas) {
  if (wgServer === "https://secure.wikimedia.org") {
    var metaBase = "https://secure.wikimedia.org/wikipedia/meta";
  } else {
    var metaBase = "http://meta.wikimedia.org";
  }
  importScriptURI(metaBase + "/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400");

  var wma_settings = { 
    buttonImage: 'http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/Geographylogo.svg/18px-Geographylogo.svg.png'
  };
}

Nous disposons ainsi d'une variable optionnelle no_wikiminiatlas permettant de court-circuiter le chargement du script. Noter que j'ai également effectué quelques corrections mineures (comparaisons strictes, points virgules).

Il y a une autre modification à faire. Dans MediaWiki:Gadget-AtlasOff.js, il faut remplacer :

var wma_settings =
{
 enabled: false
}

par :

var no_wikiminiatlas = true;

On ne peut pas désactiver le WMA dans son vector.js, il faut obligatoirement passer par le gadget. Pourquoi ? Parce que pour permettre la désactivation du WMA dans le vector.js, il faudrait englober dans un addOnLoadHook le code de chargement de WMA présent dans le Common.js. Par conséquent, le WMA serait chargé après le vector.js et non avant, comme cela est le cas actuellement. Cela risquerait de briser des vector.js intergissant avec WMA.

Cordialement, od†n [dead words] 6 janvier 2011 à 17:30 (CET)Répondre[répondre]

A priori, et sans avoir testé, ça ne marchera pas. Ceci à cause de l'ordre de chargement des scripts : d'abord les http://bits.wikimedia.org (auxquels seuls les devs ont accès), puis le Mediawiki:Common.js, puis les gadgets, puis le .js perso.
En l'occurrence, le Common est chargé avant les gadgets (dont éventuellement celui désactivant le wikiminiatlas), ce qui signifie que lors de la lecture du Common, la variable no_wikiminiatlas ne sera jamais définie, même si elle est définie plus tard dans un gadget. Donc elle ne sert à rien : la page meta:MediaWiki:Wikiminiatlas.js sera quand même chargée.
Par conséquent, le changement préconisé pour le gadget MediaWiki:Gadget-AtlasOff.js :
  • serait inutile pour empêcher le chargement de la page
  • rendrait impossible le fait d'empêcher le lancement du wikiminiatlas, celui-ci ne connaissant pas la variable no_wikiminiatlas mais réagissant à wma_settings = { enabled: false }.
Fausse bonne idée donc. Désolé.
⇨ Dr Brains ∞ Consultation ∞ 6 janvier 2011 à 18:06 (CET)Répondre[répondre]
Du moins d'après ce que je vois, les fichiers des gadgets sont lus avant le common.js.   od†n [dead words] 6 janvier 2011 à 18:20 (CET)Répondre[répondre]
Gné ?
J'étais persuadé de ce que je disais, mais effectivement, il semblerait que les gadgets soient chargés avant le common (en fait je n'utilise jamais les gadgets en préférences, je charge tout ce qu'il me faut via mon monobook).
Bon ben dans ce cas, ne pas tenir compte de ce que je disais : tel que tu le préconises, ça marche (mais pour plus de sécurité, je conserverais la variable wma_settings = { enabled: false }, on ne sait jamais).
Par contre, ce que je disais reste valable pour répondre à ta question sur le vector.js perso, qui lui est chargé après, et est donc inopérant pour un cas comme celui-là. Pour y remédier, il faudrait charger le wikiminiatlas après tous les autres scripts, c’est à dire dans une fonction addOnloadHook(), comme cela est fait par exemple pour Mediawiki:Sysop.js à la fin du Common. Je ne pense pas que cela poserait des problèmes (à vérifier avec la fonction d'affichage de carte OpenStreetMap en titre en particulier).
⇨ Dr Brains ∞ Consultation ∞ 6 janvier 2011 à 18:46 (CET)Répondre[répondre]
Ne pas toucher localement. Faire en revanche remonter le problème du côté de l'extension et du dev. Particulariser à coup de choses locales la fr.wp est de peu de profit pour le projet et c'est une source potentielle de soucis ultérieurs. Cordialement, --Lgd (d) 6 janvier 2011 à 19:29 (CET)Répondre[répondre]
Oui mais non. L'objet de la demande d'Od1n est de ne pas charger la page du Wikiminiatlas si le gadget "Off" est sélectionné (si j'ai bien compris).
Il n'y a rien que le développeur du wikiminiatlas puisse y faire.
C'est à nous, ici et en local, de (éventuellement) modifier la façon dont ce script est inséré dans le common.js.
⇨ Dr Brains ∞ Consultation ∞ 6 janvier 2011 à 19:52 (CET)Répondre[répondre]
Oui Dr Brains tu as bien compris. Mais il serait souhaitable de prendre un peu de temps pour réfléchir là dessus. Par exemple, le code du meta:MediaWiki:Wikiminiatlas.js est englobé dans un addOnLoadHook, par conséquent, si on englobe le code du Common.js dans un addOnLoakHook, le premier sera imbriqué dans le second. Je pense que cela pourrait être problématique. od†n [dead words] 6 janvier 2011 à 23:59 (CET)Répondre[répondre]
A priori, non, ça ne poserait pas de problème. Par exemple l'import de Mediawiki:Sysop.js est fait dans une fonction addOnloadHook. Cette page elle-même sert à importer d’autres pages qui elles-mêmes sont appelées par un addOnloadHook. Bref, imbriquer les addOnloadHook ne pose pas de problème en soi.
Ce qui peut poser problème, c'est que la fonction finale de cette imbrication soit déplacée tout à la fin de la lecture du code, et que les éléments qu'elle ajoute manquent pour une autre fonction qui en a besoin pour fonctionner. Par exemple, le wikiminiatlas ajoute un lien en forme de globe (   ) devant les coordonnées. Si ce lien est utilisé par une autre fonction par la suite (comme point de repère ou pour récupérer les paramètres ou autre chose), l'ajout de ces liens en tout dernier fera que cette fonction ne marchera plus.
Dans le cas présent, il semble qu'aucune fonction n'utilise ces liens par la suite, l'affichage des carte OpenStreetMap se basant sur le lien des coordonnées elles-mêmes. Donc, a priori, importer le wikiminiatlas via une fonction addOnloadHook() ne devrait pas poser de problème.
⇨ Dr Brains ∞ Consultation ∞ 7 janvier 2011 à 01:34 (CET)Répondre[répondre]
Je ne savais pas que charger un script pour rien était un problème. TigHervé 8 janvier 2011 à 17:32 (CET)Répondre[répondre]
C'est plus un soucis d’optimisation de performance qu'un réel problème, effectivement. Mais ça n'empêche pas de se pencher sur la question.
⇨ Dr Brains ∞ Consultation ∞ 8 janvier 2011 à 17:36 (CET)Répondre[répondre]

Pages où apparaît ce message : toutes les pages en mode édition

Changement proposé :

Ce script contient une fonction addCharSubsetMenu pour afficher des liens en bas de la fenêtre d'édition. Dans cette fonction, une ligne sert à récupèrer l'élément 'specialcharsets' :

var specialchars = document.getElementById('specialcharsets');

Cependant, getElementById n'est pas fiable. En mode prévisualisation, si le code wiki contient un <div id="specialcharsets">, il est récupéré à la place. Comme un traitement compliqué est exécuté sur le contenu de cet objet, cela peut poser des problèmes de sécurité (a priori plus maintenant, mais suite à un échange avec Dr Brains, ce serait mieux de corriger le problème à la base). Une solution basique serait d'ajouter un test du type :

if (specialchars.parentNode.parentNode.parentNode.tagName != 'FORM') return;

Mais ce n'est peut-être pas une bonne idée d'être dépendant de la structure du formulaire d'édition. D'autres avis seraient bienvenus.

De plus, il serait prudent d'ajouter un test similaire quand on cherche l'élément d'id "urgentsynchronejs" dans MediaWiki:Common.js (il faudrait d'abord décider à quel endroit cet élément doit être placé en temps normal).

Orlodrim [discuter] 8 janvier 2011 à 17:00 (CET)Répondre[répondre]

Précisions :
Le problème de sécurité est résolu via cette modif, qui ne permet plus de faire exécuter du code javascript, comme c'était le cas avant. Ceux qui n'ont pas encore rechargé le cache peuvent essayer d'ajouter le code <div id="specialcharsets" style="visibility:hidden"><p><span>%27-alert("foo")-%27+</span></p></div> dans n'importe quelle page pour vérifier qu'en mode prévisualisation, le code javascript correspondant est bien lancé lorsqu'on clique sur le lien.
L'idée de vérifier le tagName du parent exposée par Orlodrim consiste à s'assurer de la présence d'un tag qui est interdit par mediawiki, et donc qu'on ne peut pas retrouver en prévisualisation. J'avais, par e-mail, proposé de changer le <div id="specialcharsets"> par un élément interdit, par exemple un <fieldset> dans le message système (Mediawiki:Edittools) (sous réserve qu'une telle balise y soit autorisée). Si impossible, vérifier que l'élément est bien un enfant de l'editform règlerait le problème (la prévisualisation et tout ce qu'elle inclut n'en faisant pas partie).
⇨ Dr Brains ∞ Consultation ∞ 8 janvier 2011 à 17:19 (CET)Répondre[répondre]

Il me semble qu'on ne peut pas mettre de balise fieldset dans Mediawiki:Edittools. Je propose donc un code un tout petit peu plus générique que le précédent.

Version actuelle de addCharSubsetMenu() :

var specialchars = document.getElementById('specialcharsets');
if (!specialchars) return;

Version proposée :

var specialchars = document.getElementById('specialcharsets');
/* Par mesure de sécurité, vérifie que specialchars est dans l'editform,
   donc pas dans html généré à partir du code wiki. */
var ancestor = specialchars;
for (var i = 0; i < 10 && ancestor && ancestor.tagName != "FORM"; i++) {
  ancestor = ancestor.parentNode;
}
if (!ancestor || ancestor.tagName != "FORM") return;

Orlodrim [discuter] 14 janvier 2011 à 00:25 (CET)Répondre[répondre]

En fait j'aurai plutôt proposé l'inverse :
function Machin(){
    var specialchars = getCharset();
    if (!specialchars) return;
    
    
    
}

function getCharset(){
    var Charset = false;
    var Form = document.getElementById('editform');
    var Divs = Form.getElementsByTagName('div');
    for(var a=0,l=Divs.length;a<l;a++){
        if(Divs[a].id && Divs[a].id == "specialcharsets") Charset = Divs[a];
    }
    return Charset;
}
A vérifier peut-être d’autres id que "editform" (lors d’un téléchargement de fichier par exemple, où l'id est "mw-upload-form"), ou prendre peut-être Form = document.getElementsByTagName('form')[0]; pour embrasser tous les cas possibles.
⇨ Dr Brains ∞ Consultation ∞ 14 janvier 2011 à 01:02 (CET)Répondre[répondre]
Si tu préfères, mais alors vérifie que le tagName de Form est bien "FORM". Sinon tu remplaces juste un bug potentiel par un autre. Orlodrim [discuter] 14 janvier 2011 à 01:26 (CET)Répondre[répondre]
C'est pas faux. Donc Form = document.getElementsByTagName('form')[0]; règle tous les soucis éventuels, a priori.
⇨ Dr Brains ∞ Consultation ∞ 14 janvier 2011 à 01:29 (CET)Répondre[répondre]
Non car le champ de recherche est aussi une FORM. Le plus simple est peut-être de faire une boucle sur toutes les FORMs (c'est pas plus compliqué que d'en chercher une en particulier et a priori il n'y a pas de risque). Orlodrim [discuter] 14 janvier 2011 à 01:33 (CET)Répondre[répondre]
Mon code est quand même plus simple, non ? Orlodrim [discuter] 14 janvier 2011 à 01:37 (CET)Répondre[répondre]
Ah oui, zut.
Donc, on récapitule :
function Machin(){
    var specialchars = getCharset();
    if (!specialchars) return;
    
    
    
}

function getCharset(){
    var Charset = false;
    var Forms = document.getElementsByTagName('form');
    for(var b=0,m=Forms.length;b<m;b++){
        if(Charset) continue;
        var Divs = Forms[b].getElementsByTagName('div');
        for(var a=0,l=Divs.length;a<l;a++){
            if(Charset) continue;
            if(Divs[a].id && Divs[a].id == "specialcharsets") Charset = Divs[a];
        }
    }
    return Charset;
}
Là ça devrait être bon. On récupère le premier <div id="specialcharsets"> contenu dans un <form>. C'est un petit peu lourd, mais ça a le mérite d’éliminer totalement le bug.
Ton code est plus simple mais tu pars du div pour aller à la form, ce qui induit que si un petit malin rajoute un <div id="specialcharsets"> en dehors d’une <form>, le script s'arrête. Ce qui n'est pas le cas avec ma façon de faire, puisque je pars de la form pour trouver le div. C'est plus complexe mais ça fonctionne tout le temps.
⇨ Dr Brains ∞ Consultation ∞ 14 janvier 2011 à 01:44 (CET)Répondre[répondre]
Oui... mais si tu tiens à corriger les bugs en plus des failles, ça ne résout qu'une infime partie du problème (rien que dans ce script, il y a des getElementById sur wpSave, wpPreview, mw-editbutton-array, mw-editbutton-signature où la même chose peut se produire). Vas-tu pour chacune de ces requêtes faire un parcours complet de toutes les forms pour gérer un cas totalement improbable (il n'y a aucune raison légitime d'introduire de tels id dans un article) ? Orlodrim [discuter] 14 janvier 2011 à 02:00 (CET)Répondre[répondre]
C'est pas faux…
⇨ Dr Brains ∞ Consultation ∞ 14 janvier 2011 à 02:21 (CET)Répondre[répondre]

Mediawiki:Common.css : palettes, boîtes déroulantes, améliorations possibles à discuterModifier

Bonjour,
Deux modifications de Common.css sont envisagées et à discuter sur Discussion Projet:Modèle, afin :

  • d'éviter la multiplication des stylegroupe = width:...px superflus dans les modèles de palettes ;
  • d'évitez notamment les liens « [dérouler] » rendus pratiquement illisibles dans les boîtes déroulantes ou palettes quand une couleur de fond maladroite est imposée.

Avis bienvenus (là-bas plutôt qu'ici pour ne pas encombrer cette page à ce stade). Cordialement, --Lgd (d) 1 mars 2011 à 08:36 (CET)Répondre[répondre]

Page spéciale : Bloquer l’utilisateurModifier

Pages où apparaît ce message : Page spéciale : Bloquer l’utilisateur, Menu déroulant « Durée avant expiration »

Changement proposé : Bonjour. (Je ne sais pas si je suis sur la bonne page, <passage de pommade> mais je suis sûr que ceux qui répondent habituellement ont les compétences requises </passage de pommade mais je le pense quand même>)
L'une des options de blocage indique « fin de l'année scolaire 2010 ». Il me semble qu'il faudrait supprimer le millésime (ou peut-être l'actualiser s'il y a de savants calculs à mettre à jour tous les ans).
Bien respectueusement --En passant (d) 2 mars 2011 à 14:37 (CET)Répondre[répondre]

L'année scolaire 2010 désigne celle qui commençait à l'automne 2010, c'est à dire l'actuelle (mais c'est sans doute quelque-chose-centré, dans l'absolu). Cordialement, --Lgd (d) 2 mars 2011 à 14:41 (CET)Répondre[répondre]
A-t-on besoin de cette date ? « fin de l'année scolaire » suffit, non ? Trizek bla 2 mars 2011 à 14:43 (CET)Répondre[répondre]
C'est ce que je me suis dit aussi, spontanément. Mais quand le bandeau traîne après coup, ça peut prêter à confusion, non ? Cordialement, --Lgd (d) 2 mars 2011 à 14:44 (CET)Répondre[répondre]
Qu'appelle-tu après coup ? L'année présente dans le bandeau de blocage sur la page de l'utilisateur ? Il y a la date avec la signature lors du dépôt, non ? Trizek bla 2 mars 2011 à 14:59 (CET)Répondre[répondre]
Désolé, j'étais convaincu que l'année scolaire en cours était désignée par l'année civile de la fin d'année scolaire. Mais bon, le millésime me semble néanmoins inutile : dans les journaux de blocage, la date est indiquée en même temps que la durée déterminée par le menu déroulant, la déduction est facile à faire. --En passant (d) 2 mars 2011 à 15:27 (CET)Répondre[répondre]

MediaWiki:Sitenotice et MediaWiki:Anonnotice : semaine de la neutralitéModifier

Pages où apparaît ce message : Partout.

Changement proposé : Ajout de ceci dans MediaWiki:Sitenotice :

Plus que 75 Si 365 Wikipédiens rendent chacun neutre 3 articles en une semaine, alors la catégorie des articles publicitaires sera vidée. Cliquez ici pour participer !


C'est-à-dire ceci :

{{#ifexpr: {{PAGESINCATEGORY:Article au ton publicitaire}} > 0|{{#ifeq:{{LOCALMONTH}}|04|<span style="text-align: center; display: block">[[:Catégorie:Article au ton publicitaire#mw-pages|<span title="Semaine de la neutralité sur Wikipédia, du 24 au 30 avril" style="font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif; font-size: 36px; padding-bottom: 10px; display: block"><span style="font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif; font-size: 24px; vertical-align: middle; position: relative; top: -5px">Plus que</span> {{PAGESINCATEGORY:Article au ton publicitaire}}</span><span title="Semaine de la neutralité sur Wikipédia, du 24 au 30 avril" style="font-family:Georgia, Palatino, Palatino Linotype, Times, Times New Roman, serif; font-size: 18px; line-height: 1.3em; display: block">Si 365 Wikipédiens rendent chacun neutre 3 articles en une semaine, alors la catégorie des articles publicitaires sera vidée. Cliquez ici pour participer !</span>]]</span>}}}}

Et création de MediaWiki:Anonnotice vide, pour que ça n'apparaisse qu'aux utilisateurs enregistrés, si j'ai bien compris le fonctionnement de ce truc. Unanimité de l'utilité de ce bandeau sur le bistro si j'ai bien compris, et plusieurs demandes de mise en sitenotice, la seule critique faite étant son intrusivité quand il est mis en haut du bistro, problème réglé puisque le bandeau pourrait être masqué en un clic dans notre cas, et n'est pas coloré.

Il faut corriger les styles CSS, un peu lourds. Attention également, comme signalé dans ta page de discussion, au fait que le modèle aura un rendu dégradé selon la police de caractère effectivement présente et utilisée par IE (chevauchement partiel du compteur avec le texte situé en dessous).
Peut-être la version ci-dessous (rapidement faite à partir de ton code) serait-elle un meilleur point de départ, à tester. Cordialement, --Lgd (d) 25 avril 2011 à 20:34 (CEST)Répondre[répondre]

Je ne peux pas savoir ce que ça chez toi avec la police, étant donné que ça s'affiche correctement chez moi. En tout cas, chez moi, avec ta version du code, le « plus que » et le « 947 » sont au même niveau de la ligne, ce que je tente d'éviter. Je précise que j'ai repris les polices serif utilisées dans le Signpost. En ce qui concerne le cadre autour de la bannière, il me semble que le Sitenotice en ajoute un, non ? Il me semble également que dans notre cas, laisser le texte en bleu serait mieux (plus explicitement un lien, car ça ressemble moins à un bouton ici). Marin 25/04
20:57

S'en tenir à un choix de polices plus réduit et plus homogène devrait régler ces questions de rendus différents (pour un site notice, il faut tout de même un minimum de robustesse de rendu  ). Cordialement, --Lgd (d) 25 avril 2011 à 21:10 (CEST)Répondre[répondre]
C'est à dire ? Le sans-serif de Wikipédia ? Marin 25/04
21:23
Déjà il faut oublier TOUT lien vers une page perso (conféré la croix). Ensuite je recommanderais d'éviter tout effet de style spécifique (utilisation extensive de corrections en utilisant de trucs spécifiques à webkit et moz et les "box-shadow" pour IE) Si tu veux mettre un truc vu par tous, il faut qu'il soit compatible, et robuste pour la majorité des navigateurs => au plus simple, et sans enluminure inutile (il suffit d'ailleurs de voir le global centralnotice qu'on a actuellement : [5]) Loreleil [d-c] 26 avril 2011 à 10:33 (CEST)Répondre[répondre]

« Déjà il faut oublier TOUT lien vers une page perso (conféré la croix). »Je suppose que ce plugin s'en chargera.
« utilisant de trucs spécifiques à webkit et moz et les "box-shadow" pour IE » → J'avais enlevé tout ça dans le truc que j'ai proposé en haut de la section, je suppose que Lgd l'a mis sans faire attention quand il a voulu suggérer un hack.
« utilisation extensive de corrections » « Si tu veux mettre un truc vu par tous, il faut qu'il soit compatible, et robuste pour la majorité des navigateurs => au plus simple, et sans enluminure inutile. » Il me semble que le texte est mis en grosse taille dans la sitenotice par défaut, non ? Si c'est bien le cas, voici le truc le plus dépouillé possible au niveau CSS (+ centrage) :

Ou avec une vectorbox (déjà utilisé plusieurs fois dans une sitenotice) :

Marin 26/04
11:26

  Non Bon, bwa, là : c'est déjà un peu tard pour le faire, même si c'est aussi un peu (bcp pour moi) dommage. La prochaine fois, s'y prendre avec de l'avance, ne pas hésiter à faire plus sobre (beaucoup plus sobre) et à s'assurer sans craindre de demander avec insistance sur le Bistro si l'idée d'utiliser le siteNotice passe (elle semblait passer ce coup-ci, mais je ne suis pas sûr que ça n'aurais pas déclenché une levée de bouclier finalement). Cordialement, --Lgd (d) 29 avril 2011 à 20:56 (CEST)Répondre[répondre]

Changement proposé : Ce modèle sur Wikinews utilise ceci avec ce modèle. Est-ce qu'il pourrait en avoir un sur Wikipédia, si possible avec des textes personnalisable? STOP. De: SapindnoelParler à un sapin (et avoir l'air fou) Qu'est ce que j'ai fait? 08 mai 2011 à 19:59 (UTC-4) ou 9 mai 2011 à 01:59 (CEST)Répondre[répondre]

Bonsoir, Wikinews est un site d'information et d'actualité. Afficher les dernières dépêches ainsi y est ma foi convenable. À quoi est ce que cela servirait sur une encyclopédie ? Je suis un peu dubitatif quant à l'utilisation d'un tel modèle sur notre très chère encyclopédie. Micthev (discuter), le 9 mai 2011 à 02:12 (CEST)Répondre[répondre]
En passant, {{Compte à rebours}} a été implémenté dans le Common.js, proposé à la suppression, puis gardé sous prétexte qu'il est « pas très utile, voire inutile, mais amusant, et on l'utilise pas dans l'espace encyclopédique, alors ça va ». Marin 09/05
04:39
  Non Le common.js est suffisamment chargé comme cela pour ne pas pouvoir se permettre d'y ajouter des scripts « décoratifs ». --Lgd (d) 9 mai 2011 à 07:26 (CEST)Répondre[répondre]

MediaWiki:Common.css : ajouter un « word-wrap: break-word »Modifier

Ajouter dans le Common.css :

#bodyContent {
    word-wrap: break-word;
}

Pour éviter de faire apparaître une barre de défilement horizontale dans certains articles, par exemple, quand quelqu'un insère une URL brute et sans tirets. Je précise que cette propriété a été introduite dans Internet Explorer, et a été normalisée avec CSS3. (pas de signature) — Le message qui précède, non signé, a été déposé par Marin M. (discuter)

Pour moi, ce n'est clairement pas à utiliser de cette manière : masquer le (léger) défaut d'affichage provoqué par des contenus qui nécessitent une correction ne favorisera pas cette dernière. On ne résoud pas un problème de contenu par une opération de cosmétique.
Ce serait peut-être envisageable lorsqu'il s'agit de contenus non erronés et qu'il ne s'agit donc pas de corriger, c'est à dire éventuellement dans les seuls blocs pre pour en faciliter la consultation en évitant le scroll horizontal. Et encore, avec des réserves : les retours à la ligne arbitraires pourraient y entraîner des erreurs de sens. Cordialement, --Lgd (d) 22 mai 2011 à 07:14 (CEST)Répondre[répondre]
Pareil pour moi. La présence d'un scroll horizontal est dans l'immense majorité (peut-être même la totalité) des cas révélatrice d'un problème de mise en page, à régler au niveau du contenu. Ça peut même permettre de repérer certaines erreurs de syntaxe, j'avais rencontré une fois une erreur d'imbrication de floats qui causait un scroll. Pour conclure, la modification proposée n'est pas appropriée à la situation. od†n ↗blah 28 mai 2011 à 10:59 (CEST)Répondre[répondre]
Bon, bwa, donc :   Non. --Lgd (d) 28 mai 2011 à 11:26 (CEST)Répondre[répondre]

SiteNotice Poty2010Modifier

Ce n'est pas un message système, mais ça touche pas mal de pages.

Message actuel : Le dernier tour du coucours de l'image de l'année de Wikimédia Commons a commencé.

Pages où apparaît ce message : toutes (pour les utilisateurs enregistrés)

Changement proposé : Le dernier tour du concours de l'image de l'année de Wikimédia Commons a commencé.

Merci, --Wikinade (d) 30 mai 2011 à 17:31 (CEST)Répondre[répondre]

C'est le "CentralNotice", cest donc un pb à régler sur meta par un sysop de là-bas. D'ici on ne peut rien y faire.
⇨ Dr Brains ∞ Consultation ∞ 30 mai 2011 à 17:51 (CEST)Répondre[répondre]
Merci pour la précision. Je n'ai pas pris le temps de chercher où déposer ma requête sur méta, et j'ai choisi de demander directement à Hoo man de réparer sa coquille (j'espère qu'il va passer dans la journée). --Wikinade (d) 30 mai 2011 à 18:19 (CEST)Répondre[répondre]


ContributionsModifier

Pages où apparaît ce message : Les pages de contributions.
Changement proposé : Est-ce qu'on pourrait, du moins créer une extension, permettant de voir la modfications qui a suivi la notre? Exemple avec l'historique de cette page avec la modification 66040543 de Althiphika et la modification 66040683 de Lgd.:

Ou:

Pratique pour : Savoir si on a été révoqué, savoir si quelqu'un nous a répondu dans une page de discussion.

Je pense que tu devrais plutôt faire ta demande du côté du Projet:JavaScript. Marin 06/06
17:14
Dac j'ai demandé au projet Sapindnoel ou de juin plutôt Parler à un sapin(et avoir l'air fou) 06 juin 2011 à 11:56 (UTC-4) ou 6 juin 2011 à 17:56 (CEST)Répondre[répondre]

MediaWiki:Common.css et lisibilité du source codeModifier

Pages où apparaît ce message : Les pages où les balises <syntaxhighlight> ou <source> sont utilisées. Les pages utilisateurs contenant du code CSS ou JS.

Explication sommaire: L'extension SyntaxHighlight GeSHi ajoute des balises redondantes qui modifie involontairement la taille de la police de caractère. Pour plus d'information, voir le bug 26204 (aussi bug 23708 et bug 27145). Voir bug 20706 pour une explication de la solution.

Discussions précédentes: Sur cette même page (section MediaWiki:Common.css) et sur Wikipédia:Questions techniques (section CSS et lisibilité du code source de programmation). Si vous êtes un des utilisateurs qui avez crée une feuille de style local pour ces styles, n'oubliez pas de désactivé votre modification local pour voir le problème (et le résultat une fois le correctif appliqué).

Changement proposé : Après un délai suffisant pour voir s'il y a consensus, appliquer le correctif temporaire ci-dessous à la page MediaWiki:Common.css.

/* Corrige le problème de la taille de caractères de la balise <syntaxhighlight lang="text">.
   Retour à une taille normale jusqu'à ce que le bug [[Bugzilla:26204]] soit corrigé. */
div.mw-geshi div,
div.mw-geshi div pre,
span.mw-geshi,
pre.source-css,
pre.source-javascript {
    font-family: monospace, "Courier New" !important;
}

--Solitarius (d) 11 avril 2011 à 00:01 (CEST)Répondre[répondre]

MediaWiki:Geshi.css et bordures pour le source codeModifier

Pages où apparaît ce message : Les pages où les balises <syntaxhighlight> ou <source> sont utilisées.

Contre-indication: J'ai remarqué la présence du code « <div style="border:1px dashed green; padding:1em;margin:1em;"> » sur cette page, la modification suggéré pourrait entrer en conflit avec cette pratique si elle est répandu sur Wikipédia francophone.

Changement proposé : Ajouté le code suivant pour réactivé l'apparition de bordures pour les blocs de source code (ce source code est copié de la version anglophone de Wikipédia).

/* Bordures pour le code source */
 
body.skin-monobook div.mw-geshi {
  padding: 1em;
  border: 1px dashed #2f6fab;
  color: black;
  background-color: #f9f9f9;
  line-height: 1.1em;
}
 
body.skin-modern div.mw-geshi {
  border: solid 1px #3c78b5;
  padding: 0.4em;
  background-color: #f0f0f0;
}
 
body.skin-simple div.mw-geshi {
  margin: 2em;
  border: solid 1px black;
}
 
body.skin-chick div.mw-geshi {
  padding: 1em;
  border: 1px dashed #2f6fab;
  color: black;
  background-color: #f9f9f9;
  line-height: 1.1em;
}
 
body.skin-vector div.mw-geshi {
  padding: 1em;
  border: 1px dashed #2f6fab;
  color: black;
  background-color: #f9f9f9;
  line-height: 1.1em;
}

--Solitarius (d) 11 avril 2011 à 00:32 (CEST)Répondre[répondre]

Changement proposé : See Discussion_MediaWiki:Gadget-LastContrib.js#Bug_fixes

  Non
The advantage of this french version is that it does not use Ajax but get the last revision in the footer element.
I think it is better to avoid Ajax use when it is possible, like here.
⇨ Dr Brains ∞ Consultation ∞ 26 mai 2011 à 19:56 (CEST)Répondre[répondre]
Hi!
Thanks for fixing the link in the secure server.
I don't really understand why not to use the API: whithout it you'll need to create individual regexes to each combination of language+date preference in order to the script to works independent of the user preferences. E.g.: try changing from "Aucune préférence" to "2011-05-28T12:55:46" in the "Date et heure" section of your preferences. The script will stop in the following line
if(resultat==null) return;
because the regex only matches dates in the format specified.
There is also an inconsistency in the processing of the date of last change in the article and the current date. Taking the article Jean-Claude Narcy as an example:
  • Current version of the script gets the following values for the variables "last" and "now":
  • last: Sat May 28 2011 14:37:00 GMT-0300 (BRT) inconsistent with the value of "now", and causes the error "Erreur probable dans la concordance des horloges..."
  • now: Sat May 28 2011 10:05:22 GMT-0300 (BRT)
  • Version from Portuguese Wikipedia gets:
  • last: Sat May 28 2011 09:37:36 GMT-0300 (BRT) consistent with the value of "now", since the page was last modified less than one hour ago.
  • now: Sat May 28 2011 10:05:22 GMT-0300 (BRT)
Besides:
  • The UTCLiveClock says it is "13:05"
  • The Jean-Claude Narcy footer says it was modified "14:37"
  • My date settings are "Aucune préférence" and "Utiliser la valeur du serveur"
  • The preferences page says "Heure du serveur: 13:05" and "Heure locale: 15:05".
Helder 28 mai 2011 à 15:31 (CEST)
Using the API needs an Ajax request that occurs on every page. It is quite heavy, much more than parsing the footer. And some other gadget already do similar thing, for example Mediawiki:Gadget-HotCatsMulti.js (3 requests, 2 API and one in "action=raw" mode). Adding one when it can be done by another way is not a good idea, to my opinion. And I guess (but perhaps I am wrong) that the API will only provide UTC date, that can be not suitable.
For the formatting problem, may be it can be solved by
  • changing the regexp depending on the preference settings
  • trying different regexp (one for each format) and take care of the one who give good values for "last" and "now" (and "resultat")
  • creating a new gadget using Ajax (MediaWiki:Gadget-LastContribAjax.js)
⇨ Dr Brains ∞ Consultation ∞ 28 mai 2011 à 16:11 (CEST)Répondre[répondre]
Notice also that MediaWiki is inconsistent in how it displays time, in particular Bug 19002 may be affecting the current implementation of this gadget. Helder 3 juin 2011 à 22:47 (CEST)

Pages où apparaît ce message : Articles

Changement proposé :if (wgNamespaceNumber == 0) { le message } L'onglet ébauche apparait dans tous les espaces. Il faudrait y remédier en ne spécifiant que l'espace 0 (Principale). Je tiens d'ailleurs à dire que ce gadget est génial!! Merci Althiphika ΨΨΨ 4 juin 2011 à 13:19 (CEST)Répondre[répondre]

Le gadget teste explicitement si l'espace est > -1 sans s'assurer qu'il est == 0. Je préfère attendre l'avis de Dr Brains avant de faire quoi que ce soit.
Sinon, à la vue de cette liste, la suggestion me semble pertinente.
Amicalement — Arkanosis 5 juin 2011 à 15:11 (CEST)Répondre[répondre]
Salut,
Ce comportement est voulu : un portail, un modèle, une page d'aide, etc... peuvent aussi être des ébauches. Les seuls espaces où il est effectivement indiqué de désactiver l'onglet sont les pages de discussion.
⇨ Dr Brains ∞ Consultation ∞ 5 juin 2011 à 17:47 (CEST)Répondre[répondre]

Ajout de styles d'infobox V3 dans MediaWiki: Common.cssModifier

Bonjour,
Pour expliquer cette modification de common.css : les infobox (quel que soit leur version 1 ou 2) posent depuis longtemps de lourds problèmes d'accessibilité Web en raison du médiocre code HTML produit (le problème majeur étant la mauvaise utilisation des tableaux HTML qui mêlent dans ces modèles tableaux de mise en forme et tableaux de données d'une manière non conforme).

Les styles CSS et les modèles nécessaires à des infobox conformes aux normes internationales d'accessibilité sont en cours de mise en place (common. css, Utilisateur:Lgd/Infobox V3 accessibles). Formellement, il s'agit donc d'une « V3 » des infobox, sans impact majeur sur les choix de rendu déjà faits par les contributeurs (les changements concernent le code invisible derrière l'affichage).

Dans un premier temps, le projet:Hockey sur glace, fortement impliqué dans l'amélioration de l'accessibilité de ses contenus, sera le support de l'utilisation de ce nouveau jeu de modèles ([6]).

Ces modèles et ces styles sont généralisables à toutes les infobox actuelles et se destinent évidemment à le faire petit à petit.

Je pense préférable dans un premier temps au moins de ne pas s'engager sur la voie d'une PDD du type « infobox, on remet le couvert : adoption de la V3 ». En effet, il reste certainement du travail à faire pour que ce nouveau jeu de modèles et de style soit parfaitement à même de remplacer le précédent, compte-tenu des multiples variantes existantes. Autant commencer par des remplacements au cas par cas, immédiatement consensuels et surtout permettant de compléter et de consolider ces nouveaux modèles.

Cordialement, --Lgd (d) 12 juillet 2011 à 12:38 (CEST)Répondre[répondre]

Pages liées et suivi des pages liéesModifier

Il s'agit de plusieurs propositions:

  1. Remplacer le lien « Pages liées » (dans la colonne de gauche des menus de certaines pages Wikipédia) par « Liens entrants », remplacer le texte de l'infobulle actuel : « Liste des pages liées à celle-ci » par : « Liste des pages possédant un lien entrant vers celle-ci » et écrire « Pages possédant un lien entrant vers $1 » en début de la page spéciale.
  2. Remplacer le texte de présentation de la page spéciale actuellement « Cette page spéciale montre les modifications récentes sur les pages qui sont liées. Les pages de votre liste de suivi sont en gras. » par : « Cette page spéciale montre les modifications récentes des pages qui possèdent au moins un lien entrant vers la page précédente et/ou des pages pointées par au moins un lien sortant de la page précédente. Les pages de votre liste de suivi sont en gras. »

Débat préalable et vote de concertation possible sur cette page, Lionel Scheepmans Me contacter , le 22 juillet 2011 à 16:31 (CEST)Répondre[répondre]

C'est un peu tôt pour qu'on puisse bouger quelque-chose, en la quasi absence d'avis sur la page indiquée. Rien ne presse, on verra quand il y aura des avis...   Cordialement, --Lgd (d) 22 juillet 2011 à 16:40 (CEST)Répondre[répondre]
Bah ! Ça aura au moins l'avantage d'attirer l'attention des gens qui passerons par ici. Je suis pas pressé de nature mais dans les circonstances de mon travail, j'étais impatient de voir la suite des opérations. Mais bon voilà, comme le dit Freewol, ça peut attendre la fin de l'été. Malheureusement, dans ce cas je ne serai sans doute plus aussi présent sur fr.wikipedia. D'autres reprendrons la relève. Bonne continuation ! Amicalement, Lionel Scheepmans Me contacter , le 23 juillet 2011 à 12:45 (CEST)Répondre[répondre]

Page MediaWiki inconnueModifier

Pages où apparaît ce message : Page utilisateur

Changement proposé : Ajouter un onglet avec une enveloppe, aboutissant sur la création d'une section dans la page de discussion de l'utilisateur concerné. Est-ce faisable ? Trizek bla 29 août 2011 à 15:46 (CEST)Répondre[répondre]


MediaWiki:Common.css (curseur au passage sur une abréviation)Modifier

Pages où apparaît ce message : Est-il besoin de que précise ?

Changement proposé par le comte Ɲemoi – Les modifications apportées par Phe au Common.css ne sont pas satisfaisantes, loin de là ; celui-ci se refusant à en discuter , j’apporte ici ma requête. S’il est normal que le curseur ne soit pas modifié sur ceci (qui ne se destine qu’à faciliter la lecture des appareils), il devrait pour l’ergonomie l’être sur cela (le soulignement étant là pour attirer l’attention, il faut un marquage clair d’une interactivité au passage de la souris).

Il faudrait donc retirer le « cursor:inherit; » de l’entrée « abbr ». Accessoirement, si vous n’étiez pas d’accord avec la chose, c’est l’autre ligne qu’il faudrait retirer, celle dans l’entrée « abbr.abbr » (je vous laisse contempler ce diff …). J’invite en passant l’administrateur qui prendra en charge cette requête à rappeler dans le commentaire que le Common.css n’est pas un jouet, et qu’il existe des pages pour discuter de son contenu. Ce 22 octobre 2011 à 18:13 (CEST).

[[MediaWiki: ]] Annonces demande de dons fonctionnent pasModifier

Pages où apparaît ce message : Avis sur Toutes pages: Veuillez lire : un appel personnel de JimmY Wales ou de Brandon Harris, programmeur pour Wikipédia et le boutton Lissez maintenantses links ne fonctionnent pas.

Changement proposé : Reparer les links autrement votre campagne de recollection de fons ne sera pas bonne. !!!

Salutations et merci,

JOSE SANCHO sancho_chang1@videotron.ca