Discussion modèle:Apprentissage

Cette page de discussion concerne les discussions actuelles concernant la suite de modèle.
Vous pouvez toujours consulter la page de discussion archivée pour lire les anciens débats et problèmes ayant été réglés.

Vote pour l'adoption des modèles

Pour

• Kathan^(d) : A priori, les modèles sont sans accrocs et d'une esthétique très correcte. Je propose donc une adoption (d'autant qu'il y a eu un petit souci à ce sujet il y a quelques temps) définitive.
• InvocK^(d) : Tout ayant été remis en ordre par Misdre, je ne vois maintenant plus de raison de m'opposer à la validation de cette suite de modèle. L'accouchement fut long et douloureux, mais le bébé est beau et en bonne santé !

#Tableau dans un tableau : on peut faire mieux, #Tableaux triables, #Bords arrondis qui a dit "trop facile" ? 8) (selon moi, point 1 bloquant, points 2 et 3 non-bloquants)

--Misdre 26 avril 2011 à 18:20 (UTC)

Tableaux triables : statufié. Bords arrondis : réglé. Tableaux imbriqués : réglé. Verdict ?

Kathan - 28 avril 2011 à 09:11 (UTC)

Je vais encore parler de l'aspect esthétique et des paramètres des modèles avant de ne plus avoir d'objection, dans la journée. Je vais regarder aussi pour le bug avec l'indentation (mais ce n'est pas un point bloquant). Et oui ça prend du temps, mais c'est normal vu que quelque part on travaille sur plusieurs modèles différents (les modes d'apprentissage) et que ça a aussi nécessité de refaire la fonction d'affichage/masquage. Patience, patience.

--Misdre 28 avril 2011 à 09:42 (UTC)

• Misdre^(d) : Je considère le cas #Afficher ou masquer par défaut ? encore ouvert, mais je pense que si ça venait à changer quelque chose, on se débrouillerait pour qu'un bot fasse le boulot. Je n'ai donc plus aucun point à formuler contre l'adoption de ce modèle, et je vote pour.

• Yann^(d) : Pour. Je m'occuperais du bot, si nécessaire (même si ça devra attendre samedi dans tous les cas).

• Noxims^(d)

Résultat

La suite de modèles pour les tableaux d'apprentissage est adoptée.
--Misdre 2 mai 2011 à 23:16 (UTC)

Remarques, questions, débats, propositions

Y a comme un bug

J'ai pas regardé le code du modèle, mais il doit y avoir un problème ressemblant à une balise ouverte mais jamais fermée (ou alors quelque chox de plus sioux, auquel cas bon courage). On a une illustration de ce bug ici-même : on a bien indenté chaque commentaire (si si, j'ai vérifié), mais c'est assez peu respecté et on se retrouve décalé dès le premier test du modèle plus haut sur cette page, et après ça ne respecte plus grand chose.
--Misdre 21 mars 2011 à 21:53 (UTC)

Bon, ça marche à peu près bien si je décale pas les modèles au même niveau que le texte (du coup, voir ici pour avoir une illustration du bug). Je sais plus trop si c'est un bug du modèle maintenant...
--Misdre 21 mars 2011 à 21:57 (UTC)

J'avais remarqué également.

Je pense que c'était dû à la combinaison indentation + "margin-left:2em" appliqué au tableau, qui a créé un "écho" sur l'affichage décalé du texte sur la page (j'espère que mon image est compréhensible).

Je doute que le modèle soit "directement" en cause pour le coup. Je vais faire des tests sur mon bac à sable.

-- Ίηṿō¢Ќ ^{( -Kẅαάκ ?- )} 21 mars 2011 à 22:55 (UTC)

<EDIT d'après-test> C'est bien ça. Il suffit d'une simple indentation appliquée à la première ligne d'appel du modèle pour que le reste de la page se décale. Morale de l'histoire : Modèle + Indentation = Pas bien.

OK, ce problème me semble insoluble dans l'état actuel des choses. La façon dont MediaWiki transforme les : en balises HTML fait que c'est très fragile. Pour corriger ça, il faudrait patcher MediaWiki, et ça ne fait partie des passe-temps de personne ici. La meilleure solution, si vous souhaitez décaler un tableau, et de le mettre dans une div à laquelle vous appliquez un style du type margin-left ou padding-left.

--Misdre 2 mai 2011 à 10:39 (UTC)

Tableaux triables

Cette proposition a été refusée... Pour l'instant !
Les solutions apportées n'étaient pas satisfaisantes, mais des pages d'essais sont à disposition des utilisateurs souhaitant se frotter au problème.

Certains des modèles-tableaux créés ici gagneraient à être triables, à mon avis. Je pense en particulier aux attaques apprises par niveau, où on pourrait souhaiter connaître le Pokémon apprenant l'attaque X le plus tôt.
--Misdre 26 avril 2011 à 02:46 (UTC)

J'y ai également pensé, et je verrai ce que je peux faire sur ce point. -- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 26 avril 2011 à 20:03 (UTC)

Rappel des faits pour le jour où on souhaite s'y remettre : il est possible de rendre le tableau triable, mais cela impose de mettre le bouton afficher ailleurs, par exemple dans caption. Ce n'est pas satisfaisant et on a préféré laisser le bouton à sa place et ne pas rendre le tableau triable.

C'est une limitation technique (ou plus exactement, un bug) de MediaWiki, et j'ai pu remarquer lors de mes recherches qu'il y en avait quelques-uns concernant le tri des tableaux... j'ai aussi remarquer que le code gérant ça avait été entièrement réécrit dans la version de développement de MediaWiki. J'ai passé du temps à essayer de récupérer cette modification mais en vain (même s'il ne manquait a priori pas grand chose... une histoire d'addOnloadHook qui n'existait plus, et dont le remplaçant était impossible à utiliser à cause d'une variable indéfinie) mais j'ai finalement abandonné (il faut imaginer : on est actuellement sur la version 1.17 de mediawiki, qui est officiellement encore en alpha, et la réécriture est faite dans la version 1.18 en développement (très) actif, et a même été discutée pour savoir si elle était annulée et repoussée à la 1.19 - qui n'existe pas encore). Il y a des chances non négligeables que cette réécriture corrige notre problème et permette donc d'avoir un tableau triable même en laissant le bouton à l'intérieur du tableau donc personnellement j'y reviendrai le jour où on sera en 1.18.

--Misdre 28 avril 2011 à 06:41 (UTC)

Afficher ou masquer par défaut ?

Le comportement par défaut est de cacher le tableau. Si on souhaite inverse ce comportement, il faut l'indiquer en utilisant le paramètre afficher.

Ce point est sans doute discutable mais je pense qu'il serait préférence d'avoir le fonctionnement contraire. C'est à dire que par défaut, le tableau soit affiché, et qu'on utilise un paramètre (disons cacher) pour que son comportement soit inversé. Entre autres avantages, ce fonctionnement serait plus proche du code javascript (aucune incidence pratique, c'est juste plus simple de faire le lien (mental) entre le javascript et le modèle), plus proche du comportement si le javascript est désactivé par l'utilisateur (dans ce cas, sans doute assez rare, tous les tableaux sont affichés - vu qu'il serait impossible d'afficher un tableau caché et que le contenu serait donc inaccessible sinon), et euh ça me semble plus logique aussi.
--Misdre 26 avril 2011 à 18:42 (UTC)

Encore une fois, la question ici est d'être le plus pratique possible.

La majeure partie du temps, on met ces tableaux en place pour gagner de la place, leur but étant de masquer une looooooooooooooongue liste de Pokémon.

Je suis partisan de l'idée selon laquelle le but principal défini le paramètre par défaut. Ton argument concernant le mode de fonctionnement du code javascript se tient, mais d'un point de vue pratique pour un codeur, et non pour un utilisateur lambda.

Je crée mes modèles en considérant que les contributeurs sont comme moi partisans du moindre effort peu habiles de leur mains et ayant besoin d'une approche instinctive des choses. S'ils veulent d'un tableau qui cache la plupart du temps, et qui affiche parfois, alors il cachera par défaut, et il faudra indiquer quand il affiche.

-- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 26 avril 2011 à 20:20 (UTC)

Je disconviens :) on va utiliser ces tableaux pour les attaques, d'accord ? on ne les utilisera pas pour gagner de la place, mais pour harmoniser la forme et le contenu des fiches sur les attaques. Chaque attaque étant accompagnée d'un grand nombre d'informations, et en particulier des informations sur l'apprentissage de l'attaque, le visiteur peut vouloir cacher une partie des tableaux après coup. Dans ce cas, on considère que le tableau est affiché par défaut et qu'il désire le réduire (ce cas est là juste pour l'exhaustivité, il ne m'intéresse pas dans la suite).

Ce qui justifie ta position, c'est le fait qu'il y aura beaucoup plus de tableaux d'apprentissage cachés par défaut que de tableaux d'apprentissage visibles par défaut. Ce n'est pas faux pour toutes les attaques apparues à la 3e génération et avant, c'est globalement inexact pour les attaques apparues lors de la 4e génération et de la 5e génération. Je fais ce constat en partant de la décision de cacher tous les tableaux d'apprentissage ne correspondant pas aux deux générations les plus récentes (jusque là il me semble qu'on est d'accord). Tu admets que pour les toutes nouvelles attaques, les contributeurs partisans du moindre effort ne vont pas apprécier ces modèles ?

Allons plus loin et maintenant imaginons qu'on décide de diviser les articles sur les attaques pour déporter les générations les plus anciennes sur d'autres pages (cette décision ne me semble pas si peu probable). Dans ce cas, chaque génération ou presque aura une sous-page dédiée et dans ce cas les tableaux d'apprentissage ne seraient plus réduits par défaut. Si cette décision est prise... ton modèle se trouve en opposition totale avec l'idée que tu en as !

Ajoutons à ça mes arguments précédents (pas de parallélisme avec le code javascript, ni avec le comportement obtenu en désactivant javascript (mineur celui-là), ni même avec le modèle Masquer maintenant que j'y pense (il s'agit bien d'ajouter une précision (utiliser le modèle) pour cacher du contenu par défaut)).

Qu'en dis-tu ?

--Misdre 26 avril 2011 à 21:23 (UTC)

En tant qu'abuseur du Ctrl+F pour chercher rapidement des infos sur une page, chose impossible quand le tableau est masqué, je suis également pour que les informations soient affichées par défaut.

Zhu' 26 avril 2011 à 20:34 (UTC)

Euh attention, il ne s'agit pas de décider si, sur une page d'attaque genre Repos, tous les tableaux d'apprentissage sont par défaut affichés et pas cachés. Il s'agit juste de décider quel comportement par défaut adopte le modèle, c'est à dire : est-ce qu'on choisit de devoir ajouter une précision lors de l'utilisation du modèle (sous la forme d'un paramètre supplémentaire afficher=oui) quand on veut que le tableau soit affiché par défaut, ou est-ce qu'on choisit de devoir ajouter une précision lors de l'utilisation du modèle (sous la forme d'un paramètre supplémentaire cacher=oui) quand on veut que le tableau soit caché par défaut.

Le comportement actuel : on doit ajouter une précision afficher=oui si on veut qu'il soit affiché par défaut

Le comportement que je voudrais : on doit ajouter une précision cacher=oui si on veut qu'il soit caché par défaut

--Misdre 26 avril 2011 à 20:48 (UTC)

Euh soit, donc je pense qu'il faudrait ajouter une précision pour qu'il soit caché par défaut (je trouve pas que ça change grand chose par rapport à plus haut, mais soit xD).

Zhu' 26 avril 2011 à 20:53 (UTC)

Hum... Pas d'accord, Misdre.

A la base, quand j'ai proposé d'utiliser des tableaux en collapsible collapsed, c'était pour gagner de la place d'emblée de jeu. Si on les déroule par défaut, à quoi bon ?

En ce qui concerne les sous-pages, pas vraiment chaud non plus. L'utilisateur lambda va chercher à avoir des infos vite fait bien fait, pas à fouiller péniblement sur cinq pages différentes.

En l'occurrence, l'option des sous-pages dérange autant les adeptes du Ctrl + F que ceux de la recherche un peu plus soignée, vu que

1. Les premiers ne peuvent plus taper un mot clé pour trouver vite fait
2. Les seconds sont obligés de chercher sur plusieurs pages, au lieu de regarder plusieurs tableaux à la fois. Personnellement, j'en suis, et je suis du genre à parcourir en long, en large et en travers une page que je lis. Si elle recouvre une seule génération, je perds en connaissances et c'est moins intéressant.

Du moins, je vois les choses comme ça.

Kathan - 27 avril 2011 à 08:33 (UTC)

La logique des choses voudrait que les tableaux soient affichés par défaut, et qu'on demande à les cacher. Partisan du moindre effort ou non, si un contributeur qui débute doit faire un tableau, il ne comprendrait pas pourquoi ça ne s'affiche pas alors qu'il n'a rien demandé. GreyDragon (Question ?) 1 mai 2011 à 14:12 (UTC)

Intégrer le titre du tableau

Cette proposition a été refusée.

Comme on peut le voir pour l'attaque Laser Glace, les titres des tableaux ne sont plus indiqués à la façon des sections classiques mais font usage du morceau de syntaxe |+ (qui correspond à la balise caption à placer juste après l'ouverture de la balise table). Il faudrait donc le faire au sein des modèles (avec un brin de CSS si l'affichage ne satisfait pas).
--Misdre 26 avril 2011 à 22:51 (UTC)

Et là j'appose un nouveau « Oui, mais » !

Le choix de la caption à la place du titre de section est (à mon avis) un mauvais choix, parce qu'elle empêche de fait le sommaire de l'article d'être exhaustif en terme de contenu.

Et il va falloir se montrer très persuasif pour me faire changer d'avis sur ce point.

-- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 26 avril 2011 à 23:24 (UTC) Un indice tout de même : j'accepte les payements par chèque, carte bancaire ou Paypal.

Oui, j'avais déjà réfléchi à la question y a quelques temps.

Kathan va chercher ses notes

Si je me souviens bien, je m'étais dit que ces titres allaient servir puisque les tableaux, tous enroulés au début, étaient accessibles d'un regard. Ceux-là, ils prennent un peu plus de place, et avec les deux dernières générations affichées c'est moins pratique.

Donc, après courte réflexion, je suis pour les sections classiques. En plus, le problème des titres de tableau, c'est qu'ils ne peuvent être modifiés facilement, on doit chercher à la génération ; quand on veut modifier une lettre, y a mieux.

Kathan - 27 avril 2011 à 08:24 (UTC)

Je ne suis pas trop obtu sur ce point, je réfléchis encore deux secondes et je reviens en parler.

--Misdre 27 avril 2011 à 09:45 (UTC)

Comme je l'ai dit hier sur IRC, je n'ai pas trouvé de solution pour dire au système « hep, ce titre de tableau, met le dans le sommaire » et il n'est pas possible d'entourer d'une balise h* (* entre 1 et 6, a priori fixé à 4 dans ce cas-ci), le contenu de caption, ce qui ferait ce qu'on veut. Plus exactement ça marchouille mais ça peu très bien ne plus fonctionner à tout moment vu le côté bricolage alors c'est pas la peine...

Vu que je n'ai de toute façon pas d'opposition fondamentale à utiliser des sections (je rappelle que sur Repos, où j'utilise caption, je fais des tests (et je continuerai) et qu'il ne s'agit donc pas de la norme ni même de la future norme, il y a des choses qui me déplaisent aussi), on laisse tomber cette histoire de caption.

--Misdre 28 avril 2011 à 06:20 (UTC)

Tentative pour ne pas avoir besoin de préciser le type

Cette proposition a été acceptée.

Dans la lutte contre les paramètres barbants à renseigner, je vais tenter de supprimer le besoin d'indiquer le type de l'attaque.
--Misdre 28 avril 2011 à 10:12 (UTC)

Ça m'a l'air de marcher. Ça utilise le type défini dans l'infobox attaque. S'il n'a pas été défini, ça met le type normal par défaut. J'ai fait l'essai sur le modèle Apprentissage uniquement, si ça convient, je le porte sur les autres modèles Apprentissage-xxx.

--Misdre 28 avril 2011 à 11:13 (UTC)

J'ai fait un test avec Repos et l'argument tous=oui. Je te laisse voir toi-même ce que ça affiche, pas envie de surcharger cette page.

Kathan - 28 avril 2011 à 11:28 (UTC)

C'est complètement dingue oO.

Quand je regarde la page de Repos, aucun problème. Quand j'essaie une autre (Attraction, par exemple), ça bugue -_-.

Working on it. Je te dirai quand c'est OK.

--Misdre 28 avril 2011 à 11:47 (UTC)

Je comprends de moins en moins : j'ai refait des tests, et ça a marché.
J'ai mis le code de Ronflement, qui traîne encore dans un fichier en attendant la validation du modèle. Ça n'a pas marché. J'ai essayé de vider mon cache —-> Raté. Peut-être juste un bug d'affichage, qui se résoudrait si je créais la page au lieu de regarder... En tout cas, ça me dépasse.

Kathan - 28 avril 2011 à 12:17 (UTC)

OK, donc il y a un bug... et il n'y en a pas. Si je devais tenter une explication, il faut savoir que MediaWiki retarde l'exécution de certaines tâches en particulier lors de la modification de modèles (j'ai modifié l'infobox attaque et le modèle apprentissage). Ça peut donner des bizarreries parfois mais c'est très temporaire. J'ai lancé une exécution manuelle de toutes les tâches en attente, une fois terminée il ne devrait plus du tout y avoir de problème.

--Misdre 28 avril 2011 à 12:25 (UTC)

PS : et tente de publier Ronflement, pour voir si tu as le bug, d'ailleurs.

Effectivement, plus rien. Kathan, ou l'art de voir des bugs là où il n'y en a pas T_T

D'ailleurs, tu vas pouvoir modifier les autres modèles pour supprimer le paramètre type, du coup. Apparemment, l'efficacité est certifiée.

Kathan - 28 avril 2011 à 12:28 (UTC)

C'est fait, j'ai modifié les autres modèles pour avoir le même comportement. S'il y a encore un problème, merci de le signaler avec un maximum de gentillesse !

--Misdre 28 avril 2011 à 16:33 (UTC)

Allégement du modèle : une partie des CSS dans Common.css

Ce problème a été réglé.

Une partie des styles des tableaux d'apprentissage peut se mettre dans Common.css, je le fais.
--Misdre 28 avril 2011 à 13:44 (UTC)

J'ai créé et utilisé une classe CSS apprentissage, j'ai déporté quelques lignes de CSS dans Common.css, il y a peut-être moyen de faire mieux mais on dira que c'est amplement suffisant pour le moment.

--Misdre 28 avril 2011 à 16:28 (UTC)

Paramètres tous, toussexué, exception

Cette proposition a été acceptée.

Je me suis permis de déplacer ces trois paramètres dans le modèle Poké parce que ça me semblait plus cohérent (tout ce qui concerne les Pokémon apprenant l'attaque se renseigne en utilisant un seul même modèle) et moins perturbant (Apprentissage et Apprentissage-bas sans rien au milieu...).
Je ne sais pas si vous êtes d'accord mais je tiens à dire qu'il faudra me payer vraiment très cher pour que je change d'avis :)
--Misdre 28 avril 2011 à 16:57 (UTC)

Mon avis va se résumer très vite : pas grave, on y survivra.

Kathan - 28 avril 2011 à 17:04 (UTC)

Il est dommage que cette solution rende le texte masqué. Il s'affichait sans bouton à l'origine.

-- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 28 avril 2011 à 18:05 (UTC)

Je suppose qu'on peut l'afficher avec le bon vieux afficher=1. Et puis bon, ça fait "comme les autres" (tableaux), puisque tout est fermé ou ouvert à volonté, maintenant.

Kathan - 29 avril 2011 à 08:29 (UTC)

Yep, je privilégie la cohérence, pour le coup...

--Misdre 29 avril 2011 à 15:13 (UTC)

Apprentissage-évènement : du superflu ?

Cette proposition a été acceptée.

Une redirection de Apprentissage-événement vers Apprentissage-évènement vous paraît-elle superflue ?
Autre chose : l'en-tête du tableau indique « Évènement requis ». Je pense personnellement que le mot requis est superflu. Votre avis ?
--Misdre 28 avril 2011 à 17:24 (UTC)

Comme tu veux, je l'ai fait vraiment à la va-vite et il est modifiable ^^

Kathan - 28 avril 2011 à 17:37 (UTC)

Les deux orthographes étant acceptées, et certains utilisant l'une plutôt que l'autre, je ne vois pas d'inconvénient concernant cette redirection.

-- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 28 avril 2011 à 17:53 (UTC)

Hors-sujet

Ce problème a été réglé.

Hors-sujet, mais je n'y avais pas pensé avant : il faudrait rajouter un argument niveau.
Kathan - 29 avril 2011 à 09:36 (UTC)

Pourquoi ? L'afficher où ? (ce sont d'honnêtes questions, je ne suis pas un pro des Pokémon issus d'événements).

--Misdre 29 avril 2011 à 09:52 (UTC)

Vu que les Pokémon évènementiels ont quand même un niveau (non, ce n'est pas le joueur qui le choisit), il faudrait que ce soit visible, à la façon d'une section entre Pokémon et Évènement. Quant au "Pourquoi"... Ça peut toujours être utile à savoir, non ? ^^

Kathan - 29 avril 2011 à 09:56 (UTC)

Le pourquoi ne remettait pas en cause l'utilité de la chose, mais cherchait à savoir en quoi les Pokémon événements étaient concernés par un paramètre niveau. OK donc, je vais modifier le modèle pour l'ajouter !

--Misdre 29 avril 2011 à 15:17 (UTC)

Je pense que j'aurais pu le faire moi-même, mais je préfère limiter la casse.

Kathan - 29 avril 2011 à 15:21 (UTC)

Y a des choses qui ont été cassées

Ce problème a été réglé.

Les modèles ont aujourd'hui encore connu pas mal de modifs, et la page Sacrifice, qui permet de les tester globalement, permet de voir ce qui ne va pas (ici des tableaux qui ne se masquent plus, ou des boutons qui ciblent au mauvais endroit, ou encore un pied de modèle sorti de je ne sais où !!).
J'ai du mal à savoir d'où vient quoi, et c'est un peu frustrant...
-- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 28 avril 2011 à 18:17 (UTC)

Désolé, j'ai pas fait assez de vérification sur la fin... comme je vais me reposer un peu, je te donne ce qui me vient à l'esprit comme source des problèmes :

• Le pied de modèle n'est pas un bug, c'est un test que j'ai fait : en gros si tu précises l'argument long=1 dans les modèles Apprentissage-xxx ça te met un pied. C'est un test, faut que j'en parle (mais c'est pas bloquant pour l'adoption du modèle).
• Les problèmes autour des boutons et de l'affichage masquage, ça vient peut-être du code insérant le bouton (j'ai fait du copié collé un peu rapide pour avoir la même chose partout, j'ai peut-être fait une erreur) ; vérifier aussi la classe CSS de tbody.

Voilà, désolé encore... je regarderai après ma sieste si tu n'as pas trouvé.

--Misdre 28 avril 2011 à 18:24 (UTC)

C'est bon, c'était au niveau du bouton que les class définies se répétaient, j'ai pu corriger tout ça !

-- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 28 avril 2011 à 18:38 (UTC)

Lien des miniatures

Ce problème a été réglé.

Il serait préférable qu'un clic sur les miniatures des Pokémon mène vers la page de ce Pokémon plutôt que vers la page de la miniature, non ?
--Misdre 28 avril 2011 à 21:31 (UTC)

Ça c'est quelque chose que j'ai toujours considéré qu'on aurait du faire avec le modèle {{miniature}}.

-- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 28 avril 2011 à 22:21 (UTC)

Alors on le fait. S'il y a des cas où on veut la miniature sans le lien, on aura qu'à utiliser le nom du fichier directement, ça doit être le cas minoritaire...

--Misdre 28 avril 2011 à 22:34 (UTC)

Il faudrait juste rediriger les différentes formes vers la forme principale (Deoxys Attaque -> Deoxys, etc).

Kathan - 29 avril 2011 à 11:03 (UTC)

Paramètres remarque et rmq

Bon, j'ai pas mal réfléchi, et je pense qu'il faut tout simplement les supprimer ou changer leur nom & but selon le modèle. C'est pas que je trouve ça mal fait, mais plutôt qu'il est impossible de toujours intégrer nos besoins de façon automatique à ces modèles :

• Apprentissage par niveau : lorsqu'un Pokémon apprend une attaque à des niveaux différents selon le jeu dans la même génération, il faut une remarque par niveau donné (exemple : 10^DP, 15^Pt - ce qu'on ne peut pas gérer via ce modèle). Il n'y a aucune remarque à faire concernant le Pokémon en lui-même. Action : suppression des paramètres pour le modèle Poké-niveau.
• Apprentissage par CT : il peut y avoir une remarque, mais la seule possible est une indication de version, par exemple Kabuto qui ne peut apprendre Sacrifice dans la première génération qu'avec dans la version jaune. Action : renommage du paramètre remarque en version, suppression du paramètre rmq pour le modèle Poké (la forme imposée étant la mise en exposant).
• Apprentissage par événement : là on peut laisser remarque... on peut en avoir comme le niveau du Pokémon-événement (je dis ça au pif). En revanche, supprimer rmq (encore une fois la forme imposée étant la mise en exposant). Action : ne pas toucher remarque, supprimer rmq pour le modèle Poké-évènement.

En attente pour l'apprentissage par reproduction (l'indication à gérer, c'est le chain breeding ou reproduction en chaîne ou... lignée ?, donc il faudrait renommer remarque en conséquence), et par pré-évolution (a priori là on laisse les deux remarques, on supprime juste rmq et rmq2 et la mise en forme par défaut est juste la mise en exposant).

À la place de rmq on va créer des modèles pour indiquer les versions dans le cas des niveaux et des CT (abréviation + couleur + texte d'infobulle). Les modèles d'apprentissage peuvent être validés avant la création de ces modèles. En revanche ce que je dis plus haut est vraiment un point bloquant. Je veux bien oublier l'histoire encore plus haut sur le paramètre afficher où j'admets que le point de vue contraire a du sens mais là sur ce point je me vois difficilement transiger. Et si ce que je dis là est réglé mais que je n'interviens plus à cause d'une grosse charge de boulot, considérez que je vote pour, pas besoin d'attendre mon feu vert puisque c'est ma dernière objection.

--Misdre 28 avril 2011 à 23:06 (UTC)

Je préférerais conserver un paramètre qui me permettrait d'indiquer toutes les remarques que je juge judicieuses et ce pour tout les modèles. Admettons, par exemple, que dans un futur jeu, un Pokémon apprenne une attaque à un niveau spécifique et dans un lieu particulier, le paramètre remarque/rmq aura alors tout son sens.

Franchement je préfère un seul paramètre générique pouvant palier à tout les cas de figure que quatre ou cinq paramètres finalement assez restrictifs.

Je ne suis pas contre une réforme du modèle mais je pense qu'il est utile de pouvoir indiquer ce que l'on veux, soit en indice, soit dans une infobulle, dans n'importe quel modèle.

Noxims 28 avril 2011 à 23:52 (UTC)

Je suis plutôt d'accord, j'y ai songé après m'être couché et j'ai eu la flemme de revenir dire ça, mais en fait on peut garder le nom générique remarque (et parler des cas possibles dans la doc, ce qui pour l'apprentissage par niveau revient à dire "ce paramètre est inutilisé pour l'instant", un peu particulier mais on peut vivre avec). Par contre je suis catégorique : il faut vraiment supprimer rmq/rmq2 et se contenter de mettre en exposant, après c'est l'utilisateur qui se charge d'utiliser le code utile pour mettre le texte et l'infobulle qu'il veut. rmq est en fait trop restrictif, il impose d'avoir une seule infobulle, ce qui n'est pas pratique si on a plusieurs remarques à faire et si on veut harmoniser la manière dont on veut noter les indications de version.

--Misdre 29 avril 2011 à 05:09 (UTC)

J'ai eu un peu de mal à lire tout ça d'un bloc, surtout au petit matin (bon, matin tout court), mais bon...

Alors. Déjà, l'apprentissage par reproduction a besoin de la remarque. Voir Sacrifice. Ensuite, pas envie de mettre des petites abréviations en couleur. Ça dépareillerait le modèle, et trancherait trop par rapport au reste.

L'apprentissage-niveau : Quand on sort une remarque, c'est pour la forme. Sinon, on met les deux niveaux sur deux lignes. Et je suis d'accord avec Noxims.

Pour rmq, je te laisse faire.

Kathan - 29 avril 2011 à 08:22 (UTC)

P.S : Désolé si ce message est incompréhensible... J'ai dû me coucher vers cinq heures du mat' hier et je suis totalement claqué ><

<EDIT> Après réveil, une question me taraude l'esprit...

Pourquoi supprimer ces arguments ? Ils sont personnalisables, facultatifs... C'est plus une manière de se compliquer la vie qu'autre chose, pour moi oO

Si tu regardes ma dernière intervention, je dis qu'on peut laisser les paramètres remarque, même ceux qui ne servent à rien pour le moment (celui de Modèle:Poké-niveau) et que je me suis emporté les concernant. Reste qu'on supprimerait rmq car ils restreignent les remarques qu'on peut noter. Déjà dit ça plus haut... quant aux petites abréviations de couleur et aux niveaux sur une seule ligne, c'est gravé dans le marbre depuis et pour un bon moment.

--Misdre 29 avril 2011 à 10:10 (UTC)

Ça n'a jamais été gravé. J'ai toujours préféré mettre les niveaux sur deux lignes, qui permettent de bien montrer la séparation. Et je pense ne pas être le seul à être dans ce cas.
D'ailleurs, je ne vois toujours pas pourquoi supprimer rmq.

Kathan - 29 avril 2011 à 10:44 (UTC)

rmq est en fait trop restrictif, il impose d'avoir une seule infobulle, ce qui n'est pas pratique si on a plusieurs remarques à faire et si on veut harmoniser la manière dont on veut noter les indications de version. Exemple : si je dois indiquer que tel Pokémon ne peut apprendre cette attaque que par chain breeding, ça me fait une remarque. Si en plus ce n'est possible que dans une version, je dois aussi faire la remarque. rmq impose la présence d'une seule infobulle, ce qui peut donner lieu à des infobulles de trois mètres de long ET sur des "sujets" différents (chain breeding, version). C'est pas clair.

De plus concernant l'harmonisation des indications de version, cette façon de faire laisse l'utilisateur très libre sur la façon d'indiquer qu'une attaque ne s'apprend à tel niveau que sur telle version. On risque de se retrouver avec plusieurs façons d'indiquer la version suivant les fiches. Là est le problème d'harmonisation. Ne pas utiliser rmq permettrait de créer un modèle d'indication qui serait utilisé à chaque fois, donc le rendu serait identique partout.

Voilà pourquoi je tiens à supprimer ce paramètre, c'est pas juste une lubie... d'ailleurs InvocK a déjà commencé à créer les modèles d'indication, ils demandent encore un peu d'amour mais ils existent.

Je répondrai sur les abréviations de couleur et les lignes à part, pour que déjà on se comprenne sur ce point avant d'enchaîner sur ce deuxième point sans doute plus polémique.

--Misdre 29 avril 2011 à 11:02 (UTC)

Dit comme ça, je comprends mieux. Et reste neutre.

Ceci dit, je vais faire les deux exemples d'indications de niveau (qui sont un peu hors-sujet d'ailleurs).

Pokémon			Niveau
[-] Masquer
0025		Pikachu	N.14RFVF / N.35RSE

Pokémon			Niveau
[-] Masquer
0025		Pikachu	N.14 N.35

Il me paraît un peu anormal que les indications, dans la première version, prennent autant de place que le nom du Pokémon. De plus (ce n'est qu'un avis personnel), je trouve plus esthétique de caser légèrement en hauteur que de s'étendre en longueur à ce point.

Kathan - 29 avril 2011 à 11:11 (UTC)

Ah mais d'accord... on n'est pas opposé sur ce point alors, il y a quiproquo ! Je pensais que tu doublais totalement la ligne, c'est à dire que tu mettais plusieurs fois le Pokémon (une ligne entière pour chaque niveau différent !). Le retour à la ligne juste pour la dernière case, comme ça, ne me gêne mais alors absolument pas (pour les couleurs et l'indication, j'y reviens plus tard).

--Misdre 29 avril 2011 à 11:14 (UTC)

Aaaaah... Ah oui, je comprends mieux. Après, en ce qui concerne les couleurs d'indication, j'ai déjà fait un truc pour les donneurs de capacités sur Ronflement, mais je vois très mal ça casé en tableau

Donc, autant s'arrêter là (et revenons-y plus tard, dans une énième section mieux adaptée).

Kathan - 29 avril 2011 à 11:19 (UTC)

Je fais la modification... (suppression de rmq/rmq2 partout, remarque reste partout aussi).
--Misdre 30 avril 2011 à 12:56 (UTC)

Pas très pratique... Ça fait très moche, dans la partie reproduction de Sacrifice :/

Kathan - 30 avril 2011 à 13:18 (UTC)

Leçon 1 : attendre que ce soit fini avant d'en parler. (leçon 2 : il y a un petit truc pas bien dans la CSS que je vais corriger, le texte devrait être noir par défaut) (leçon 3 : c'est facile à révoquer, si jamais)

--Misdre 30 avril 2011 à 13:26 (UTC)

Bon bon bon, je me tais (et j'ai droit à une bonne note, si j'apprends bien mes leçons ?).

Kathan - 30 avril 2011 à 13:29 (UTC)

Tu as la parole (et tu auras peut-être un schokobon).

--Misdre 30 avril 2011 à 13:48 (UTC)

Hey, ça c'est pas cool, moi j'ai jamais eu droit à un Schokobon !

C'était la seule intervention intéressante que j'avais à faire sur ce sujet.

-- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 1 mai 2011 à 19:53 (UTC)

Style bizarre

Ce problème a été réglé.

Ce point n'est PAS bloquant et peut tout à fait être réglé 6 mois après l'adoption des modèles. Il y avait des style="color: black;" un peu partout, je l'ai supprimé et certains textes sont devenus invisibles (ou blancs). J'ai ajouté deux lignes dans MediaWiki:Common.css et c'est réglé. Si j'en parle c'est pour deux choses :

• Il peut toujours y avoir des conséquences que je n'ai pas vu, n'hésitez pas à les signaler (attention, la bonne façon de corriger d'éventuels problèmes n'est pas de faire revenir les style="color: black;" au galop),
• Il reste à trouver pourquoi c'était blanc et pas noir par défaut (je n'ai pas trop le temps de chercher là maintenant).

Voilà !
--Misdre 30 avril 2011 à 13:48 (UTC)

L'explication est très simple, et se trouve [[:Catégorie:Modèles de couleurs|ici]]. En fonction du type défini comme couleur de fond, le texte pouvait être défini en blanc, ce qui m'avait poussé lors de la création du modèle à forcer le noir avec color:black. J'avais adopté la même attitude il y a longtemps lors de la création des modèles pour les familles d'évolution.

Merci en tout cas d'avoir réglé ce problème par le biais des commons. -- Ίηνō¢Ќ ^{( -Kẅαάκ ?- )} 1 mai 2011 à 19:42 (UTC)

Liste des cas à documenter avec exemples

Je vais documenter un certain nombre de cas :

• Comment indiquer plusieurs niveaux d'apprentissage pour un même Pokémon
• Comment indiquer une spécificité à une ou plusieurs versions (ça peut rejoindre le premier point)
• Comment indiquer une chain breeding
• Comment donner une information spécifique comme sur la page de Crocs Éclair

Merci de m'indiquer des cas particuliers que j'aurais pu oublié afin que je les documente (si nécessaire). Attention, la façon de faire ne se discute pas là mais dans des sections différentes ! (mais attendez la doc...)
--Misdre 30 avril 2011 à 14:10 (UTC)

• D'accord. On a déjà eu un petit souci récemment à ce sujet, autant avoir une façon fixe et bien définie
• Du genre Tel Pokémon apprend telle attaque uniquement dans tel jeu ?
• Petite astérisque avec une infobulle par chaîne uniquement. Pour l'instant, c'est ce qu'on fait. Ou alors, un petit dessin de chaîne au lieu de l'astérisque, mais c'est moins facile.
• Est-ce vraiment utile ? A la limite, ce n'est pas vraiment important... Si vraiment il faut le mettre, on peut faire à la façon de Bulbapedia : en petit, incorporé dans le bas du tableau. Dans ce cas, il suffirait de configurer le Modèle:Apprentissage-bas pour accepter un argument

Ceci dit, pas d'idées particulières, mais je chercherai.

Kathan - 30 avril 2011 à 15:00 (UTC)

Yep, le dernier point (Crocs Éclair) n'a sans doute pas besoin d'être formalisé, je ne m'en occuperai pas plus que ça.

--Misdre 30 avril 2011 à 16:34 (UTC)

Position des tableaux

1 mois après Pourquoi avoir intégré les tableaux à gauche? Les positionner au centre serait peut-être mieux esthétiquement et pratiquement, sachant qu'il y a pas mal de tableaux placés au centre actuellement, pourquoi ne pas faire la même chose avec les modèles récemment créés? G®ï$øù 8 juin 2011 à 19:48 (UTC)

Pour éviter le décalage dû à l'infobox. (désolé si je ne suis pas précis, j'ai la flemme d'en dire plus... Je détaille tout à l'heure, promis)

Kathan — 9 juin 2011 à 07:10 (UTC)

L'heure tourne !

--Misdre 6 juillet 2011 à 18:36 (UTC)

Ça m'est sorti de la tête ^^' (on va dire que j'habite sur une autre planète, les jours y sont beaucoup plus longs). Enfin, t'aurais quand même pu attendre deux jours, ç'aurait fait un mois tout pile.

Bon, bref.

En gros (sans savoir si Grisou va me lire... T_T), quand on a une infobox (sur la droite), le tableau considère (apparemment) que la page s'arrête au début du cadre de l'infobox. Il va donc se décaler de quelques centimètres sur la gauche. Alors que les autres tableaux, qui ne seront plus à côté de l'infobox grâce à la taille du premier tableau, vont reprendre une place normale.

En bref (faut que j'arrête avec cette expression), si les tableaux étaient au centre, le premier serait toujours décalé par rapport aux autres. Tu peux encore voir cet effet sur n'importe quelle page encore aux vieilles normes (Jackpot ou Spore, par exemple).

Et j'ai essayé beaucoup de trucs : avec le parpaing monstrueusement long qui traîne sur toutes les fiches, pas moyen de mettre le premier tableau hors de son cadre. A moins de sauter vingt-cinq lignes derrière une description ultra-détaillée.

Donc, l'explication est suffisante ou un peu plus claire que de la boue ?

Kathan — 7 juillet 2011 à 08:16 (UTC)

Modèle Couleur

Ce problème a été réglé.

Apparemment, le tableau réagit mal au modèle Couleur. On peut le voir très nettement sur certaines pages, surtout que seul ce tableau là utilise Couleur et pas Couleur Type.
En bref : la bordure n'existe plus. Il doit y avoir un bug quelconque, que je ne trouve pas en tout cas... Il faudrait que quelqu'un regarde, parce que c'est vraiment moche.
Kathan - 10 juillet 2011 à 09:03 (UTC)

Done, une histoire sordide de ligne sautée au milieu de la définition de style (Correction).

Zhu' 14 juillet 2011 à 12:29 (UTC)

Précision du type dans les tableaux

Je viens de mettre à jour Malédiction et je constate qu'il n'est plus possible de préciser le type dans les tableaux hormis pour le modèle apprentissage, étant donné qu'il s'agit d'une attaque qui change de type en passant à la gen 5, je me suis dis qu'il serait pertinent de mettre les tableaux récapitulatif des génération 2 à 4 aux couleurs du type car dans ces générations, l'attaque n'est pas de type spectre.
Noxims 1 août 2011 à 20:35 (UTC)

Tableaux allongés

Là, je sens que je vais arriver comme un cheveu sur la soupe - En bossant sur la refonte graphique des articles des types (exemple, à priori fini), je me suis dit que les tableaux à multi-colonnes peuvent s'avérer pratiques. En regardant une page comme une autre, on peut voir que, quand tous les tableaux sont ouverts, on se retrouve avec une perte de place monumentale : une page qui s'allooooooonge... pour rien. Une page plus courte serait sûrement plus agréable à l'oeil et plus pratique à visiter (je pense notamment à la section Dessin animé, reléguée tout au fond de l'article). On a aussi un exemple, assez moche mais tant pis.
Je pense donc à des tableaux à au moins deux colonnes (on en a déjà brièvement parlé). J'ai malheureusement peur que ce soit irréalisable avec les arguments actuels, et ça donnerait un joyeux chantier si on devait en rajouter.
Bref, quelqu'un aurait une vague idée pour rendre ça possible ?
Kathan - 18 juillet 2011 à 11:53 (UTC)