Discussion utilisateur:Dr Brains/Archives/21 12 2010

Archives
13 02 2010 01 04 2010 20 05 2010 09 07 2010 29 11 2010 21 12 2010 05 05 2011	25 07 2011 06 10 2011 12 05 2012 11 08 2013 31 12 2013 29 12 2014
Récompenses
Ajouter

Bug ?

Pourquoi le bot a t-il fait ça ? Kolossus (d) 24 novembre 2010 à 01:36 (CET)

J'en sais fichtre rien.

Apparemment il a corrigé de lui-même au passage suivant.

J'ai remarqué que lorsqu'il tournait trop longtemps (genre plusieurs jours non-stop), il lui arrivait de déconner un peu, par exemple de temps en temps il crée la page Undefined (ce qu'il ne peut plus faire maintenant que je l'ai protégée à la création).

Je soupçonne une saturation de la mémoire ou un truc dans le genre. Ce qui est sûr c'est que cela ne vient pas du code proprement dit. Si tu vois que ça lui re-arrive, n'hésites pas à reverter.

⇨ D^r Brains ^{∞ Doléances ∞} 24 novembre 2010 à 02:25 (CET)

Modèle:Browsebar

Bonjour, au sujet de cette modif, bien vu Tant que nous y sommes, on pourrait remplacer ces <font> dépréciés par des <span>. od†n ^{[dead words]} 26 novembre 2010 à 09:12 (CET)

Fait.

⇨ D^r Brains ^{∞ Doléances ∞} 26 novembre 2010 à 18:52 (CET)

Super, merci Une petite pub au passage, pour la proposition que j'ai fait ici ; je devrais tantôt poster un message sur le bistro pour essayer de recueillir quelques avis. od†n ^{[dead words]} 26 novembre 2010 à 20:47 (CET)

bot ou script

Bonjour, connais tu un bot ou un script qui permettrait de rajouter une évaluation en page de discussion en fonction du portail mis sur l'article? Ex: pour les articles ayant le bandeau "portail colombie", pouvoir créer une une évaluation pour le "projet colombie" en page de discussion. cordialement. Lepsyleon (d) 26 novembre 2010 à 12:56 (CET)

Il faut voir sur Wikipedia:Bot/Requêtes. C'est vrai que l'évaluation a pris un sacré retard avec toutes ces nouvelles pages de municipalités...

⇨ D^r Brains ^{∞ Doléances ∞} 26 novembre 2010 à 18:10 (CET)

Ok, merci. Je ferai donc une requête sur Wikipedia:Bot/Requêtes lorsque j'aurai fait toutes les municipalités.

Lepsyleon (d) 26 novembre 2010 à 19:21 (CET)

Merci

Salut, merci pour le coup de main sur le code pour LRC. Bonne soirée :) Argos42 (d) 27 novembre 2010 à 22:41 (CET)

Fonction hasClass()

Bonjour, après quelques recherches supplémentaires, je suis arrivé à une proposition de code alternative, aux performances restant très bonnes (toujours bien meilleures que le code actuel), mais surtout à la syntaxe bien plus courte, se payant même le luxe d'être plus courte que le code actuel Pour rappel ça se passe ici, je t'invite à y laisser un mot pour trancher en faveur de l'un ou l'autre des codes proposés, que l'on puisse rapidement procéder à l'implémentation. Bien à toi, od†n ^{[dead words]} 28 novembre 2010 à 10:04 (CET)

Je sais, j'ai suivi votre discussion (j'ai un gros bandeau orange qui s'affiche si la page Discussion Projet:JavaScript (et quelques autres) est modifiée).

A choisir, je prends le moins lourd en terme de performance. La longueur du code est un peu accessoire. Tant qu'à faire, il faudrait voir aussi les autres fonctions de manipulation de classe (addClass() et removeClass() notamment), histoire de tout optimiser d'un coup.

⇨ D^r Brains ^{∞ Doléances ∞} 28 novembre 2010 à 10:10 (CET)

Je ne me suis pas (encore) penché sur ces fonctions. De ce que j'ai vu du Common.js, ainsi que de quelques scripts, il y a effectivement beaucoup à faire au sujet des performances. Ça tombe bien, j'adore ça.

Sinon, j'ai été étonné de ta préférence pour ma proposition de code la plus longue ; je pensais que tout le monde allait opter pour la nouvelle proposition, tellement le code est court en comparaison. Attendons quelques avis supplémentaires, voir ce que ça donne.

Autre chose, je vois que très souvent (quasiment tout le temps, en fait), les éléments sont parcourus à partir de document, alors que nous disposons d'un joli id bodyContent qui ne demande qu'à être utilisé. Aurais-tu à ta connaissance des contre-indications à l'utilisation de cet id pour démarrer le parcours des éléments ?

– od†n ^{[dead words]} 28 novembre 2010 à 10:23 (CET)

La contre-indication majeure c'est que tous les skins disponibles n'utilisent pas cette ID (voir ici pour les équivalences). Or, il faut bien les prendre en compte dans le développement, même si il est certain que tous les utilisateurs sont sous vector ou sous monobook.

⇨ D^r Brains ^{∞ Doléances ∞} 28 novembre 2010 à 10:49 (CET)

Merci beaucoup pour ce lien, je ne l'avais jamais vu avant, une véritable mine d'or. od†n ^{[dead words]} 28 novembre 2010 à 11:26 (CET)

Wikimag - Semaine 47

Wikipédia:Wikimag/2010/47 CaBot 29 novembre 2010 à 01:10 (CET)

portail colombie

Bonjour, j'ai vu que tu retravaillais le portail colombie ainsi que ses autres pages liées. Tout d'abord, ce nouveau design avec les dégradés de couleurs me semble bien moins sobre visuellement que l'ancien. Par ailleurs, j'ai noté plusieurs bugs d'affichage, étant en 1024*768:

• sur la page du portail:
  • Portail:Colombie/Entête : l'ancienne présentation me semblait plus claire, car maintenant, cela fait trop tassé entre le texte (qui s'étend sur 10 lignes avec 2 mots par ligne), le drapeau et l'image.
  • Portail:Colombie/Image au hasard : les images débordent du cadre de la page web, d'où une barre de défilement qui apparait en bas du navigateur.
• sur la page du projet:
  • Projet:Colombie/Évaluation/Statistiques_détaillées : ce tableau est coupé. On ne le voit pas intégralement.

Cordialement. Lepsyleon (d) 29 novembre 2010 à 08:16 (CET)

Salut, effectivement, je chamboule pas mal de choses.

Pour la sobriété, les couleurs pourront changer, c'est à voir. Pour le moment, les seules choses que j'ai changées au rendu sont l'effet dégradé, le retour des arrondis, les barres de titre entourées d'une bordure et la couleur jaune pâle entre cette bordure et le cadre intérieur des barres de titre. Tout cela (sauf la deuxième bordure autour des titres) peut être modifié.

Cela dit, les changements que j'apporte sont plus profonds qu'il n'y paraît. J'ai regroupé toute la syntaxe compliquée dans un unique modèle {{Cadre 3D 2}}. C'est lui qui gère la présence ou nom d'onglets, la présence ou non de barre de titre, les bordures suivant si c'est un cadre "normal" ou un cadre sans bordure (ex-"cadres dynamiques"), etc. En tout il y plus d'une trentaine de paramètres...

Pour le portail Colombie (et les autres pages du projet), cela aboutit à :

1. La suppression de Portail:Colombie/Cadres dynamiques et Portail:Colombie/Onglets ;
2. L'utilisation de seulement deux modèles très simples : Portail:Colombie/Cadre standard (sans onglets) et Portail:Colombie/Cadre introduction (avec onglets).

Tout ça est encore en chantier donc il peut arriver qu'il y ait des bugs d'affichage. Tout retour est le bienvenue.

• Pour Portail:Colombie/Entête, je n'y retoucherait pas de suite, donc si tu veux déplacer la phrase qui prend trop de place (le décompte des articles, je présume) ou le sommaire désormais possible via ce nouveau modèle, n'hésites pas.
• Pour Portail:Colombie/Image au hasard et Projet:Colombie/Évaluation/Statistiques_détaillées (je pense que tu parles de l'inclusion dans Projet:Colombie), c'est bizarre car ayant modifié le système d'onglets, ceux-ci n'encadrent plus la totalité de la page comme avant, du coup il y a plus de place en largeur et je ne comprends pas trop comment cela se fait que ces cadres débordent maintenant si ils ne le faisaient pas avant.

Enfin bon, bref, le travail n'est pas encore fini, même si il est bien avancé.

⇨ D^r Brains ^{∞ Doléances ∞} 29 novembre 2010 à 08:45 (CET)

Bon, j'ai fini le gros de ce que j'avais à faire. {{Cadre 3D 2}} et sa doc sont désormais finis, et le portail Colombie n'utilise désormais plus qu'un seul modèle : Portail:Colombie/Cadre. C'est lui qui gère tout : les onglets, les couleurs, etc...

Donc, si tu souhaites re-changer les couleurs pour du plus sobre, tu peux.

Tu as toujours les deux bugs dont tu me parlais tout-à l'heure ?

⇨ D^r Brains ^{∞ Doléances ∞} 29 novembre 2010 à 10:14 (CET)

Oui, toujours pour Portail:Colombie/Image au hasard et Projet:Colombie/Évaluation/Statistiques_détaillées... Pour [Portail:Colombie/Entête]], j'ai apporté quelques retouches mais il faudrait peut-être voir pour une autre présentation du sommaire.

Lepsyleon (d) 29 novembre 2010 à 11:34 (CET)

OK, j'ai trouvé d'où ça vient pour Portail:Colombie/Image au hasard. En fait, j'ignore encore pourquoi, mais lorsqu'incluse dans la page du portail, l'image panoramique ne présente pas l'ascenseur horizontal qu'elle devrait, du coup elle "pousse" la limite droite de la page et les autres images en profitent pour se carapater aussi.

Tu confirmes ?

⇨ D^r Brains ^{∞ Doléances ∞} 29 novembre 2010 à 11:54 (CET)

Oui, c'est bien ça! tu sais comment résoudre ce problème? Lepsyleon (d) 29 novembre 2010 à 11:59 (CET)

Gadget OuvrageArticle

Salut, juste pour te signaler que je viens d'ajouter la prise en compte des paramètres "spage et "epage" par le script.

Désolé du retard.

⇨ D^r Brains ^{∞ Doléances ∞} 29 novembre 2010 à 13:17 (CET)

Merci et pas de souci: je ne paye pas donc je ne peux rien exiger :-) Snipre (d) 29 novembre 2010 à 13:46 (CET)

Petite question sur les images qui s'agrandissent quand on passe la souris dessus

Bonjour, est-il possible d'ajouter un temps d'attente de quelques centaines de milliseconde quand la souris survole une image afin qu'elle ne commence pas immédiatement à s'agrandir car je pense que les autres contributeurs sont comme moi, ils ne veulent pas systématiquement agrandir les images des articles. Merci de ta réponse. --Thesupermat ^{[you want to talking to me ?]} 30 novembre 2010 à 14:15 (CET)

C'est tout à fait possible. Je vais voir ça.

⇨ D^r Brains ^{∞ Doléances ∞} 30 novembre 2010 à 14:17 (CET)

Fait.

Donc il y a deux nouvelles variables, ZoomOnThumb_Delay et ZoomOnGallery_Delay qui conditionnent le délai avant le début du zoom. Elles s'expriment en milisecondes, 200 par défaut.

Voir Projet:JavaScript/Notices/ZoomOnThumb#Paramètres que je viens de mettre à jour.

⇨ D^r Brains ^{∞ Doléances ∞} 30 novembre 2010 à 14:36 (CET)

Cette catégorie

que tu as renommée, présentait l'avantage de regrouper dans un même sac les mathématiciens et les historiens, qui ont montré quelque intérêt marqué pour l'algèbre spécieuse et les historiens qui se sont plus particulièrement intéressé à la vie de Viète. Certains aux deux. Quant tu renommes une page... essaie de comprendre le but dans lequel elle a été créée. Il y a trop peu de l'un et de l'autre pour se priver de la dénomination collective "Biographes de Viète, spécialistes de l'AN". Je sais bien que les recommandations de Wp sont de tout mettre au singulier. Mais dans ce cas, je ne vois pas d'autres solutions pour signaler cette catégorie.Jean ^{[de Parthenay]} 3 décembre 2010 à 08:26 (CET)

Bonjour,

Catégorie:Biographe de Viète, spécialiste de l'algèbre nouvelle fonctionne aussi bien. Le pluriel ne s'impose pas.

Maintenant, je ne vois pas bien l'intérêt de ", spécialiste de l'algèbre nouvelle", à moins qu'à terme tu souhaites créer une Catégorie:Biographe de Viète, pas spécialiste de l'algèbre nouvelle

Cela dit, lors que le titre est incertain, se poser cinq minutes et se demander si la catégorie mérite vraiment création n'est pas forcément superflu. Enfin, j'imagine que ce sera discuté sur le bistro...

Sinon, une autre catégorie m'a un peu fait tiquer : Catégorie:Les lieux de François Viète. Outre le déterminant "Les" qui est superflu, et l'usage là aussi du pluriel, je ne vois pas bien l'intérêt. Si c'est pour regrouper dans une même catégorie tous les lieux où il a séjourné, le portail fait ça très bien. Nul besoin de créer une catégorie. Imagine que l'on fasse la même chose pour tout le monde. On se retrouverait par exemple avec une Catégorie:Lieu de Nicolas Sarkozy regroupant la moitié des communes françaises.

Sans vouloir te prendre de haut, une relecture de Aide:Catégorie et en particulier de Aide:Catégorie/Organiser te serait sans doute salutaire. Pour ma part, après avoir procédé à ce renommage, et m'étant aperçu que, selon moi, la plupart des catégories liés à François Viète sont à revoir, je m'empresse de me dé saisir de ce dossier, qui ne m'intéresse guère, à vrai dire.

⇨ D^r Brains ^{∞ Doléances ∞} 3 décembre 2010 à 08:44 (CET)

Merci pour ta collaboration pour le portail. C'est parfait. D'autre part : Si tu trouves un nom convenable pour ces catégories, tu es bienvenu : je n'ai rien contre évidemment... Mais essaie de m'en parler avant pour qu'on cerne mieux le champs, que ce ne soit pas trop limitatif ou en porte faux, c'est tout. Jean ^{[de Parthenay]} 3 décembre 2010 à 18:02 (CET)

{{Autres projets}}

Bonjour, c'est au sujet des améliorations de présentation que tu viens d'apporter aux boîtes {{Autres projets}}. C'est vrai que c'est bien plus lisible quand on distingue plus clairement le titre. J'aime bien les guillemets, je trouve que c'est une bonne idée. Par contre, avec en plus la virgule je trouve que ça fait un peu lourd, je te propose de mettre seulement les guillemets mais pas la virgule, ça te conviendrait ? Cordialement, od†n ^{[dead words]} 4 décembre 2010 à 06:44 (CET)

Je ne sais pas. En l'absence de différenciation plus claire (par exemple que le "sur wikimachin" ne soit pas en italique), la virgule me semble quand même utile.

Je suis déjà intervenu deux fois sur ce modèle très utilisé, presque unilatéralement. Alors bon, je ne voudrais pas pousser.

Le mieux est de lancer une discussion ici et d'en parler sur le bistro.

Techniquement, pour enlever l'italique, il suffirait d'entourer le contenu du lien d'un span avec une class précise (par exemple "AutreprojetsSource") et d'en définir les attributs dans MediaWiki:Common.css.

Après, tout est question de choix éditorial, et je ne me sens pas forcément habilité à le faire tout seul dans mon coin.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 08:40 (CET)

Mélanger style normal et italique au sein d'un passage lui-même en gras me semble assez peu recommandable d'un point de vue typographique. Et surtout, je trouve que l'italique ne porte pas clairement l'information (distinction titre/projet).

• Lorem ipsum dolor sit, amet consectetur adipisicing (elit sed do eiusmod tempor)

Je me suis rendu compte d'un autre inconvénient, c'est que l'on utilise les guillemets pour véhiculer une information à laquelle elles ne sont pas du tout destinées, c'est en quelque sorte un bricolage

• « Lorem ipsum dolor sit », amet consectetur adipisicing (elit sed do eiusmod tempor)
• « Lorem ipsum dolor sit » amet consectetur adipisicing (elit sed do eiusmod tempor)

On peut imaginer foison d'autres approches, par exemple retirer du gras comme ceci, ce qui a l'avantage de créer un lien plus fort entre le nom du projet et la description entre parenthèses :

• « Lorem ipsum dolor sit » amet consectetur adipisicing (elit sed do eiusmod tempor)
• Lorem ipsum dolor sit, amet consectetur adipisicing (elit sed do eiusmod tempor)

Sinon, j'ai déjà un peu survolé les discussions qui avaient eu lieu, il me semble que tout le monde est d'accord pour une distinction visuelle entre le titre et le nom du projet. Donc tes modifications, assurément, ont déjà amélioré la situation.

Cordialement, od†n ^{[dead words]} 4 décembre 2010 à 09:05 (CET)

Bonjour,
La virgule est syntaxiquement incorrecte dans ce cas. Pour l'ajout éventuel de span, attention au fonctionnement du script qui récupère le contenu du premier span inclus dans le lien pour générer le title du lien dans le menu en colonne de gauche. Pour une emphase sur le titre de page, utilisez plutôt un em stylé comme vous le souhaitez. Cordialement, --Lgd (d) 4 décembre 2010 à 09:13 (CET)

@Odin : comme je le disais, c'est un choix éditorial, que je ne sens pas habilité à faire, ni forcément qualifié (les conventions typographiques, je connais que de très loin).

@Lgd : Oui, après avoir vérifié, l'ajout d'un span n'est pas compatible avec le script tel qu'il est actuellement. Mais vu que cela me semble la seule façon de changer le style CSS de ce bout du lien, il faudra donc faire évoluer le script (peut-être avec un getTextContent(link) ?). Des tests seront donc nécessaire avant d'appliquer une telle modification sur le modèle (en n'oubliant pas la mise à jour du cache des utilisateurs).

Une autre solution serait de sortir le "sur wikimachin" du lien, comme c'est fait dans {{CommonsCat}}, mais là aussi il faut vérifier que le script réponde correctement.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 09:32 (CET)

Ne copiez pas les discussions dans ma page svp, je suis celle-ci.

Il suffit d'utiliser EM pour styler au lieu du SPAN que vous voulez ajouter (et ce sera tout à fait approprié du point de vue sémantique). Cela dit, le script est certainement améliorable (à défaut de le supprimer, ce qui serait le plus avisé en fait : la gestion des liens interprojets est trop complexe éditorialement pour être traitée avec ce système de modèle unique et de javascript pour simuler ce qui se fait avec les liens interwikis). Cordialement, --Lgd (d) 4 décembre 2010 à 09:52 (CET)

Ah oui, je n'avais pas capté le coup du <em>. Effectivement, ça règle le problème puisqu'on aura alors à l'intérieur du lien :

« La page de Commons » <em class="AutreprojetsSource">sur <span>Commons</span></em>

Le premier span est donc toujours correctement attribué au site, et un autre élément permet de mettre un style différent du reste du lien (à moins que tu pensais faire l'inverse et entourer « La page de Commons » par le <em> ?)

Pas de soucis.

Ne reste plus qu'à se décider pour le style.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 10:07 (CET)

Optimisation JavaScript

C'est encore moi

Il faudrait passer en production la function hasClass() que j'ai dopée aux stéroïdes. (pour rappel, elle est ici, la proposition initiale est la bonne)

Autre chose, j'ai retravaillé la fonction addcache() (un véritable goulot d'étranglement), le résultat se trouve ici, code se trouvant dans la section « Code final ». J'ai procédé aux derniers peaufinages, j'ai tout bien testé et vérifié, pour moi le code est fin prêt pour être mis en prod. Les performances, à défaut d'être fulgurantes, sont déjà moins pires. Le benchmark le prouve.

Cordialement, od†n ^{[dead words]} 4 décembre 2010 à 10:27 (CET)

Rah ! Plus moyen d'écrire des articles tranquille... Vivement que tu sois admin !

Bon, je m'occupe de hasClass(), et je vois pour addCache() (c'est le script qui ajoute les liens [archive] aux références, non ?)

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 10:31 (CET)

addClass() est petit et sûr de sûr, tu peux y aller. Pour addcache(), tout à fait, c'est le script qui ajoute les [archive]. Pour ma part je n'ai repéré aucun bug, j'en ai même corrigé. Après si tu veux, on peut attendre un peu, histoire que d'autres personnes y jetent un œil. Et désolé pour les bandeaux oranges od†n ^{[dead words]} 4 décembre 2010 à 10:37 (CET)

Avec le nouveau addClass() je viens de repérer un changement : les boîtes déroulantes, qui étaient auparavant enroulées au chargement, sont maintenant déroulées. J'essaie de voir de quoi ça vient (le bug est peut-être au niveau du script des boîtes, qui sait ?), je te tiens au courant. od†n ^{[dead words]} 4 décembre 2010 à 10:47 (CET)

(Edit) Mmh, tu as remplacé :

    var external_links;
    if (document.getElementsByClassName) {
      external_links = document.getElementsByClassName('external');
    } else {
      external_links = getElementsByClass('external',document.getElementById("bodyContent"),'a');
    }

par

        var collections_count;
        var collections = [];
        if (document.getElementsByClassName) {
            var references = document.getElementsByClassName('references');
            collections_count = references.length;
            for (var i = 0; i < collections_count; i++) {
                collections[i] = references[i].getElementsByClassName('external');
            }
        } else {
            collections_count = 1;
            collections[0] = $j('ol.references a.external').get();
        }

1. filter dès le départ les class"references" (ce qui est une bonne chose)
   • Points négatifs :
     • faire une recherche getElementsByClassName() sans préciser le tag "ol" (ou "a")
     • faire la recherche sur tout le document et non sur le contenu de la page (mais peut-être les tests nécessaires pour déterminer le skin actif bouffent l'avantage que cela procurerait)
2. a priori, document.getElementsByClassName devrait être toujours défini. Si ce n'est pas le cas, recourir systématiquement à la syntaxe jQuery ne serait-il pas préférable en termes de performances ?

A part ça, j'ai mis à jour hasClass(); (mais ça tu l'as vu apparemment). Pour le bug, vite, sinon, je reverte. On ne peut pas se permettre de jouer les apprentis-sorciers avec cette fonction-là.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 10:51 (CET)

J'ai trouvé le bug de hasClass(). Si la node n'a pas de classe, haystack.indexOf() renvoie un erreur.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 10:55 (CET)

J'avais de mon côté repéré le problème au niveau de cet appel : javascript:toggleNavigationBar(5);, note le type integer (évidemment le problème n'a rien à voir avec ce type int, je mets ça sur le compte de la précipitation). Bon, vu que tu as corrigé plus vite que ton ombre, je vais pouvoir regarder le correctif à tête reposée od†n ^{[dead words]} 4 décembre 2010 à 10:58 (CET)

Oui, sur common.js, on ne peut pas se permettent d'attendre. Les utilisateurs ne peuvent pas le désactiver comme un vulgaire gadget. C'est d'autant plus vrai sur cette fonction très utilisée.

En fait, je n'ai pas encore réagi assez vite. J'aurais dû tester moi-même qu'il n'y ait pas de problème. Je t'ai trop fait confiance...

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 11:01 (CET)

Concernant le addcache() :

• apparemment il est inutile de vérifier les tags OL et A, les classes étant suffisamment précises, mais peut-être que je me trompe ?
• les getElementByClassName natifs tournent à la vitesse de la lumière, donc mieux vaut faire direct sur le document plutôt que d'ajouter des tests pour déterminer le skin. Quand au sélecteur jQuery, ce qui est un peu étonnant d'ailleurs, il est plus performant si on fait sur tout le document plutôt qu'à partir de l'id du contenu.
• La méthode avec le getElementsByClassName natif est plus performante que la méthode avec le sélecteur jQuery. Il doit y avoir une confusion quelque part dans mes comperatif, ne tenez pas compte de cette remarque, j'ai des trucs à revérifier

od†n ^{[dead words]} 4 décembre 2010 à 11:12 (CET)

OK pour jQuery/getElementsByClassName.

Par contre, pour les tags, cela me semble nécessaire, sinon il va inspecter chaque élément de la page, y compris ceux dont on sait qu'ils ne correspondent pas. Ajouter un filtre au niveau du tag ne peut qu'être bénéfique. Enfin, il faudrait voir exactement comment cette fonction fonctionne pour en être sûr, ou au pire faire des tests de performances.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 11:21 (CET)

Chuis casse-pieds, je sais . Dans ce cas, il faudrait tester les perfs du script entièrement réécrit en jQuery. Pensez aussi à optimiser MediaWiki:Gadget-ExtendedCache.js, le cas échéant. Cordialement, --Lgd (d) 4 décembre 2010 à 11:24 (CET)

Mais non. Trois cerveaux valent mieux que deux.

Pour le jQuery, je passe. Pour moi, c'est encore du chintoc.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 11:32 (CET)

Je te vous convertirai (si moi j'y arrive, des passionnés du js comme vous doivent pouvoir devenir des dieux du jQuery ). Pour le côté chinetoc, je crois qu'une fois qu'on a bien réalisé que les sélecteurs étaient directement déclinés des sélecteurs CSS, cela change tout. Plus sérieusement, j'y vois au moins trois avantages énormes (avec d'éventuels défaut de perf ponctuels pour lesquels il faut arbitrer habilement entre jquery et script vanilla) : beaucoup moins de soucis de debug et de compatibilité ; beaucoup moins de risques de fonctions redondantes ; la mutualisation des fonctions de base via l'appel unique à http://bits.wikimedia.org quelque-soit le projet (avec les gains de cache navigateur que cela implique).

Si vous voulez, je fais une version de addcache() (ou mieux de MediaWiki:Gadget-ExtendedCache.js) en jQuery pour que vous puissiez tester les perfs (mais attention, je me sers de jQuery comme un chimpanzé qui empoigne un horaire de chemin de fer), éventuellement via un gadget de test (voir ci-dessous). Cordialement, --Lgd (d) 4 décembre 2010 à 11:56 (CET)

Je suis déjà subjugué par jQuery. Et à propos il n'y a pas que les sélecteurs CSS, on peut même faire du XPath pour les plus téméraires. Quant aux perfs, il faut voir au cas par cas, mais en règle général jQuery se débrouille très bien, c'est l'une des raisons pour lesquelles j'apprécie cette lib. od†n ^{[dead words]} 4 décembre 2010 à 12:07 (CET)

Il y a du nouveau concernant l'optimisation de addcache(), voir ici. La nouvelle proposition est bien plus simple et globalement plus performante. Contrairement à hasClass(), j'ai pu la tester avec mon espace utilisateur. Elle peut être passée en prod. Lgd comme tu suis cette page, si jamais tu veux t'en occuper Comme ça je pourrai embrayer sur la suite, setModifySectionStyle().  – od†n ^{[dead words]} 7 décembre 2010 à 15:23 (CET)

Heu, pas trop sur le coup tout de suite : je suis là sans être là alors que je ne devrais pas être là. Du coup je préfère ne pas m'occuper de choses compliquées qui demandent un peu plus de disponibilité. Si ça n'est pas urgent, attendez-moi un peu, sinon, allez-y comme ça, vous ne devriez pas casser tout le Web, normalement. Cordialement, --Lgd (d) 7 décembre 2010 à 16:19 (CET)

Pas de souci, je sais que tu es occupé en ce moment, c'est simplement parce que j'avais vu que tu étais connecté à ce moment. od†n ^{[dead words]} 7 décembre 2010 à 16:42 (CET)

Peut-être remplacer

            if (element_parent.className === "noarchive") {
                continue;
            }

par

            if (hasClass(element_parent, "noarchive")) {
                continue;
            }

histoire d'éviter une possible mauvaise surprise.

Sinon ça me semble pas mal.

⇨ D^r Brains ^{∞ Doléances ∞} 7 décembre 2010 à 15:30 (CET)

Ok pour ta modif. Dans l'absolu, chercher le "noarchive" seulement dans le parent immédiat n'est pas une approche très satisfaisante, ça serait un point à améliorer ultérieurement. od†n ^{[dead words]} 7 décembre 2010 à 15:42 (CET)

Autre chose, comme je garde en tête ce message, je voudrais savoir s'il serait utile d'extérioser la fonction ? c'est-à-dire passer de :

if (wgNamespaceNumber === 0) {
    addOnloadHook(function addcache() {
        if (typeof no_external_cache !== "undefined" && no_external_cache) {
            return;
        }
        // traitements
    });
}

à quelque chose du genre :

function addcache() {
    if (typeof no_external_cache !== "undefined" && no_external_cache) {
        return;
    }
    // traitements
}
if (wgNamespaceNumber === 0) {
    addOnloadHook(addcache);
}

– od†n ^{[dead words]} 7 décembre 2010 à 17:28 (CET)

OK pour le changement

Reste le problème de la récupération des liens à l'interieur d'un élément spécifique (par défaut le <body>.

Ca pourrait se régler comme ça (si j'ai bien compris le principe de jQuery):

function addcache(Element) {
    if (typeof no_external_cache !== "undefined" && no_external_cache) {
        return;
    }
    if(!Element) Element = "body";
    var liens = $j(Element + ' ol.references a.external');
    for (var i = 0, l = liens.length; i < l; i++) {
        // traitements
    }
}
if (wgNamespaceNumber === 0) {
    addOnloadHook(addcache);
}

On pourra alors rappeler la fonction ultérieurement et l'appliquer à un élément en particulier comme ça :

addcache('#MyId');

// ou

addcache('.MyClass');

⇨ D^r Brains ^{∞ Doléances ∞} 7 décembre 2010 à 17:45 (CET)

Ou alors comme ça, mais de toute façon les perfs semblent inchangées :

    var liens = element ? $j(element + ' ol.references a.external') : $j('ol.references a.external');

Ce qui m'intéresse le plus dans cette problématique, c'est la gestion des namespaces. Je pense notamment à la situation où ton script incorpore une page d'un autre namespace.

Mais attention à ne pas mélanger les problématiques. On pourrait déjà mettre en place l'optim de perfs, pour ensuite s'occuper sereinement de la modularité des composants.  – od†n ^{[dead words]} 7 décembre 2010 à 18:24 (CET)

Je ne vois pas ce que tu veux dire. En faisant comme indiqué plus haut, le script s'active par défaut dans le namespace 0 et sur tout le body, mais rien n'empêche de le rappeler sur un autre élément et/ou dans un autre namespace.

⇨ D^r Brains ^{∞ Doléances ∞} 7 décembre 2010 à 18:29 (CET)

Concernant le namespace, j'ai effectivement réfléchi de façon trop tordue (je t'épargne les détails). La solution ci-dessus est parfaite. Concernant le paramètre element, j'ai effectué quelques tests et en fait ça va un peu moins vite avec le body ajouté dans le sélecteur. C'est assez critique avec les vieux IE, car vu que les perfs sont désastreuses, toute économie est bonne à prendre. Ma solution avec l'assignation ternaire te convient ? od†n ^{[dead words]} 7 décembre 2010 à 18:51 (CET)

Si ça marche, oui.

⇨ D^r Brains ^{∞ Doléances ∞} 7 décembre 2010 à 19:07 (CET)

Ah ah, ça ne marche pas comme ça, "ReferenceError: pouet is not defined" autant pour moi : dans une fonction ça fonctionne tout à fait, l'interpréteur JS référençant les arguments même s'ils sont undefined  –  od†n ^{[dead words]} 7 décembre 2010 à 19:18 (CET)

Espace de dev

Comme je vous ai tous les deux sous la main, je profite de l'occasion pour vous soumettre une idée à propos des développements javascript, qu'il s'agisse de gadgets ou de common.js.

Nous manquons d'un véritable espace de test avant la mise en production. On bricole chacun comme on peut avec les vector.js personnels, mais c'est loin d'être commode. or, nous pourrions utiliser la fonctionnalité de gadget à cet effet :

• en créant une section supplémentaire dans MediaWiki:Gadgets-definition : « gadget en développement » (assortie d'une brève explication pour les contributeurs sur le mode : ne cochez pas ces gadgets si vous ne souhaitez pas participer à leur développement, par exemple)
• et en systématisant dans différentes fonctions de MediaWiki:Common.js la variable initiale qui permet de les désactiver au plus simple, comme c'est le cas par exemple avec no_external_cache (voir son utilisation dans MediaWiki:Gadget-ExtendedCache.js.

De cette manière, nous pourrions travailler plus facilement (et avec d'autres contributeurs) lors de l'optimisation ou du développement de gadgets ou de fonctionnalité intégrées via common.js, il me semble ?

A terme, on peut même imaginer un mécanisme collaboratif de validation des scripts avant passage en prod.

Vos avis ? Cordialement, --Lgd (d) 4 décembre 2010 à 11:43 (CET)

Très bonne idée.

En fait, j'ai peut-être encore mieux à proposer : Utilisateur:Dr Brains/GlobalManager.js (documentation).

C'est un script qui s'active dans les pages personnelles .js. Il permet de choisir via des cases à cocher le ou les scripts à installer/désinstaller et la mise à jour de la page .js se fait automatiquement en Ajax (des commentaires sont insérés pour délimiter la section gérée par ce script, voir mon monobook).

Or donc, en l'adaptant (renommage des variables et des fonctions, commentaires différents), en le mettant en gadget, on disposerait d'une liste séparée de script (ou de sous-pages utilisateur de test) que chaque personne qui souhaite participer au développement pourrait ajouter/enlever facilement de son .js perso.

Pour aussi la systématisation des variables de désactivation.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 11:58 (CET)

D'accord dans l'ensemble. Déjà, MediaWiki:Gadgets-definition aurait besoin d'être réorganisé : des scripts abandonnés ou expérimentaux se promènent au milieu des scripts stables... od†n ^{[dead words]} 4 décembre 2010 à 12:10 (CET)

Questions : Une page de la forme Projet:JavaScript/Développement/MonScript.js fonctionnerait-elle comme n'importe quelle page utilisateur ou mediawiki ?

Est-elle éditable par les non-sysops ?

Si oui et oui, alors c'est à partir de Projet:JavaScript/Développement qu'on pourrait travailler tranquillement (il faudrait quand même semi-protéger ces pages .js, on ne sait jamais...).

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 12:13 (CET)

Apparemment, oui et oui.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 12:19 (CET)

Heu... Il faudrait que je comprenne comment utiliser Utilisateur:Dr Brains/GlobalManager.js en mettant dans la peau d'un contributeur appelé à tester. C'est certainement faisable, mais je privilégierais pour ma part le fait de dire « pour tester notre nouvelle version de la fonctionnalité « X » : allez dans vos préférences ; si c'est un gadget et que vous l'avez déjà, décochez « X » (si besoin). Puis cochez simplement « X » dans la section « Scripts en développement ». » Le Utilisateur:Dr Brains/GlobalManager.js me semble un peu complexe pour le contributeur, même si c'est un dispositif assez habile.

Sinon, oui, il y a de tout et n'importe quoi dans les gadgets, et la maintenance de ceux-ci est un redoutable défi. Qu'on ne peut relever AMHA qu'en disposant déjà de cet outil de dev. D'autre part, ce serait bien qu'un gadget en véritable dev le soit avec ce filtre « sysop » pour l'acceptation (a propos, Od1n, tu t'y mets quand à la candidature sur le mode admin technique ?). Mais sinon, on peut aisément permettre l'utilisation par tous de ce système via une inclusion (ou un obtenir, etc.) Cordialement, --Lgd (d) 4 décembre 2010 à 12:36 (CET)

Oui, en fait, je conçois que la documentation puisse être obscure.

En fait, l'idée est d'avoir un gadget Mediawiki:Gadget-DeveloppementJavaScript.js qui intègre un version alternative de mon "GlobalManager" (cochable pourquoi pas dans les gadgets).

Ensuite, sur la page Projet:JavaScript/Développement/ListeDesScripts.js (modifiable par tous ou semi-protégée), on ajoute les fonctions soumises au développement commun.

• Celui qui aura coché la case "Participer au développement" dans les gadgets, aura au sommet de son monobook (ou son vector) une autre série de cases à cocher pour les scripts proposés au développement. A lui de choisir celui qu'il veut ajouter/enlever pour tester et/ou proposer des changements.
• Celui qui veut proposer un script à développer conjointement pourra l'ajouter dans Projet:JavaScript/Développement/ListeDesScripts.js (documentation à prévoir), et tous ceux qui utilisent le gadget pourront sélectionner ce nouveau script dans leur .js. Si ce script est créé correctement dans une sous-page de Projet:JavaScript/Développement, n'importe qui (passant la semi-protection) pourra y intervenir.

Ca paraît compliqué mais en fait à l'usage ce serait très simple. C'est juste une histoire de cases à cocher ou pas.

Le risque, par contre, c'est qu'un petit malin "autoconfirmed" vienne délibérément altérer les scripts possiblement liés sur des monobooks d'utilisateurs (potentiellement sysops par ailleurs).

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 12:53 (CET)

Il faut que je teste avant d'avoir vraiment un avis. Mais dans l'idée de réunir des panels de contributeurs pour recetter des fonctionnalités (côté ergo ou compatibilité skin, navigateur, etc.), il me semble vraiment préférable de s'en tenir à des explications de choses à faire dans ce qui est le plus familier (ou le moins étrange) : leurs préférences (lien présent par défaut dans l'interface). Plutôt que de leur dire d'aller sur leur monobook/vector/.js. Par ailleurs, sans AJAX (je ne sais pas si j'ai bien suivi ?), c'est mort ou pas ? Cordialement, --Lgd (d) 4 décembre 2010 à 13:11 (CET)

Oui, m'enfin on parle là de gens qui sont familiers avec les gadgets même si ils n'en comprennent pas le fonctionnement interne. Je ne pense pas que les diriger vers leur page monobook soit au dessus de leur compréhension (surtout que le gadget ajoute un lien vers cette même page dans les liens personnels). Ensuite, ce ne sont que des cases à cocher.

Sans Ajax, oui, c'est mort. La mise à jour automatique du monobook ne se fera pas. Mais pourquoi Ajax ne marcherait pas ? j'ai testé avec 5 navigateurs différents et je n'ai jamais eu aucun soucis.

Le gros avantage de ce que je propose, c'est qu'on évite d'encombrer les préférences avec un tas de gadgets pas au point dont la grande majorité des utilisateurs se contrefout.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 13:19 (CET)

J'ai du mal avec un outil de test js qui est conditionné par le support d'une couche technique (ici, AJAX) quand on aura besoin de tester les fonctionnalités sans. Et je ne suis pas si sûr que les contributeurs éventuellement intéressés par du test utilisateur soient aussi systématiquement avertis que cela (voir le test du gadget accessibilité, fait via un gadget, et qui a du coup attiré des retours de simples contributeurs du projet Hockey notamment, extrêmement utiles : je doute qu'ils soient allés le cas échéant jusqu'à éditer une obscure page vector.js ou monobook.js pour participer). Pour ce qui est d'encombrer les préférences, c'est évidemment une section de plus, mais avec le grand mérite d'être clairement identifiée en tant que « pas toucher si pas intéressé ».

Mais à ce stade, la question reste ouverte : d'autres avis seront nécessaires pour décider dans un sens ou un autre. L'essentiel est déjà qu'elle doit posée et reconnue. Cordialement, --Lgd (d) 4 décembre 2010 à 13:39 (CET)

Tout à fait, la discussion reste ouverte.

Cela dit, j'ai oublié de rappeler l'autre intérêt de ma solution : les scripts sont modifiables par des non-sysops, et ils sont nombreux à pouvoir tirer avantage de ce changement : Odin, Arkanosis, Chrphe, etc... Ils pourraient participer activement au lieu de toujours quémander les changements aux quelques sysops qualifiés pour le faire.

Du coup, peut-être que le mieux serait de coupler nos deux points de vue :

1. Pour les scripts en développement : mon système hébergé sur le Projet:JavaScript, scripts modifiables par tous, sélection par cases à cocher dans la page perso .js
2. Pour les scripts à tester par le tout-venant : section idoine dans les gadgets (donc copie du script en page Mediawiki:), comme tu le souhaites.

Qu'en penses-tu ?

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 14:01 (CET)

Je suis toujours partisan du meilleur des deux mondes, quels que soient ceux-ci . J'ai vu que tu mettais ça en place sans attendre : je testerai. Cordialement, --Lgd (d) 4 décembre 2010 à 15:16 (CET)

Oui, c'est toujours mieux de juger sur du concret. Si ça ne plaît pas, tant pis, y aura qu'à effacer.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 15:21 (CET)

Voilà, à priori, c'est prêt.Il suffit donc d'ajouter au monobook (ou autre) obtenir('DeveloppementJavaScript'); (étape facultative si on met le script en gadget), puis de recharger le cache.

Les scripts, tels que définis dans Projet:JavaScript/Développement/ListeDesScripts.js devraient apparaître en haut de la page.

Après : cocher, décocher, valider, bref, amusez-vous.

La page se met à jour toute seule avec une copie du script demandé (plus simple pour les développeurs d'intervenir sur une copie que sur un script "partagé" via document.write()).

Apportez des modifs, bidouillez, testez. Lorsque c'est OK, mettez à jour le script partagé.

Et voilà !

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 15:38 (CET)

L'idée me semble pas mal, il n'y a plus qu'à essayer ça. Une remarque en passant, la police de caractères est un peu grosse, tu ne trouves pas ? od†n ^{[dead words]} 4 décembre 2010 à 17:34 (CET)

Chez moi non, mais tu dois sans doute être sur Vector. Tu peux ajuster les styles CSS si tu veux :

• Le <fieldset> : id="DeveloppementJavaScript_Fieldset"
• Le lien pour afficher/masquer : id="DeveloppementJavaScript_ToggleLink"
• Le <div> qui englobe la liste : id="DeveloppementJavaScript_ScriptList"
• Le <form> qui englobe lui aussi la liste : id="DeveloppementJavaScript_Form"
• Le <div> de "contrôle" : id="DeveloppementJavaScript_Running"

Tu dois pouvoir arranger la taille des polices avec tout ça.

⇨ D^r Brains ^{∞ Doléances ∞} 4 décembre 2010 à 18:05 (CET)

1 000^e portail ?

Salut Doc !

Dis-donc, vu que tu t'occupes souvent des mises à jour de la liste des portails, je me disais que t'étais probablement le plus à même de retrouver quel était le 1 000^e portail ? Ce serait pas mal de rajouter ça dans l'historique...

Cordialement, — Ċ ң т╒ η (♪ Jasons ! ♫) 5 décembre 2010 à 19:27 (CET)

Certainement.

Le 16 novembre, il y avait 1000 portails (en comptant le Portail:Accueil).

Donc

• si tu comptes le Portail:Accueil, le 1000^e est le plus récent de ces trois portails :
  • Brabant wallon, 16 novembre 2010 à 10:30
  • Territoires du Nord-Ouest 20 octobre 2009 à 02:46
  • Yukon 20 octobre 2009 à 02:44
• si tu ne le comptes pas (ce qui est le plus logique), c'est le plus ancien de ces trois portails (Ceuta et Taza-Al Hoceima-Taounate ayant été supprimés) :
  • Berlin, 26 novembre 2010 à 14:16
  • Franco-Américains 17 novembre 2010 à 20:36
  • Hainaut 26 novembre 2010 à 09:02

⇨ D^r Brains ^{∞ Doléances ∞} 5 décembre 2010 à 19:43 (CET)

EDIT : j'ai rajouté les dates. Donc c'est soit Brabant wallon, soit Franco-Américains selon le mode de calcul.

⇨ D^r Brains ^{∞ Doléances ∞} 5 décembre 2010 à 19:48 (CET)

EDIT bis : ben non, chui con...

C'est soit Territoires du Nord-Ouest soit Franco-Américains

Tant pis pour les belges...

⇨ D^r Brains ^{∞ Doléances ∞} 5 décembre 2010 à 19:51 (CET)

RE-Edit ter...

Heu, non, y a un problème. Territoires du Nord-Ouest date de 2009.

Y'a une couille quelque part.

On va dire que c'est Franco-Américains et puis voilà !

⇨ D^r Brains ^{∞ Doléances ∞} 5 décembre 2010 à 19:53 (CET)

Ah, ça y'est j'ai compris l'embrouille.

En fait Territoires du Nord-Ouest était une redirection jusqu'au 12 novembre 2010 à 00:42

Idem pour Yukon jusqu'au 14 novembre 2010 à 21:48

Donc...

C'est bien ce que j'avais dit au début : soit Brabant wallon, soit Franco-Américains selon le mode de calcul.

⇨ D^r Brains ^{∞ Doléances ∞} 5 décembre 2010 à 19:57 (CET)

Nickel, merci beaucoup pour la réflexion intense, j'ai mis à jour l'historique. À plus ! — Ċ ң т╒ η (♪ Jasons ! ♫) 5 décembre 2010 à 21:13 (CET)

Wikimag - Semaine 48

Wikipédia:Wikimag/2010/48 CaBot 6 décembre 2010 à 01:10 (CET)

Wladyslaw Sławny

Merci beaucoup de m'avoir aidé.

FS (d) 6 décembre 2010 à 11:33 (CET)

De rien.

A présent que la notoriété (et donc l'admissibilité) de ce monsieur est établie et que l'article est convenablement présenté, il faudrait trouver des sources pour corroborer les différents éléments (voir Aide:Notes pour la syntaxe).

Une photo libre serait également bienvenue pour illustrer l'article.

⇨ D^r Brains ^{∞ Doléances ∞} 6 décembre 2010 à 12:23 (CET)

J'apprécie ton aide

Particulièrement sur le portail. Pour les Catégories, je ne peux que te conseiller de lever le pied. Les dénominations peuvent changer mais l'Algèbre Nouvelle ne peut pas être détachée de Viète : elle en dépend (c'est son œuvre) et le dépasse (elle ne se comprend pas sans ses successeurs)

Je ne comprends pas l'intérêt d'avoir une sur Catégorie et deux sous Catégories ? Pourquoi pas trois ? Car je te répète, selon moi, Viète et l'Algèbre nouvelle sont inséparables... A la limite sous cette forme :

"Mathématicien français"         "Histoire des mathématiques"   "Algèbre"  
            |                           |        |                /
Protestant  |  "Mathématicien du XVIe siècle"    |               /  
      |     |     |                              |              /
      |     V     V                              |             /
      ---------  VIÈTE ET L'ALGÈBRE NOUVELLE --------- ------------------       
          |        |                             |                   |   
          /        V                             |                   |   
         /                                       |                   |  
        "François Viète"    <--------->  "Algèbre nouvelle"      "spécialiste de François Viète et de l'algèbre nouvelle" (cat isolée) 
       /                                         |                      (Biographe, collectionneurs, défenseurs, illustrateurs, héritiers)
     /                                           |                                         
    |-> "Protecteur de François Viète"           |---> "Prédécesseur de l'algèbre nouvelle"  
    |-> "Élève, Secrétaire de François Viète"    |---> "Éditeur,Imprimeur,Traducteur de l'algèbre nouvelle" 
    |-> "Locus Vietae"( humour Vietéen )                                                                                       

                                                                                          

Car sans ces doubles dénominations ça ne tiendra pas : on ne peut pas constituer une catégorie pour 3 secrétaires ou 3 imprimeurs, 2 à 5 traducteurs, etc... et je ne crois pas qu'on en trouve jamais d'autres... Ou dans cent ans...

Comment compter ceux qui sont à la fois biographes et spécialistes ? Ceux qui sont élèves et éditeurs (cf Ghetaldi, Aleaume) ?... Autre exemple, Chasles n'est pas vraiment un biographe, mais il compte pour "ranimer" l'homme (par l'importance qu'il donne à l'œuvre), idem Fourier, Ocagne, Marie, ou Bertrand ils sont à la fois un peu biographes et un peu spécialistes... Il faut vraiment lire tous les articles pour se pénétrer de la complexité du classement... De Salins est un collectionneur, Idem Feuillet de Conches, où les ranger ? Biographes ? Héritiers. Faire encore une autre catégorie ? Surtout : ne pas les éliminer, car ils comptent dans la fabrication de l'image de Viète. Et Fillon aussi, il n'est vraiment ni Biographe, ni spécialiste... Ritter est les deux, le seul à connaître Viète et ses œuvres à fond, le traduire en entier (hors harmonicon), et tracer une tentative de monographie qui tient la route (jusqu'à Grisard).

En fait, pour de tels sujets, je crois que la volonté de Wp de catégoriser par l'élément et non par l'ensemble (et donc de bannir le pluriel) est une pure hérésie en soi. Ainsi, les lieux de Viète n'ont-ils aucun sens pour Wp... mais il ne peut non plus exister de "lieu de Viète"... car intrinsèquement cela n'a pas de sens... pour un mort qui bougeait beaucoup. Du coup les relations qu'entretiennent ces lieux sombreront dans l'anonymat du portail... Cela ne facilitera pas la transversalité (pour aller de Foussay-Paré à Fontenay ou le Busseau, passer par la case Paris !...) Mais ça, c'est pas le plus grave. Le plus amusant est la demande des consignes de non ambiguïté, qui finit par produire de faux classements si on n'y prend pas garde... ou exclure toute possibilité de classement... (ce que je redoutais voici un an lors de la création de la première page de lien proposé à une PaS, en décembre 2009).

Ainsi, d'après moi, le choix est simple : - Ou ne rien faire (et je ne vois pas que ça porte un gros préjudice au portail, ni à sa crédibilité, ni à celle de Wp) - Ou faire au mieux de tes convictions et de ton temps libre... (mais ce sera forcément très imparfait, voire destructeur - en toute courtoisie et sans mésestimer ton intelligence) ; car tu ne feras entrer sous les fourches caudines des consignes, et tenter de réparer l'irréparable outrage)... sans te retrouver avec des catégories quasiment vides, que le premier bureaucrate (je ne mets pas tous les admins dans le même sac) venu aura tôt fait de supprimer. Tu comprends que je ne pourrais pas donner mon accord. - Ou de t'y intéresser à fond (lire toutes les références, toutes les notes, tous les articles... et prendre en charge tout ça, en essayant de conjuguer le portail, les catégories et la logique Wp)... On en reparle dans un mois ou dans un an... et je crois que d'ici ce moment là, un troisième larron sera déjà venu avec son code de la loi... trancher dans le vif... ad libitum.

En attendant, je pars, je vous/te laisse vous/te débrouiller... parce que ça n'est pas ma logique d'inclusion. Et tant pis si vous/tu trouves que je suis une tête de cochon, mais je ne vois pas comment faire autrement et entrer dans la logique proposée. D'où le sabordage absolu, et finalement justifié -je crois- , de ma page et ma pdd... car je ne me fais aucune illusion. J'en suis persuadé : à terme que le point de vue de 'Wp' triomphera... avant que ne triomphe un point de vue plus inclusif. Cordialement mais sans espoir. Jean ^{[de Parthenay]} 6 décembre 2010 à 15:53 (CET)

Mmh, en fait je crois avoir compris ton erreur d'interprétation.

En fait, tu voudrais regrouper François Viète et l'Algèbre nouvelle dans une même catégorie parce que "c'est indissociable". En gros, pour avoir "une vue d'ensemble", si je comprends bien.

Sauf que ça c'est la fonction du portail, pas des catégories. Les catégories sont là pour regrouper les articles de même nature. Or, là, avec la catégorie Algèbre Nouvelle et François Viète, on a deux choses différentes : d'un côté une personne, de l'autre une branche des mathématiques. Même si l'une est le fruit de l'autre, ce n'est pas la même chose et cela n'a pas de sens de les regrouper dans la même catégorie, étant donné l'usage qui est fait dans WP des catégories.

Pour te donner un exemple, ce serait équivalent à une catégorie "Albert Einstein et la théorie de la relativité". Or, si tu va voir les catégories associées à ces deux notions (Albert Einstein et Relativité), tu verras qu'elles ne sont pas sur le même plan de l'arborescence, même si évidemment il y a des recoupements au niveau des articles (bon en fait mon exemple est pas super car la catégorisation de ce "secteur" laisse un peu à désirer et pourrait être amélioré, mais bon, j'espère que tu as compris le principe de ce que j'essaye d'expliquer).

Concernant les difficultés que tu évoques, je te rappelle qu'un article peut avoir plusieurs catégories, donc se retrouver à la fois "Biographe de François Viète" et "Spécialiste de l'algèbre nouvelle" (ou pas)

Le nombre d'articles dans chaque catégorie n'est pas un obstacle. Même si il est recommandé qu'il y en ait un minimum, ce n'est qu'une recommandation. Donc à moins de vraiment trop abuser et de faire une catégorie que pour un seul article, on peut y déroger.

Quant aux lieux, si Viète est important dans leur notoriété, ils peuvent être catégorisés directement dans "François Viète", mais je doute vraiment de la pertinence d'une catégorie spécifique.

Pour finir, c'est dommage que tu le prennes ainsi. Personnellement, je n'ai pas vocation à devenir spécialiste du sujet. Ça c'est ton rôle. Moi je n'apporte que ma connaissance des usages de Wikipédia. Et c'est par la discussion qu'on arrivera à concilier les deux impératifs. Si tu refuses de discuter sur cette réorganisation nécessaire, je ne ferai rien du tout, et un beau jour (demain, dans un mois, un an), quelqu'un tombera sur cette arborescence qui ne respecte pas les conventions et fera le ménage à grands coups de hache.

Puisque le problème a été soulevé, réfléchissons-y ensemble et tâchons de sortir par le haut de ce malheureux quiproquo.

⇨ D^r Brains ^{∞ Doléances ∞} 6 décembre 2010 à 16:32 (CET)

Jean

Bonjour Dr Brains. Bravo! J'interviens dans votre PdD pour vous dire que quelque part vous avez réussi à argumenter comme il se doit avec Jean. Voir le message de Jean. C'est son droit exclusif ou inclusif de prendre un court wikibreak dont la durée dépend de lui. Amicalement, GLec (d) 6 décembre 2010 à 22:52 (CET)

Bravo et merci. Tu viens de te coltiner un boulot monstre : négociation et rangement. J'aurais voulu aider davantage mais je me suis un peu perdue dans les discussions sur l'arborescence mère fille, catégorie, portail, modèle... Le temps que je me retourne, tu avais fait ensuite presque tout le travail de petite main sur l'attribution de toutes les catégories (le reste prend un peu de temps  : réflechir.... choisir... et il y aura probablement des questions à poser à Jean de Partenay). Méfie-toi : maintenant tu es fiché : si j'ai besoin d'aide pour des catégories, je sais à qui j'irai m'adresser. Merci pour tout. HB (d) 7 décembre 2010 à 12:30 (CET)

Bravo et merci. Tu viens de te coltiner un boulot monstre... Je joins mes félicitations à celles de HB. Le résultat est étonnant. Bien que je trouve un peu triste que les "lieux" et les personnalités" liées à Viète ne puissent réellement figurer en tant que tels, je dois avouer que mes préventions étaient timorées. Utilisateur:Jean de Parthenay (d) 8 décembre 2010 à 18:43 (CET)

Aide:Syntaxe

Bonjour/soir

Je cherche quelqu'un de plus compétent que moi en html pour traiter de manière sûre une petite difficulté dans Aide:Syntaxe. Si tu as un peu de temps pour ça, le problème est exposé ici.

Bon courage dans tous les cas . TigHervé 8 décembre 2010 à 19:03 (CET)

addcache()

Salut, vu que la fonction addcache() remaniée semble prête, si tu te sens d'attaque, que dirais-tu de mettre celle-ci en place ? J'ai posté le code avec nos dernières modifs ici. Comme ça je pourrai embrayer tranquillement sur setModifySectionStyle(), vu que je suis arrivé à quelques résultats intéressants. od†n ^{[dead words]} 8 décembre 2010 à 21:03 (CET)
PS : J'ai survolé cette histoire d'algèbre nouvelle, joli boulot

Ce coup-ci, j'ai vérifié et il ne semble pas y avoir de bug.

setModifySectionStyle() est, je crois, une fonction assez lourde par rapport à l'utilité réelle. L'optimiser est très indiqué.

Qu'on ne me parle plus d'algèbre nouvelle, je vais devenir allergique à force ! ;)

⇨ D^r Brains ^{∞ Doléances ∞} 8 décembre 2010 à 21:14 (CET)

J'ai vu que tu étais dessus, merci ! Mais n'oublie pas le Common.css od†n ^{[dead words]} 8 décembre 2010 à 21:15 (CET)

Rah, il faut l'ajouter ou remplacer l'existant ? Si c'est la deuxième solution, je n'ai pas trouvé.

C'est un vrai foutoir ce Mediawiki:Common.css. Un de ces quatre, il va falloir que je me décide à tout ranger proprement.

⇨ D^r Brains ^{∞ Doléances ∞} 8 décembre 2010 à 21:26 (CET)

Il n'y a pas d'existant, c'est à ajouter Pour être honnête, je ne sais pas trop où il faut placer ça. J'ai trouvé une section « /* COULEUR DES LIENS */ ». Ou peut-être mieux, juste en dessous il y a une section « /** NOTES, RÉFÉRENCES, BIBLIOGRAPHIE **/ ». od†n ^{[dead words]} 8 décembre 2010 à 21:32 (CET)

Mouais. Bon, je vais l'ajouter dans la section « /** NOTES, RÉFÉRENCES, BIBLIOGRAPHIE **/ » et je m'attaque direct à une réorganisation totale (dans une sous-page personnelle pour commencer). Parce que à ce niveau-là de foutoir, c'est pas tenable...

⇨ D^r Brains ^{∞ Doléances ∞} 8 décembre 2010 à 21:38 (CET)

Faudrait en toucher un mot à mon parrain Arkanosis (d · c), mais bon il est un peu occupé en ce moment. Il peut repérer l'utilisation d'une class donnée sur le wiki. En effet, ça ne me suprendrait pas que le Commons.css contienne du dead code. od†n ^{[dead words]} 8 décembre 2010 à 21:42 (CET)

Wiki D&D (encore)

• Pourquoi est-ce que dans la palette géographie, [Bérégost] apparaît dans Région (alors que c'est une ville) ?
• Pour les images, est-ce qu'on peut les emprunter (à partir d'autres sites, livres, ou cartes) ou est-ce qu'il faut les recréer systématiquement? (comme tu as fait pour les cartes)
• Est-ce que tu sais qu'en fait on n'est pas du tout à jour par rapport à la 4ème Edition? Moi je le savais pas... o_O Mais Mystra est morte, Lathandre était en fait Amaunator et il a repris son nom, Abeir a "fusionné" avec Toril, Maztica a été remplacée par Abeir Resurgi (c'était bien la peine de créer un continent pour le faire disparaître...), la Plan de l'Ombre a été remodelé par Shar et s'appelle maintenant la Gisombre, le port de Luskan est à l'abandon, la Tour des Arcanes est en ruines et hantée par des morts vivants et la ville n'a plus de gouvernement, le Zhentarim n'existe plus, Halruaa est tombée et il ne reste plus qu'une terre stérile et cinq compagnies de navires volants qui sillonnent le ciel, etc, etc. Alors qu’est-ce qu’on fait ? On n’en tient pas compte et on reste sur l’ancienne édition ou est-ce qu’on précise l’évolution avant/après la Magepeste (pour Luskan par exemple puisque c’est flagrant)? C'est pénible ces bouleversements entre deux éditions, en plus l'année en cours maintenant c'est 1479 CV, donc il nous manque 101 ans dans la chronologie, et j'arrive pas à les trouver sur internet ces cents ans...

Lamelugubre (d) 9 décembre 2010 à 15:10 (CET)

• Bérégost : corrigé.
• Pour les images, on peut les emprunter à d'autres sites, mais il faut indiquer clairement où on l'a prise (avec un lien) et spécifier que de toutes manières, les RO appartiennet à WotC et qu'on ne peut pas les utiliser commercialement. Le modèle Information est fait pour ça.

  Cela dit, tu ne peux pas importer des images. Il faut être bureaucrate. Donc ce que tu fais, c'est que tu ajoute le nom de l'image ici. Tu dois définir le nom tel qu'il sera dans wiki-donjons-et-dragons, peu importe si c'est pas le même que l'image d'origine. Par contre, il faut impérativement garder la même extension (.gif, .jpg, .png, etc...) et mettre le préfixe Fichier:. Donc, tu ajoute le fichier dans la liste, tu crée la page de description avec l'adresse où je peux trouver l'image et les autres infos qui vont bien, et je me chargerai du téléchargement.

• je sais oui, mais en fait je connais très peu la 4ème édition. Cela dit, ça ne change pas tout non plus. Même si le Zhentarim n'existe plus, on peut quand même avoir un article dessus (il faudra juste le mettre à jour pour indiquer que ça n'existe plus et pourquoi). Te bile pas pour la chronologie, ce qu'il y a déjà est encore très incomplet. J'imagine que dans le livre de campagne, il y a la chronologie post-4^e édition. Bref, pour l'instant, le mieux est de s'en tenir aux infos qu'on a, c'est à dire les 2e et 3e édition, et on mettra à jour plus tard. Il y a encore un boulot monstre même sans compter cette mise à jour...

⇨ D^r Brains ^{∞ Doléances ∞} 9 décembre 2010 à 16:10 (CET)

Hello!

Merci pour tes réponses!

J'ai essayé d'entrer des fichiers dans le projet images à importer (là) je ne sais pas si j'ai vraiment fait ce qu'il fallait faire et si on peut utiliser ces images. Si ce n'est pas le cas, dis-le moi ou dis-moi ce qu'il manque ou ce que j'ai mal fait. C'est juste des essais pour comprendre la procédure, je m'y mettrai sérieusement (avec les symboles des dieux et les cartes des villes) quand mes partiels seront terminés.

Merci d'avance! Lamelugubre (d) 14 décembre 2010 à 22:57 (CET)

Images importées.

Pour Drizzt, je n'ai pas pris l'image que tu indiquais car elle avait le copyright sur le bord et je ne voulais pas la couper. Alors j'en ai choisi une autre, tirée des comics.

⇨ D^r Brains ^{∞ Doléances ∞} 15 décembre 2010 à 00:59 (CET)

Super, les articles sont tout de suite beaucoup plus parlants avec une image!

J'ai ajouté d'autres fichiers à la liste des images à importer, si tu n'as pas le temps de les importer, change mon statut et j'essayerai de le faire comme une grande! ^_^

See ya! Lamelugubre (d) 16 décembre 2010 à 21:19 (CET)

Guillemets du modèle : Autres projets

NEMOI, à 13 heures 53, le 10 décembre 2010. − Salutations. Il y a plein de cas où les guillemets ne me semblent pas nécessaires, pour ne pas dire superflus voire aberrants (comme sur Paul de Levoča, que je poste bientôt). Ta modification a-t-elle été discutée quelque part ?

Bonjour, oui et non.

Ma modif fait suite à une rapide discussion sur le le bistro du 3 décembre, et suite à ça une discussion a commencé sur ma pdd entre Od1n (d · c · b), Lgd (d · c · b) et moi. On est à peu près tous d'accord pour dire que le titre de la page doit être mieux différencié que le ", sur Wikimachin", mais on ne sais pas trop encore comment. Le problème est d'ailleurs compliqué par le fait qu'il y a la couche JavaScript qui ajoute les liens dans la colonne de gauche et dont il faut tenir compte.

Donc, pour l'instant, les guillemets (et la virgule) sont une solution temporaire, amenée à être remplacée par quelque chose de mieux qu'il faut déterminer.

Si le sujet t'intéresse, je te suggère de commencer une discussion sur la pdd du modèle.

⇨ D^r Brains ^{∞ Doléances ∞} 10 décembre 2010 à 14:03 (CET)

NEMOI, à 15 heures 04, le 10 décembre 2010. − Lancé ici.

setModifySectionStyle()

Salut, j'ai un peu travaillé sur cette fonction. Les gains de perfs ne sont malheureusement pas fulgurants, mais il y a quelques amélioration ci et là. Ça se trouve ici. Tu me diras ce que tu en penses od†n ^{[dead words]} 10 décembre 2010 à 19:47 (CET)

Vu que le principal but du .js est de faire passer le "editsection" après le "mw-headline" dans le DOM, pourquoi ne pas mettre tous les styles nécessaires par CSS

• .editsection { font-size: x-small; font-weight: normal; float: none; } (le font-weight est je crois nécessaire pour contrer les attributs des Hx. pour le H2 c'est inutile mais les H3 sont en bold, par exemple)
• .mw-headline { margin-right:0.25em; }

Par contre ça suppose d'étendre le .js aux H1, présents par exemple dans les sous-pages du bistro, du BA, etc...

Et il faut voir le rendu dans le cas où le .js est désactivé.

⇨ D^r Brains ^{∞ Doléances ∞} 10 décembre 2010 à 20:08 (CET)

• Pour le font-weight, je viens de revérifier, avec ce qu'il y a dans le main.css les .references sont bien à chaque fois en font-weight:normal
• C'est bien là le souci : il faut appliquer les styles si et seulement si le JS est activé

od†n ^{[dead words]} 10 décembre 2010 à 20:22 (CET)

• C'est pas les références dont il est question mais les H1-6. Cela dit, après vérif, c'est bon quand même. Les H3-6 sont en bold mais les editsection correspondants sont en normal.
• Dans ce cas, pourquoi ne pas se contenter d'ajouter une classe particulière aux H1-6 ? Le css des deux span intérieurs serait dépendant de l'ajout ou non de cette classe par javascript.

⇨ D^r Brains ^{∞ Doléances ∞} 10 décembre 2010 à 20:27 (CET)

Cela consisterait donc à définir de nouveaux styles dans le common.css, et dans le script à passer de 3 setters de style à un addClass() sur le <hX>. J'avais du penser à quelque chose de similaire au début, avant de faire le système avec margin-right, je pense que j'ai du ensuite oublier l'idée J'essaierai et je verrai ce que ça donne  – od†n ^{[dead words]} 10 décembre 2010 à 20:34 (CET)

Tout à fait. En plus du déplacement du span .editsection, l'ajout d'une classe "ModifiedSectionTitle". Avec les classes correspondantes dans le commons.css :

• .ModifiedSectionTitle .editsection { font-size: x-small; float: none; }
• .ModifiedSectionTitle .mw-headline { margin-right:0.25em; }

Faut voir ce que ça donne en terme de performances.

⇨ D^r Brains ^{∞ Doléances ∞} 10 décembre 2010 à 20:37 (CET)

Cette fonction est assez délicate à benchmarker, vu qu'elle modifie son propre environnement, mais en l'occurence le gain de perfs a été flagrant, y'a pas à chercher plus loin, ta modification vaut vraiment le coup.

Autre chose, je vois bien trop souvent des « class=" maClasse" », il faudrait modifier addClass(), pour quelque chose dans ce genre :

function addClass(node, className) {
    if (hasClass(node, className)) {
        return false;
    }
    var cache = node.className;
    if (cache) {
        node.className = cache + ' ' + className;
    } else {
        node.className = className;
    }
    return true;
}

– od†n ^{[dead words]} 11 décembre 2010 à 02:00 (CET)

Fait pour addClass() (a priori pas de bug possible). Y a plus qu'à améliorer removeClass() pour peut-être se passer de RegExp et on aura fait le tour de la manipulation de classes.

Pour les liens [modifier], y a plus qu'à mettre d'ors et déjà en place les classes CSS qui vont bien. On implémentera le javascript lorsqu'il sera prêt.

Je m'occuperai de ça demain (enfin, tout à l'heure), à tête reposée.

⇨ D^r Brains ^{∞ Doléances ∞} 11 décembre 2010 à 02:15 (CET)

Pour le addClass() je venais justement de finir ceci :

Code tout léger

function addClass(node, className) {
    var cache = node.className;
    if (!cache) {
        node.className = className;
        return true;
    }
    if (cache === className) {
        return false;
    }
    var pos = cache.indexOf(className);
    if (pos === 0
            && cache.substr(className.length, 1) === " "
        || pos > 0
            && cache.substr(pos - 1, 1) === " "
            && (pos + className.length === cache.length
                || cache.substr(pos + className.length, 1) === " ")) {
        return false;
    }
    node.className = cache + ' ' + className;
    return true;
}

 

En fait ce qu'il faudrait, c'est une version de hasClass() acceptant 2 strings en entrée.

Pour ce qui est du javascript de setModifySectionStyle(), je pense qu'on a fait le tour de la question. J'ai mis le code modifié sur ma page. Évidemment n'hésite pas à apporter toute modification que tu souhaiterais.

od†n ^{[dead words]} 11 décembre 2010 à 02:31 (CET)

Je vois pas bien l'intérêt de ce nouveau code pour addClass(). Si je comprends bien, tu veux éviter le recours à hasClass() et en recopiant le code. Est-ce que ça en vaut vraiment la peine ?

⇨ D^r Brains ^{∞ Doléances ∞} 11 décembre 2010 à 13:37 (CET)

Ne t'en fais pas, c'était surtout une expérience pour m'amuser. Un exemple d'inlining quelque peu trop poussé. L'idée n'était pas de faire un appel de fonction en moins (ça on s'en moque) mais plutôt de faire un accès .className en moins. od†n ^{[dead words]} 11 décembre 2010 à 14:27 (CET)

setModifySectionStyle() mis à jour. a priori aucun bug.

J'ai appliqué la modif également aux h1 (ceux qui contiennent un .editsection), pour les pages organisées en sous-pages et qui utilisent ce genre de titre de section.

⇨ D^r Brains ^{∞ Doléances ∞} 11 décembre 2010 à 13:54 (CET)

Tu as bien fait pour les <h1>, ils n'avaient pas de raison particulière d'être exclus. od†n ^{[dead words]} 11 décembre 2010 à 14:27 (CET)

J'ai un peu réfléchi à cette histoire avec hasClass(), on pourrait y ajouter quelque chose dans ce genre, un overload pour ainsi dire :

if (typeof node === "string") {
    haystack = node;
} else {
    haystack = node.className;
}

Attention, je ne dis pas que c'est forcément à faire, c'est juste une idée comme ça. L'intérêt serait pour les fonctions faisant usage de hasClass(), on pourrait lui passer directement la valeur de className, dans le cas où celui-ci aurait déjà été rapatrié en amont. À la louche, cela fait tourner hasClass() 10 % moins vite (mais comme cette fonction a été grandement accélérée il y a peu de temps, elle reste particulièrement rapide), mais pour les fonctions faisant usage de hasClass(), cela permet de rendre l'appel 25 % plus rapide (sous réserve que le className ait déjà été rapatrié, et que la fonction soit modifiée pour effectuer l'appel à hasClass() directement avec la valeur de className). L'informatique est histoire de compromis, là on perd un peu d'un côté, mais on peut gagner un peu plus d'un autre (cf. le profiling qui est posté sur ma page). De toute façon, le plus gros des améliorations de perfs a été fait On est là dans le coupage de cheveux en quatre, et cela implique la modification de la signature de hasClass(), ce qui à mon avis est à ne pas pas négliger. Considère cela comme une réflexion purement académique. J'aimerais simplement savoir si tu as un avis là dessus. Sinon rassure-toi, j'ai des projets plus importants en tête, je prévois notamment de retaper le gadget HistoryDeluxe. Bien à toi, od†n ^{[dead words]} 12 décembre 2010 à 01:57 (CET)

Mouais, c'est vraiment du coupage de cheveux en quatre à ce niveau-là . Je ne voudrais pas dire de conneries, mais je pense que dans l'immense majorité des utilisation de hasClass(), la classe n'a pas été rapatrié en amont. Aussi je crois que ce serait globalement une régression au niveau des perfs.

Avant de te lancer dans l'optimisation du gadget HistoryDeluxe, jette un coup d'oeil sur ma version perso (en imaginant que les requêtes API sont faites en XML et pas en texte, un de ces quatre il faudra que je m'attelle au changement) Fait.

⇨ D^r Brains ^{∞ Doléances ∞} 12 décembre 2010 à 02:26 (CET)

• Pour revenir sur le coupage de cheveux en quatre, on pourrait faire une nouvelle fonction inClassList, qui serait grosso modo une copie de hasClass mais prenant directement la valeur de className en entrée, et qui serait pour ainsi dire destinée à un usage interne. Ainsi il n'y a aucun ralentissement de hasClass, et cette fonction pourrait déjà être utilisée pour addClass, et peut-être pour removeClass (que je n'ai pas encore regardé).
• Pour le gadget DeluxeHistory, ce qui m'intéresse au délà des perfs (qui sont effectivement à améliorer) c'est surtout qu'il y a des bugs à corriger. Et le code actuel de rapatriement sysops/bots est une catastrophe. Effectivement c'est l'API qu'il faut utiliser, d'ailleurs pourquoi ne pas tout simplement utiliser du JSON ? Il faudra aussi que je regarde pour le cache des sysops et bots, si on peut tirer profit des capacités de stockage de HTML5 ça serait une bonne chose (je ne connais pas encore le fonctionnement de ce système), et on garderait l'énorme cookie seulement si le navigateur ne permet que cette solution.

od†n ^{[dead words]} 12 décembre 2010 à 16:21 (CET)

• Une fonction alternative supplémentaire serait effectivement une bonne solution. Il faudrait voir ça en même temps que l'optimasation de removeClass()
• Il me semble (à vérifier) que contrairement au XML le JSON n'est pas pris en charge par tous les navigateurs, notamment les plus vieux. Et il me semble aussi que le gain en termes de performances entre le XML et le JSON n'est pas vraiment significatif (ne serait-ce qu'en regard du temps de réponse de la requête elle-même). Je ne connais pas non plus les nouvelles propriétés du HTML 5 (et/ou la prise en charge de ces méthodes par les différents navigateurs). La seule méthode sûre pour conserver des infos d'une page à l'autre que je connaisse reste le cookie.

⇨ D^r Brains ^{∞ Doléances ∞} 12 décembre 2010 à 16:38 (CET)

Je suis en train de regarder un peu ton script perso, je n'ai pas encore examiné en profondeur, mais n'y aurait-il pas un risque de faux positif, lorsqu'on détermine si un user est bot ou sysop, avec les indexOf sur la valeur du cookie ? Je m'explique : soit AdminToto, qui est sysop, et Toto, qui n'est pas sysop. La recherche pour Toto ne fait-elle pas un match sur AdminToto ? od†n ^{[dead words]} 12 décembre 2010 à 18:12 (CET)

A priori non, étant donné comment est codée la fonction .indexOf pour les variables de type Array dans le Common.js :

code

// Array.indexOf : recherche un élément dans un tableau
 
if(!Array.indexOf){
	Array.prototype.indexOf = function(obj){
		for(var i=0; i<this.length; i++){
			if(this[i]==obj){
				return i;
			}
		}
		return -1;
	}
}

 

C'est la totalité de l'élément qui doit être égal à la valeur recherchée, donc pas de faux-positif possible.

Cela dit, c'est valable pour le codage dans le Common.js ; pour les navigateurs où la fonction est déjà implémentée, il faudrait vérifier que le rendu est le même.

⇨ D^r Brains ^{∞ Doléances ∞} 12 décembre 2010 à 18:24 (CET)

Ah, c'est sur un array, j'aurais du prendre le temps de mieux lire. Tant que nous y sommes, remplace donc cette infamie du Common.js :

for(var i=0; i<this.length; i++){

par ceci :

for (var i = 0, l = this.length; i < l; i++) {

toujours mettre en cache le length od†n ^{[dead words]} 12 décembre 2010 à 18:46 (CET)

Le truc que je ne fais jamais... Encore une bonne habitude à prendre.

A priori, la plupart des fonctions de Common.js font comme ça. Je mettrai à jour en même temps que le reste.

⇨ D^r Brains ^{∞ Doléances ∞} 12 décembre 2010 à 19:03 (CET)

Spécialiste de l'Oman

Je viens de faire Sultan Qaboos Sports Complex, stade situé à Mascate (Oman). Je veux créer la catégorie Stade omani de football. Problème, dans la "catégorie:Oman", il y a deux appellations différentes : omani(e) et omanais(e). Moi, j'emploie le premier, mais le second est présent. Lequel choisir? Car après il faut harmoniser soit dans l'un ou dans l'autre. Déjà, on dit un omani (un habitant de l'Oman) et le rial omanais (monnaie de l'Oman). Que dois-je faire? Dans l'attente de vos réponses, merci d'avance!!FCNantes72 (discuter) 11 décembre 2010 à 11:31 (CET)

Bonjour,

désolé mais je ne suis pas spécialiste de l'Oman. Je me suis contenté de créer le portail (raison pour laquelle, je suppose, tu t'adresses à moi).

Ta question trouverait probablement sa réponse sur l'Oracle ou sur le Bistro.

⇨ D^r Brains ^{∞ Doléances ∞} 11 décembre 2010 à 13:32 (CET)

Wikimag - Semaine 49

Wikipédia:Wikimag/2010/49 CaBot 13 décembre 2010 à 01:10 (CET)

Nouveau modèle pour les portails

Bonjour Dr Brains, j'ai crée ceci ; {{Wikimédia associés 2}} dernièrement, si cela vous intéresse. Amicalement. FrankyLeRoutier % Appelez-moi sur mon CB 13 décembre 2010 à 15:01 (CET)

Vu.

Quelques remarques :

1. Pourquoi le cadre du tableau est à l'extérieur des <includeonly> ?
2. A quoi sert le </div> à la fin, juste avant le </includeonly> ? Un oubli de copier-coller ?
3. Le paramètre implicite {{{1}}} est utilisé plusieurs fois (pour les trois liens commons). Ça peut sans doute poser problème.
4. Il manque :
   • un valign="top" pour aligner les différentes cases
   • un width="100%" sur le tableau et un width="??" sur les cases pour que toutes les cases aient la même largeur (voir sans doute {{Nombre de paramètres définis}} pour obtenir le nombre de cases et donc calculer la largeur qui va bien)

Sinon, il n'existait pas déjà un modèle qui faisait ça ?

⇨ D^r Brains ^{∞ Doléances ∞} 13 décembre 2010 à 15:17 (CET)

Rebonjour Dr Brains, volià j'ai modifié le modèle selon vos remarques et déplacées les icones. Effectivement il y a même deux modèles l'un est verticale et l'autre a des paramètres par défauts ; Spéciale:Recherche si il n'y a pas de lien qui est préciser, impossibilité de choisir un meilleure titre du projet connexe, j'aurais peut-être pu modifié la version horizontale mais il auraient fallu aussi le faire sur la trentaines de portails qui l'utilisent et là je ne suis pas sûr que la nouvelle version leurs plairent, j'ai fais une annonce sur le bistro après la création mais hèlas sans succès. Merci beaucoup pour l'aide technique, amicalement. FrankyLeRoutier % Appelez-moi sur mon CB 14 décembre 2010 à 07:00 (CET)

.className

Bonjour, je m'intéresse (ici) à une fonction du common.js, toolTipPlusMinus(), qui ralentit un peu les listes de suivi. Il y a un accès .className, suivi d'un fallback getAttribute("class"). Pour les pages HTML, le .className est parfaitement cross-browser, j'avais donc envisagé de supprimer le getAttribute("class"). Mais on m'a évoqué la compatibilité avec les documents XML. Comme tu dois être bien plus calé que moi dans le domaine, saurais-tu me dire si le getAttribute("class") peut se révéler nécessaire dans certains cas ? Je pense notamment aux résultats de requêtes ajax, et plus précisément dans les cas où la fonction pourrait être re-appelée par d'autres scripts (comme on a fait auparavant pour d'autres fonctions). Bien à toi, od†n ^{[dead words]} 14 décembre 2010 à 02:26 (CET)

A priori, lors d'une requête Ajax, le .js n'est pas exécuté (d'où justement mon souhait d'adapter le maximum de fonction du Commons pour être réutilisables a posteriori).

Il serait donc bon d'introduire dans cette fonction aussi une variable pour définir la cible (document par défaut). Et à l'intérieur de cette cible, cibler les <ul class="special">, sans doute moins nombreux que les <span>, pourrait peut-être faire gagner du temps (mais il faudra toujours y chercher les <span class="mw-plusminus-???"> donc au final je ne sais pas si ça vaut le coup).

Cela dit, si une fonction doit recueillir des infos sur la liste de suivi via Ajax, il est bien plus simple de le faire via l'API (en XML donc). Mais aucun attribut ne porte le nom de "class" et de toutes manières l'API ne donne pas la différence de taille mais la taille avant et après (requête API avec tous les paramètres possible).

Donc, à priori le .getAttribute("class") est inutile ici.

⇨ D^r Brains ^{∞ Doléances ∞} 14 décembre 2010 à 03:15 (CET)

Merci pour ta réponse. Je suis revenu sur ma décision de supprimer le fallback getAttribute("class") après être tombé sur un fallback similaire dans le code source de jQuery. La différence étant que jQuery répond à des situations très diverses, tandis que là pour Wikipédia nous pouvons cerner un nombre bien plus restreint de cas de figures. C'est pourquoi j'ai souhaité vérifier auprès de toi si je n'avais rien oublié. De toute façon, dans un hypothétique pire des cas, le script serait tout simplement ineffectif dans des situations vraiment très particulières d'inclusion etc. via des gadgets ajax. En somme rien d'extrêmement grave.

Concernant la sélection des éléments, c'est précisément le cœur du problème (c'est en fait le seul point à traiter). Je me suis déjà un peu penché dessus, et les résultats sont évidemment très différents selon les navigateurs, sinon c'est pas drôle. De ce que j'ai trouvé pour l'instant, on pourrait donner un bon coup de fouet à IE (qui en aurait vraiment besoin) en utilisant jQuery. Pour finir, n'oublie pas que les sélecteurs jQuery/Sizzle démarrent de la droite, donc il faut être le plus précis possible à droite^{(présentation intéressante)}. C'est toute une science mais ça tombe bien, j'aime ça od†n ^{[dead words]} 14 décembre 2010 à 03:43 (CET)

HotCats

Bonjour,

J’aurais besoin d’aide pour MediaWiki:Gadget-HotCats.js mais sur la wikisource en breton : s:br:MediaWiki:Gadget-HotCats.js. Actuellement, le gadget ne fonctionne pas, saurais-tu pourquoi ?

Cdlt, Vigneron * ^discut. 15 décembre 2010 à 00:52 (CET)

Ah mais c'est la vielle version.

Elle ne marche pas car il manque des fonctions qui sur Wikipedia fr sont présentes dans le commons (hasClass() est celle dont l'absence provoque l'erreur mais peut-être y en a-t-il d'autres).

Pourquoi ne pas préférer la nouvelle version, HotCatsMulti ?

Non seulement les fonctions de commons nécessaires y sont définie (au cas où elle ne le seraient pas), mais en plus l'aspect multilingue a déjà été pensé, il n'y a plus qu'à faire la traduction des textes en breton.

⇨ D^r Brains ^{∞ Doléances ∞} 15 décembre 2010 à 01:26 (CET)

Discussion lancée sur place : [1]

⇨ D^r Brains ^{∞ Doléances ∞} 15 décembre 2010 à 01:58 (CET)

Ok merci.

Pour info, je viens déjà de modifier s:br:MediaWiki:Gadget-HotCats.js (étape 1 validée), je pense que Gwendal se chargera de la traduction (mon breton n’étant pas encore assez bon). Le gadget n’est-il pas sensé fonctionné même sans la traduction ?

Cdlt, Vigneron * ^discut. 15 décembre 2010 à 09:59 (CET)

Si, il va fonctionner en français sans problème.

Mais tant qu'à faire autant mettre en place la traduction, puisque ça été pensé pour être multilingue.

⇨ D^r Brains ^{∞ Doléances ∞} 15 décembre 2010 à 14:39 (CET)

Bonjour, ça ne marche pas non plus pour VIGNERON, malgré l'activation du gadget. (voir [2]) Merci.--Gwendal (d) 20 décembre 2010 à 11:14 (CET)

Problème trouvé: C'est la fonction Match and Split de br.WS qui doit être mal configurée et donc entre en conflit avec HotCats.--Gwendal (d) 20 décembre 2010 à 14:46 (CET)

LiveRC

Bonjour, pourrais-tu te rapprocher D'Orlodrim pour les modifications en question. Orlodrim doit avoir la dernière version en date avec les derniers debugs et dernières fonctionnalités. Sa version est basée sur la mienne qui corrigeait plusieurs bugs et ajoutait des fonctionnalités. La version d'Orlodrim n'est pas encore officielle mais ce serait bien qu'elle le devienne, il suffirait qu'un admin remplace le JS de EDUCA33e. Argos42 (d) 17 décembre 2010 à 14:48 (CET)

Bub's wikibot (d · c · b) et ajout de bandeaux de portails

Salut, juste pour signaler un comportement de a priori fautif de ton bot : il ajoute des bandeaux de portail dans des redirects, comme par exemple ici.

Il faudrait le configurer pour qu'il passe sont chemin en cas de redirection. ⇨ D^r Brains ^{∞ Doléances ∞} 7 décembre 2010 à 19:32 (CET)

Bonjour,

Merci pour cette remarque, c'est en effet un bug de traitement d'une requête que je lui ai fait exécuter.

La difficulté ici a été que :

• la page de redirection était catégorisée et le robot l'a sélectionnée ;
• l'attribut XML "redirect=" qui indique — lors de l'énumération des titres — si une page est une redirection n'est pas toujours fourni par l'API (d'après ce que je comprends il n'est mis à jour que depuis quelques temps et uniquement après une modification de la page) ;
• le mot magique #REDIRECTION n'est pas employé dans cette page (c'est la version anglaise qui est utilisée).

J'ai depuis corrigé le bug sur le mot magique (en employant cette requête) et il ne devrait plus recommencer.

Merci pour ta vigilance. Bonne continuation. Bub's [di·co] 18 décembre 2010 à 10:20 (CET)

Wikimag - Semaine 50

Wikipédia:Wikimag/2010/50 CaBot 20 décembre 2010 à 01:17 (CET)

Bistro

Pour info. Moyg hop 20 décembre 2010 à 11:06 (CET)

LiveRC et liste de suivi

Salut,

J'ai fait une modification de LiveRC.js pour prendre en compte la demande de Druth. Le problème est qu'il n'y a aucune valeur de wpWatchthis qui dit "ne rien changer". Si on ne passe rien, la page est retirée de la liste de suivi. J'ai résolu le problème en testant si la page a un élément "ca-unwatch" au lieu de tester l'état de la case "Suivre cette page".

De plus, au lieu du lien en deux parties qui ne semble pas trop plaire, j'ai mis un code qui ajoute simplement un second lien vers LiveRC.

Peux-tu mettre à jour la version principale à partir de Utilisateur:Orlodrim/LiveRC.js (diff) ?

Merci,

Orlodrim ^[discuter] 20 décembre 2010 à 20:06 (CET)

En fait, tu te prends la tête pour rien, il suffit de remplacer :

  var wpWatchthis = doc.getElementById('wpWatchthis').checked ? "&wpWatchthis=1" : "";

par

  var wpWatchthis = ( (doc.getElementById('wpWatchthis').checked && !lrcBypassWatchdefault) ? "&wpWatchthis=1" : "");

⇨ D^r Brains ^{∞ Doléances ∞} 20 décembre 2010 à 20:20 (CET)

Non, car avec cette méthode, lorsqu'on fait une révocation sur une page suivie, elle est retirée de la liste de suivi (j'ai mis des mois à comprendre que des pages disparaissaient de ma liste de suivi à cause de ça). Encore une fois, ne pas passer wpWatchthis signifie retirer la page de la liste de suivi quel que soit l'état précédent. Orlodrim ^[discuter] 20 décembre 2010 à 20:22 (CET)

Ah OK, je comprends pourquoi tu ne fais pas comme ça.

Donc, il faut vérifier si elle est déjà dans la liste de suivi.

Rechercher la présence de ca-unwatch, pourquoi pas, mais n'a-t-on pas déjà en réserve dans une Array (lstSuivi je crois)la liste complète des pages suivies ? Ne serait-il pas préférable dans ce cas de remplacer :

  var wpWatchthis = doc.getElementById('wpWatchthis').checked ? "&wpWatchthis=1" : "";

par

  var wpWatchthis = ( ( (lstSuivi.indexOf(page)!=-1 && lrcBypassWatchdefault) || (doc.getElementById('wpWatchthis').checked && !lrcBypassWatchdefault) )? "&wpWatchthis=1" : "");

⇨ D^r Brains ^{∞ Doléances ∞} 20 décembre 2010 à 20:35 (CET)

Le problème est que lstSuivi est lue au chargement et n'est pas tenue à jour ensuite (ce serait trop lourd). Orlodrim ^[discuter] 20 décembre 2010 à 20:38 (CET)

Mmmh, je m'en doutais...

Alors remplacer :

  var wpWatchthis = doc.getElementById('wpWatchthis').checked ? "&wpWatchthis=1" : "";

par

  var wpWatchthis = ( ( (doc.getElementById('ca-unwatch') && lrcBypassWatchdefault) || (doc.getElementById('wpWatchthis').checked && !lrcBypassWatchdefault) )? "&wpWatchthis=1" : "");

⇨ D^r Brains ^{∞ Doléances ∞} 20 décembre 2010 à 20:43 (CET)

Et bien je crois que ça correspond exactement à ce je propose, si ce n'est que j'ai mis le code dans une fonction pour éviter de le recopier 4 fois . Orlodrim ^[discuter] 20 décembre 2010 à 20:46 (CET)

Ah oui tiens... ⁺.

Faut me pardonner, des fois j'ai du mal...

Bon ben je mets à jour.

⇨ D^r Brains ^{∞ Doléances ∞} 20 décembre 2010 à 21:07 (CET)

Merci . Orlodrim ^[discuter] 20 décembre 2010 à 21:23 (CET)