Wikipédia

Discussion Projet:Modèle/Harmonisation

< Discussion Projet:Modèle
Dernier commentaire : il y a 3 mois par SyntaxTerror dans le sujet Liste des paramètres problématiques
En savoir plus sur cette page
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Portail de qualité
  • Bon portail
  • Lumière sur
  • À faire
  • Archives
  • Commons

Harmonisation des Infoboxes modifier

Dernier commentaire : il y a 16 ans4 commentaires3 participants à la discussion

Salut! Je travail ces derniers temps à confectionner des Infoboxes, mais avant de la construire je cherche toujours une norme qui se rapporte à ce type d'Infobox. C'est à ce moment que je me rend compte à quel point c'est le "free-for-all" dans les Infoboxes et qu'il n'y a pas vraiment d'harmonisation. Premièrement, j'ai l'intention de nommer toute nouvelle "Infobox" que je fabrique en "Fiche..." qui est un terme plus aproprié sur WP francophone.

Ensuite pour la charte graphique, c'est vraiment pêle-mêle; il est inutile d'avoir une charte graphique si tout le monde peut retoucher les couleurs à sa guise. Elle devrait être uniforme et rigide. Comme par exemple Modèle:Liste InfoBox/Musique, à mon avis, il devrait y avoir une couleur UNIQUE pour tous les types de "Fiches" qui se rapportent à la musique... sinon il parfaitement inutile d'avoir une charte graphique.

J'aimerais avoir vos commentaires avant de me lancer dans le GRAND ménage des "Infoboxes" (qui deviendront éventuellement des "Fiches". Au plaisir, Antaya @ - 18 août 2007 à 20:49 (CEST)Répondre

  • C'est bien pour résoudre ce problème que j'ai créé cette page ; donc complète-là d'abord.
  • Je pense que l'apparence graphique est une question annexe, déjà en partie réglée, et conflictuelle. C'est pourquoi j'ai préféré faire l'impasse là dessus. (Annexe ... car il est plus facile de retoucher un modèle ou une feuille de style que de rectifier tous les articles en cas de mauvais paramétrage.)
  • « il devrait y avoir une couleur UNIQUE pour tous les types de "Fiches" qui se rapportent à la musique. » Ca me parait un peu violent. Je dirai plutôt « Il est souhaitable que des infoboxes similaires aient dans leur apparence graphique un élément rappelant leur appartenance à une famille commune ». Si disons {{Fiche Album Classique}} et {{Fiche Album Rock}} dérive d'un même modèle {{Fiche Album}}; cela (l'apparence similaire) se fera naturellement.   <STyx @ 25 août 2007 à 22:02 (CEST)Répondre
J'ai beau lire et relire les propositions de "Modèle/Harmonisation", mais tout n'est pas clair et je serais mal venu d'écrire sur cette page alors que je ne comprend pas tout!

Quelques points qui me semblent importants
  • D'après-moi, la classe "infobox" est désuète; les lignes séparatrices des cellules alourdissent (inutilement) le visuel d'une fiche.
  • Le phénomène text-align="center" donne une impression d'un manque de structure. Les deux colonnes devraient être alignées à gauche.
  • Je crois que l'utilisation des "#if:" est mieux que "HiddenStructure", sauf dans quelques cas exeptionnels.
  • Favoriser les Méta-modèles, et empêcher leur modifications.
Bref, je préfère me plier à des règles établies que de débattre de ces règles : c'est que je suis un exécutif! Mis à part les principes des classes, voici ce que je crois être un bon codage pour une Fiche : voir mon bac à sable #6. Il y a sûrement d'autres points, mais pour l'instant c'est ce qui me fait hésiter à me lancer dans d'autres constructions.

Bonjour,

Alors plusieurs choses. Déjà, c'est une convention d'appeler les infobox "Infobox XXXX" (voir Aide:Infobox). Il y a eu de longues discussions à ce propos ya déjà un petit moment, à savoir si on devait garder le terme infobox ou le franciser. Je n'ai plus le lien sous la main mais ca doit pouvoir se retrouver.

Ensuite, il y a eu un sondage sur une harmonisation des box musicales. Je pense que c'est une bonne chose de s'attaquer à un domaine précis (la musique) et le faire bien plutot que de s'attaquer à un travail de titan que de recharter et retravailler toutes les infobox. Ensuite ya un Projet Infobox, des pages d'aides sur les box, les modèles, la charte graphique, et également beaucoup de discussions à ces propos... Je pense que ce n'est pas une bonne idée de faire les choses dans son coin, ca va mettre encore plus de disparités dans les box qu'autre chose.

Je vous invite à vous rendre ici : Wikipédia:Sondage/Choix des infobox du projet musique, point de départ du travail qui est en cours.

JSDX 8 septembre 2007 à 20:39 (CEST)Répondre

Les réponses a tes remarques se trouvent dans l'introduction de la page.   <STyx @ 15 septembre 2007 à 16:56 (CEST)Répondre

Le problème du # dans les couleurs modifier

Dernier commentaire : il y a 16 ans4 commentaires2 participants à la discussion

Plutôt que de passer par un modèle ou autre, on peut aussi utiliser la balise # au sein du modèle qui peut s'avérer bien pratique ! Voilà :) --Paulokoko 猿渡樹 27 septembre 2007 à 10:21 (CEST)Répondre

  • Il y a sans doute malentendu. Il est jugement question « utiliser la balise # au sein du modèle » et c'est cela qui crèe « Le problème du # dans les couleurs ».   <STyx @ 1 octobre 2007 à 21:43 (CEST)Répondre
Erf nan mon commentaire n'a pas rendu mon idée :p En fait voilà je voulais dire : on peut utiliser <nowiki>#</nowiki> pour afficher l" # ^^ --Paulokoko 猿渡樹 6 octobre 2007 à 11:42 (CEST)Répondre
UP ! Comme on dit :p Je ne sais pas si vous avez vu mon dernier commentaire, sans doute passé inaperçu dans l'historique. --Paulokoko 猿渡樹 9 octobre 2007 à 09:38 (CEST)Répondre

Webdesign/Mise en page modifier

Dernier commentaire : il y a 16 ans2 commentaires2 participants à la discussion

Bonjour,

Récemment j'ai charté les nouvelles infobox musicales et d'autres petits travaux comme le background de la box réalisateur, par exemple. J'ai des connaissances en webdesign, mise en page, typographie, que je mets en oeuvre dans mon travail.

Pour compléter l'harmonisation du code, des noms des paramètres, bref du fond des infobox, j'ai constaté que sur la forme, c'était limite voire inexistant. J'avais alors commencé à écrire quelques lignes ici : Projet:Charte graphique/Apparence des InfoBox mais je ne sais pas si c'est l'endroit approprié.

J'aimerai écrire quelques conseils de façon plus poussée, puis-je le faire ? Si oui, où ? JSDX 28 septembre 2007 à 09:14 (CEST)Répondre

Palette de navigation modifier

Dernier commentaire : il y a 16 ans3 commentaires2 participants à la discussion

Salut STyx, je fabrique souvent des palette de navigation et je me demandais s'il n'était pas mieux de définir une nomenclature similaire aux infoboxes. Par exemple, on commence toujours par le mot "Infobox" tout de suite après l'espace de nom; ensuite le nom l'infobox en commençant par une majuscule (EX - Modèle:Infobox Ville du Canada). Bref, pour les palettes en bas des pages, est-ce que tu crois que je peux définir les titres de la même façon? (EX - Modèle:Palette Subdivisions du Québec)... Il me semble que c'est plus logique, et lorsque l'on recherche dans l'espace de nom, c'est plus facile de les trouver car elles sont toutes groupées.

Qu'en penses-tu? Merci pour tes éternels bons conseils! Au plaisir, Antaya @ - 6 octobre 2007 à 00:14 (CEST)Répondre

Excellente idée !   <STyx @ 6 octobre 2007 à 00:29 (CEST)Répondre
  • il y a aussi Menu pour les ... menus ;) (aie j'ai utilisé "Navigation" ; voir {{Méta navigation}})
  • En généralisant, on dirait « Pour chaque grande classe de modéles, on utilisera un mot-clé particulier en préfixe du nom du modèle »
  • Mais on pourrait regrouper par méta modèle (ca ferait beaucoup de termes à inventer)   <STyx @ 6 octobre 2007 à 20:03 (CEST)Répondre
Palette
 
Navigation
 
Menu
 

Concernant l'harmonisation modifier

Dernier commentaire : il y a 16 ans17 commentaires5 participants à la discussion

Bonjour je me pose uen question toute bête : où en est-on avec l'harmonisation des infobox et des modèles ? Quelles sont les règles, notamment celles de nommages ? Quand utiliser « Fiche », « Infobox », « Palette » .. y'a t'il une page de recommandation ? (Dans le cas de {{Brasserie}} et {{Bière}} je devrais remplacer par Infobox Brasserie/Bière ? --Paulokoko 猿渡樹 6 octobre 2007 à 11:00 (CEST)Répondre

Moi je prône pour les "Fiches" qui est un terme français, mais il y a encore beaucoup de contestations lorsque je fais équipe avec d'autres contributeurs; mais si tu veux on pourrait les appeler Modèle:Fiche Bière et Modèle:Fiche Brasserie c'est la norme qui tend à être adoptée. Pour la programmation, il y a moyen d'intégrer les anciennes infoboxes, sans recourir aux bots (en tout cas pour le début et durant l'installation, etc.), et de créer les bons paramètres (mots complets, minuscules, etc.)... Pour l'entête de la fuche, ce serait bien de demander à JSDX de nous pondre un ti-graphisme qui tue sa mère! Alors fais-moi signe quand tu veux, je peux t'aider... Au plaisir, Antaya @ - 6 octobre 2007 à 11:29 (CEST)Répondre
Pour le graphisme ça va aller. Et je ne connais pas la maman de JSDX, je ne lui veut aucun mal :D « Fiche » donc. Si tu n'y vois pas d'inconvénient je prends en charge cette tâche ^^ Ceci-fit pour le mot fiche, ça va être compliqué dans pas mal de cas. Je pense aux taxobox.. Fiche taxon ? Ca va être une discussion sans fin :p --Paulokoko 猿渡樹 6 octobre 2007 à 11:41 (CEST)Répondre
Petit commentaire. Après avoir consulté le sondage et la page infobox, ma conclusion est : "mais c'est un peu le foutoir °_O". En fait personne ne semble s'être mis d'accord. Des requêtes à des bots de type "modifier {{Commune de france}} en {{Infobox Commune de france}}" apparaissent chaque jour.. Bref, j'ignore toutes les discussions qui ont eu lieu à propos du renommage, je suis plutôt pour personnellement bien que c'est un travail titanesque. Infobox étant un terme un peu étrange, peu facile d'accès pour le nouveau venu. Ceci dit il serait bien de mettre en place de vraies recommandations, une annonce.. Bref un grand chantier, fédérateur, un peu comme celui de Wikipédia 1.0. --Paulokoko 猿渡樹 6 octobre 2007 à 12:26 (CEST)Répondre
Non je n'y voit pas d'inconvénient que tu prennes en charge, mais ce serait bien de continuer dans la lignée des nouvelles infoboxes pour le style, mais sans la charte graphique là! JSDX fait des merveilles avec ses entêtes. Pour le terme "Fiche...", est que tu parles de ce sondage? Et finalement, est-ce que tu démarres le modèle dans ton bac à sable ou ailleur?... C'est que j'aimerais bien suivre l'évolution! Au plaisir, Antaya @ - 6 octobre 2007 à 12:51 (CEST)Répondre
Je vais faire quelques tests de graphisme chez moi (les idées de JSDX sont excellentes, je vais reprendre le concept général avec une choppe de bière ou autre en fond.. je vais faire des tests) et une fois que j'aurais terminé je ferai un brouillon perso et je t'aviserai pour que tu me commentes ça, et le modifier aussi si tu y vos des bêtises. Oui sinon je parlais effectivement de ce sondage.. au final c'était assez mitigé il me semble. Mais je vais prendre en considération les recommandations des fiches, notamment pour les métadonnées et les formats numériques. --Paulokoko 猿渡樹 6 octobre 2007 à 13:18 (CEST)Répondre
Coucou les gens ! Alors bien que je porte mon codeur Antaya dans mon coeur, je ne suis pas daccord avec lui sur tout, et surtout sur FICHE ! N'écoute pas ce quebequois qui veut tout franciser ahah ! ;p. Nan il me semble qu'il y a déjà eu des discussions et surtout, dans les recommandations, y disent de mettre Infobox. Comme la grande majorité des box sont appelées Infobox, que c'est un terme qui est rentré dans le language courant Wikipédien, pourquoi ne pas l'utiliser. C'est comme Hotdog, Parking, et tout les termes qui sont rentrés dans notre langage. Et c'est très bien comme ça ;D JSDX 6 octobre 2007 à 14:51 (CEST)Répondre
Ok, n'en déplaise à Antaya, et pourtant je t'apprécie grandement et j'apprécie tes contributions et tout ce que tu fais pour l'harmonisation... mais je rejoint JSDX sur ce point. Je voulais depuis un moment rejoindre la recommandation qui dit "Infobox XXXX" pour mes modèles, j'ai voulu m'y mettre et je suis venu ici et l'histoire des fiches m'a un peu troublé. Il faut réellement se mettre d'accord, et non pas d'accord avec le simple projet:modèle mais avec toute la communauté. Je ne sais pas comment mettre tout le monde d'accord est possible, mais il faut le faire, car d'un côté on a les pages d'aides, les recommandations, et de l'autre on a les idées du projet d'harmonisation. Je préfère attendre "l'avis du public", même si cette idée de franciser me plait dans le fond.. mais au final j'ai peu de contribuer à un possible "foutoir". Il faudrait notamment différencier Infobox de Fiche de cette page, car pour l'instant ça n'"harmonise" pas trop amha, et à mon grand regret car je soutiens complètement ce type de projet. Voilà je préfère attendre pour le moment car comme le dit la page "La notion de fiche est donc au stade du prototype". --Paulokoko 猿渡樹 6 octobre 2007 à 15:40 (CEST)Répondre
  • "La notion de fiche est donc au stade du prototype" : oui hélas ; donc pas de fiches dans les articles pour le moment
  • « différencier Infobox de Fiche » : en faire des "Fiches" sera un moyen commode de remplacer les vieilles infoboxes par des neuves (aux normes) ; le « fait » du « à faire » . Donc "Fiche=infobox bien faite" (si c'est pas assez clair sur cette page, rectifiez)
  • Voici mon #Plan de travail.   <STyx @ 6 octobre 2007 à 18:43 (CEST)Répondre
  • Le nom des modèles n'est pas le plus gros problème. Le plus gros problème, c'est les paramètres (leur nom et leurs contenus)
  • Nom point de vue est : « plutôt que de résorber le foutoir par petites touches, repartons de zéro. »   <STyx @ 6 octobre 2007 à 18:57 (CEST)Répondre

STyx, je suis totalement d'accord avec ce que tu viens de dire, il faut absolument mettre ça en place rapidement, parce que je sens que je tergiverse pour rien. Il y a trop d'informations partout qui divergent et ça devient difficile de faire valoir son point. Merci pour ton bon travail. --Antaya @ - 6 octobre 2007 à 19:25 (CEST)Répondre

Ça suffit JSDX, je ne suis pas CE québécois à se méfier qui veux tout franciser! Je n'ai même pas participé au sondage pour franciser le terme Infobox, je ne fais qu'appliquer ce vers quoi on se dirige collectivement! Mais au final, faut se questionner sur cette manie qu'ont les français de tout angliciser? C'est à la mode sur le vieux continent, ça fait plus "people"? Émoticône Bref, c'est pas mal plus logique d'appeler ces modèles des "Fiches", que de simplement poursuivre l'anglicisation de Wikipédia.fr. En tout cas, on va les appeler Modèle:Infobox Bière et Modèle:Infobox Brasserie si ça vous chante, c'est plus urgent de fabriquer des belles fiches, avec un paramétrage harmoniser, plutôt que de les nommer en français!
Un attendant JSDX, pour en revenir à ton commentaire du québécois qui veux tout franciser, j'aimerais que tu médites sur le fait que la langue française n'est parlée que par 7 millions de personnes aux Amériques, c'est normal qu'on veuille la protéger farouchement... Et on ne peut pas compter sur la France (le CILF) pour appuyer sa propre langue; d'ailleurs, c'est pour ça que l'Office québécois de la langue française a été mis en place après la révolution tranquille, nos deux pays sont souvent en opposition pour l'utilisation et l'évolution de la langue... c'est déplorable, mais c'est ainsi! Et comme mes compatriotes et moi avons été élevés dans cette mentalité de nous battre pour parler français, n'imagine que nous allons abandonner sur Wikipédia! Think about it and take care buddy! Émoticône --Antaya @ - 6 octobre 2007 à 19:32 (CEST)Répondre
Bonjour je passe par là par hasard. Il y avait eu un sondage sur la francisation du terme infobox qui avait conduit à le garder voir Wikipédia:Sondage/Traduire infobox ?. Mmmh peut-être en parler plus largement avant de le faire (moi personnellement ça m'est égal). De plus il me semble qu'il y a déjà des "fiches" pour certains projets qui bien sûr correspondent à autre chose. Tella bavarder 6 octobre 2007 à 20:00 (CEST)Répondre
Allez voir le sondage dont Tella donne le lien. Les arguments dans les "contre" sont recevables. Pas question que vous renommiez discretement les box en Fiche. Si vraiment vous voulez parler de Fiche, REFAITES un sondage et après on voit. Les résultats ne changeront guère. 53% contre, contre 35% pour, ce n'est pas insignifiant. La ou j'hallucine un peu,c 'est qu'il existe des pages d'aides pour "fiche", et d'autres page d'aides pour "infobox"... (http://fr.wikipedia.org/wiki/Aide:Infobox).
Bref je suis 100% contre à ces francisations en scred. A ce moment là, on va aussi franciser le HTML et le CSS ? Wikipédia en Wikipédie ? Non, il y a eu beaucoup de discussions et des concensus se sont dégagés. Respectez l'avis de la majorité, et si vraiment vous ne pouvez pas en dormir, relancez un sondage.
Et je persiste à dire, mon cher quebecquois, que tu veux tout franciser ;p. Non vraiment les quebecquois et les français ne seront probablement jamais daccord sur ce point là... ;)
A bientot JSDX 7 octobre 2007 à 16:56 (CEST)Répondre
Rien ne sert de grimper dans les rideaux le chat! Comme il est dit plus haut « La notion de fiche est donc au stade du prototype" : oui hélas ; donc pas de fiches dans les articles pour le moment ». Alors du calme, rien n'est fait encore mon piti-graphiste-préféré... Le terme à adopter n'apparaît même pas dans les articles, donc c'est assez secondaire! Moi je trouve qu'on fait du bon boulot, et c'est bien plus important l'apparence de l'Infobox que sa nomenclature. Au plaisir, Antaya @ - 7 octobre 2007 à 18:06 (CEST)Répondre
Héhé! T'inquiètes pas cher codeur je voulais juste t'embeter encore un peu avec la question de la francisation :D. Et puis 60 millions de français contre 9 millions de quebecquois.... Bien évidemment, l'apparence et le contenu d'une box est mille fois plus important :). Infoboxement, JSDX 7 octobre 2007 à 19:24 (CEST)Répondre

Plan de travail modifier

Dernier commentaire : il y a 16 ans3 commentaires3 participants à la discussion
  1. Deux carrés gris et deux carrés violets completer les recommandations
  2. les rendre consensuelles (en faire une page d'aide)
  3. créer les fiches (ou renommer et remanier)
  4. remplacer une à une les infoboxes par des fiches dans l'encyclopédie (les dresseurs de bot vont souffrir Émoticône sourire)

  <STyx @ 6 octobre 2007 à 18:48 (CEST)Répondre

Infobox (;p). JSDX 7 octobre 2007 à 19:49 (CEST)Répondre
Occupe-toi donc de l'atelier graphique et laisse-nous le projet modèle... petit coquin! Émoticône --Antaya @ - 7 octobre 2007 à 19:53 (CEST)Répondre

Bleurir les paramètres ? modifier

Dernier commentaire : il y a 16 ans3 commentaires3 participants à la discussion

Salut à vous

J'aimerai que l'on parle d'un point assez important niveau harmonisation. Ils ont pris une décision pour le projet Jeu Vidéo, pourquoi ne pas la prendre ailleurs également.

Voila sur un certain nombres de modèles, certains liens des paramètres (colonne de gauche) sont "bleuis". En général, pas tous, ce qui fait que c'est vraiment inesthétique. Ensuite l'utilité est plutot discutable (par exemple ici : Modèle:Infobox Musique (œuvre)). Si quelqu'un ne sais vraiment pas ce qu'est un label, ce qui doit représenter 1% des gens qui liront l'article, ils utilisent le champs rechercher à gauche et basta. Dernier argument et pas des moindres que j'ai pu lire, c'est que bleuir les noms des paramètres défocalise l'attention du lecteur qui devrait se concentrer uniquement sur la colonne de droite (la colonne de gauche n'est quasi pas lu au bout d'un petit moment, via automatisme).

Mais comme j'ai pas envie de me lancer dans une guerre d'édition sur certaines box, je me demande si on ne pouvait pas en discuter et si un consensus se dégage, inscrire le résultat dans les recommandations des infobox :). JSDX 8 octobre 2007 à 07:42 (CEST)Répondre

  • Pour mais c'est une question d'apparence (donc ne pas aborder cela ici ; mais dans "charte graphique")
  • la seule chose à dire est « une infobox doit utiliser class="infobox" »
  • ensuite il n'y a plus qu'à ajouter dans la (?) feuille de style quelque chose comme (à vérifier ; voir couleurs des liens — élément a) :
infobox TH A:link    { color: ... }    /* lien non-visité */
infobox TH A:visited { color: ... }   /* lien visité   */
infobox TH A:hover   { color: ... } /* lien survolé     */
infobox TH A:active  { color: ... }
  <STyx @ 8 octobre 2007 à 13:19 (CEST)Répondre
Je suis d'accord pour ne pas bleuir les liens (en fait ça ne m'importe pas, c'est une question de graphisme). Maintenant, la class="Infobox" est une horreur, et on ne devrait pas permettre cela! Les lignes séparatrices aloudissent le visuel et ça s'apparente plus à un tableau mathématique que d'une fiche-infobox. Mais encore là, c'est une question de graphisme, alors je ne m'en mêle pas!! Au plaisir, Antaya @ - 8 octobre 2007 à 21:16 (CEST)Répondre

Merci ! modifier

Dernier commentaire : il y a 16 ans4 commentaires3 participants à la discussion
Récompense Félicitations à tout les membres du projet Modèle, et plus particulièrement
ceux de l'« harmonisation » pour le travail abattu et leur motivation.
Merci à vous pour l'élan que ce projet m'a donné sur Wikipédia.
Paulokoko 猿渡樹 9 octobre 2007 à 17:37 (CEST)Répondre

Comme c'est mignon... un gros merci Paulokoko pour cette récompense de groupe! Franchement, c'est très gratifiant pour tous les modèleux! Au plaisir, Antaya @ - 9 octobre 2007 à 19:00 (CEST)Répondre

Hey y'a même un travail graphique (pourri ouai pbon ok je suis codeur pas graphiste), pour une barnstar unique :p --Paulokoko 猿渡樹 11 octobre 2007 à 09:40 (CEST)Répondre
Un grand Merci Émoticône ... tardif Émoticône.   <STyx @ 19 octobre 2007 à 20:03 (CEST)Répondre

Paramètres des acronymes modifier

Dernier commentaire : il y a 16 ans1 commentaire1 participant à la discussion

Salut! J'ai une question de paramètres. Quelqu'un m'a demandé d'améliorer l'{{Infobox Protéine}}, mais pour la traduction des paramètres je ne suis pas certain au niveau des acronymes : Discussion Modèle:Infobox Protéine. Comme par exemple "ATC_prefix" d'après l'harmonisation, est-ce que ATC peut devenir "prefix atc"?? Merci d'éclairer ma lanterne! --Antaya @ - 11 octobre 2007 à 18:09 (CEST)Répondre

Les questions de fond modifier

Dernier commentaire : il y a 15 ans28 commentaires9 participants à la discussion

« Premature optimization is the root of all evil (or at least most of it) in programming. »

— Donald Knuth

Cette discussion est en fait un mini sondage qui s'adresse au grand connaisseurs de WP et du logiciel MediaWiki. Si vous connaissez des liens sur le sujet, n'hésitez pas à les rajouter. Plus concrètement, ce sont des questions préliminaires à la conception d'une nouvelle génération d'infobox (voir Projet:Infobox/Fiche/Construction).

Cout des techniques modifier

La question générale est « Faut-il se préoccuper pour la programmation des modèles de la charge en calcul, mémoire, volume des données transférées ? ». Autrement dit « Faut-il optimiser ? » ; « Y-a-t-il risque de saturation ? »

En fait, il y a déjà des problèmes de saturation (de deadline ?) en géolocalisation à cause de l'absence des mathfunctions.

  1. ?   <STyx @ 13 octobre 2007 à 19:19 (CEST)Répondre
  2. La charge serveur est inhérente à l'amélioration des modèles.. Je veux dire par exemple, dans un système de "classes" pour les modèles, où on a des inclusions d'inclusions, qui sont là pour améliorer l'utilisation pour l'utilisateur lambda, il ya forcément une surcharge par rapport à un système wiki avec peu de modèles et des pages simples.. Enfin je sais pas si je répond à la question. Enfin oui je pense qu'on doit quand même y penser et éviter de trop compliquer les choses. --Paulokoko 猿渡樹 14 octobre 2007 à 22:13 (CEST)Répondre
  3. Non. Pour optimiser, il faudrait être en état de mesurer réellement ce qui coûte (avec un profiler). — Régis Lachaume ✍ 5 novembre 2007 à 18:52 (CET)Répondre
  4. Comme Régis : pour pouvoir optimiser, il faut profiler. Il me semble que l'avis de Brion Vibber sur ce genre de question a toujours été que c'était aux devs de s'adapter, pas aux utilisateurs. R 5 novembre 2007 à 23:24 (CET)Répondre
  5. Comme Régis et R. J'en profite pour dénoncer à nouveau la protection, (je dis bien la protection, pas la semi-protection) de certains modèles par certains admins, sur la base de pseudo-arguments techniques, alors que s'il y avait des problèmes techniques réels, Brion les aurait traités lui-même. Teofilo ◯ 9 novembre 2007 à 15:23 (CET)Répondre
  6. Entre les deux : 1) je ne suis pas persuadé que l'appel aux modèles soit spécialement pénalisant en termes de charges serveurs ; 2) en tous état de cause une amélioration ne peut se faire qu'à un niveau inférieur, celui du développement ; 3) limiter l'appel en cascade aux modèles ne résoudrait rien, s'il apparaît que la charge serveur est pénalisante : au lieu de faire un appel indirect à des fonctions on ferait un appel direct, mais ce qui coûte du temps et de la bande passante est l'appel aux fonctions, pas l'appel aux appels de fonctions. -O.M.H- ♦ ✉ ♦ -H.M.O- 11 novembre 2007 à 16:44 (CET)Répondre

Usage des styles (/class) thématiques modifier

Sortir le style du code wiki est une bonne chose. Cependant, cela ne va-t-il pas conduire à un gonflement démesuré des pages CSS ?

Exemples : les class « Charte... » dans Mediawiki:Common.css

  1. Après réflexions, je pense que c'est une bonne car rétroactivement cela limitera la personnalisation thématique des infobox.   <STyx @ 13 octobre 2007 à 19:19 (CEST)Répondre
  2. Les classes chartes ne sont pas là par véritable choix mais plutôt par défaut, mediawiki limitant l'usage au sein d'une syntaxe wiki l'utilisation de quelques styles CSS, notamment : "background-image:url" et "color:rbg(". Pour la couleur la limitation est faible, (seulement bloquée au sein des syntaxes de tableaux par exemple). Mais pour les background-image, utilisés pour les nouvelles infobox, il n'y a pas d'autre choix que de passer par des appel à des classes, l'inclusion en tant que style n'étant pas possible via la syntaxe wiki. De manière générale, et àmha, je suis de ceux qui sont pour limiter la sur-personnalisation des styles, les modèles ne devrait pas permettre de personnaliser sur une page (je sais pas si j'arrive à me faire comprendre :p). --Paulokoko 猿渡樹 14 octobre 2007 à 22:21 (CEST)Répondre
    Très clair. La personnalisation bonbon des modèles, enlève de la crédibilité aux articles. --Antaya @ - 17 octobre 2007 à 05:21 (CEST)Répondre
    Ouaip, en gros le modèle à un style, une charte (ou plusieures dans des cas spécifiques comme les infobox musique..), mais l'insertion du modèle sur une page doit-être le plus simple possible. Comme beaucoup d'infobox actuelles d'ailleurs. --Paulokoko 猿渡樹 17 octobre 2007 à 09:26 (CEST)Répondre
  3. Oui. Ça allège le modèle et en plus la difficulté d'accès au monobook aura pour effet de diminuer l'inuniformité (tain j'invente des mots) de la charte graphique. Franchement, certains articles avec navbar bariolées donnent une impression d'amateurisme préjudiciable au projet. — Régis Lachaume ✍ 5 novembre 2007 à 18:54 (CET)Répondre
    Aha ^^ Je pensais pas mais rire sur cette page de discussion (technique), mais en fait oui ^^ Merci Régis Émoticône. Dans le genre bariolé on pourrait demander des conseils à Manuguf (pour ceux qui avaient vu sa signature). --Paulokoko ⊂comptoir⊃ 9 novembre 2007 à 19:11 (CET)Répondre

Modèles génériques modifier

C'est la pratique de recherche des fonctions primitives ("recherche de généricité") dont le principe est : « rassembler les troncs communs dans des modèles génériques ». Faut-il limiter cette pratique ?

Cette pratique entraine l'utilisation d'un grand nombre de sous-modèles.

Exemples : {{Fiche}} et les méta-modèles en général

  1. en tous cas, à l'heure actuelle il faut chercher à la développer pour simplifier et harmoniser les modèles.   <STyx @ 13 octobre 2007 à 19:19 (CEST)Répondre
  2. Pour le coup ça rejoint un peu l'idée sur la charge serveur. C'ets le genre de pratique qui simplifie peut-être le boulot utilisateur mais qui alourdit la charge serveur. La question aussi est : si, imaginons, que pour un tel modèle, il s'avère qu'une erreur existe depuis longtemps, une modification même infime peut avoir de grosses répercussions... --Paulokoko 猿渡樹 14 octobre 2007 à 22:24 (CEST)Répondre
    Idem JSDX et aussi, de toutes manières et si cette technique de "super-classes" (en développement orienté objet.. on pourrait parler ici de super-modèle) n'est pas conseillée, on peut en tout cas définir et recommander des techniques de codage et des pratiques. --Paulokoko 猿渡樹 14 octobre 2007 à 22:26 (CEST)Répondre
  3. oui lorsque ça conduit à du code plus simple. Et puis qu'en savez-vous de la charge serveur (il me semble que les modèles sont précalculés) ? Peut-on optimiser sans savoir ce qu'il faut optimiser ? N'est-ce pas plutôt à MediaWiki de s'adapter aux usages ? — Régis Lachaume ✍ 5 novembre 2007 à 18:56 (CET)Répondre
  4. Pour la charge serveur, il me semble que l'usage des méta-modèles est parfaitement neutre (à condition toutefois de ne pas inclure en cascade 12 modèles avec 50 ko de documentation chacun), voire favorable si l'on compare le cas où l'on modifie un méta-modèle inclus dans 1000 modèles au fait de modifier individuellement les 1000 modèles. Les avantages des méta-modèles en termes d'harmonisation et de simplicité d'usage sont par contre clairs et justifient largement leur généralisation. R 5 novembre 2007 à 23:45 (CET)Répondre
la mise en cascade de modèles est déjà limitée par le serveur. J'en ai déjà fait l'expérience sur le Bistro, avant l'appartion des parser-functions qui ont permi de bien simplifier la syntaxe. En gros, lorsque tu mets trop de modèles en cascade (je ne sais plus exactement combien c'était : une cinquantaine ?) un message d'erreur apparait et la page ne se charge plus entièrement. Donc tant que ce message n'apparait pas, on sait qu'on est dans la limite de ce que souhaite Brion. Teofilo ◯ 9 novembre 2007 à 15:33 (CET)Répondre

Pratique du « tout en un » modifier

La pratique du « tout en un » ; c'est à dire « un seul modèle pour tous les cas de figure (même les plus singuliers) » est-elle souhaitable ?

Cette pratique crée des modèles qui ont un grand nombre de paramètres souvent inemployés.

Exemples de tels modèles : {{BUtilisateur}} • Projet:Modèle/Fiche ville • {{Coord}} (dans une moindre mesure)

  1. plutôt contre : Car contraire à la Projet:Modèle/Harmonisation#Conception des méta-modèles. Ces modèles sont trop souvent remaniés  : ajout de paramètres, prise en compte de nouvelles particularités, et ... rectification des bugs (car ces modèles sont si complexes que les erreurs de syntaxe reviennent sans cesse). {{BUtilisateur}} en particulier est un excès. Je préféré un modèle simplifié pour le cas général et souhaitable ; des modèles (déconseillés) pour les singularités.   <STyx @ 13 octobre 2007 à 19:19 (CEST)Répondre
  2. plutôt pour, surtout à la vue des Chimiebox (une dizaine de modèle pour une infobox !). Plus pratique pour les contributeurs que d'allez chercher différents modèles selon le cas. Par exemple, je serais plutôt pour la fusion des infobox pour les personnes (qu'il soit acteur, roi ou homme politique). VIGNERON * discut. 5 novembre 2007 à 18:30 (CET)Répondre
  3. plutôt pour dans la mesure où ça centralise le codage et évite des corrections sur n modèles lorsqu'on décide de changer une virgule. À mon avis {{ouvrage}} ou {{périodique}} sont de bons exemples. Mais il ne faut pas que ça se fasse aux dépens de la facilité de codage avec des millions de {{#if}} qui s'emboîtent les uns les autres. — Régis Lachaume ✍ 5 novembre 2007 à 18:58 (CET)Répondre

Imbrication des modèles modifier

Les deux pratiques précédentes entrainent un gonflement de la liste des (sous-)modèles dans les articles. Faut-il s'en préoccupper ?

  1. non (secondaire) au moins dans une premier temps.   <STyx @ 13 octobre 2007 à 19:19 (CEST)Répondre
  2. bof, il ne faut pas l'oublier mais ce n'est pas le plus important. VIGNERON * discut. 5 novembre 2007 à 18:32 (CET)Répondre

Technique d'intégration de la documentation modifier

Cela consiste, pour un méta-modèle, à intégrer également la documentation du modèle dérivé (qui l'emploie). Ce modèle dérivé est donc (quasiment) automatiquement documenté. Peut-on employer librement ce procédé ?

Exemple : {{Méta bandeau licence}} (voir {{GFDL}}) • {{Méta utilisateur}} (voir {{Utilisateur Projet/Géopolitique}}) • (voir aussi Catégorie:Modèle de documentation)

  1. Pour   <STyx @ 13 octobre 2007 à 19:19 (CEST)Répondre
  2. Gné ? Inclure la doc d'un autre modèle ? Pourquoi ne pas indiquer simplement « sous modèle de {{bla}}. » ?— Régis Lachaume ✍ 5 novembre 2007 à 19:00 (CET)Répondre
  3. J'ai mis du temps avant de comprendre comment fonctionnais le machin, et je trouve ça inutilement compliqué pour un résultat qui peut être trompeur. R 6 novembre 2007 à 04:26 (CET)Répondre

Bandeau de disharmonie modifier

Existe-t-il un bandeau indiquant qu'un article s'écarte d'une convention quelconque (charte graphique, convention d'écriture, "règles" de projet).

Sinon, pourrait-on avoir quelque chose comme:

L'affichage des XYZ ne correspondent pas/plus aux recommandations de UVW.

Le but serait d'indiquer à tout ceux qui voient l'article que cette page mérite d'être corrigée suite à une dérive (censée ne pas être du vandalisme) ou à une méconnaissance ou une interprétation erronée des règles qui sont nombreuses dans WP (et de surcroît les articles peuvent appartenir à plusieurs projets ayant leurs propres conventions).

-- SerSpock à l'inter...もしもし 20 février 2008 à 13:18 (CET)Répondre

  • En fait, ce ne sont pas les articles qui sont en cause ici, mais les modèles. Le moyen le meilleur (amha) de corriger un mauvais modèle est d'en créer un nouveau plus conforme et de marquer le premier avec {{Modèle obsolète}}
  • Ensuite pour « indiquer à tout ceux qui voient l'article que cette page mérite d'être corrigée », je préfère la catégorisation car c'est automatique, et plus discret. Voir Catégorie:Page utilisant un modèle obsolète
  • amha, WP est déjà trop envahi par les bandeaux. Cela tend à déléguer à d'autres le travail à faire. Bref, c'est plutôt nuisible.
  • donc plutôt contre même dans les modèles.   <STyx @ 29 août 2008 à 16:02 (CEST)Répondre

Gestion des paramètres manquants modifier

Dernier commentaire : il y a 15 ans5 commentaires2 participants à la discussion

Ma solution a long terme est d'employer le méta-modèle {{Fiche/Ligne facultative}}   <STyx @ 29 août 2008 à 16:03 (CEST)Répondre

{{#if ... modifier

La technique du {{#if est très lourde, chaque |- doit être encodé avec des {{!-}} etc., par contre elle à l'avantage de ne pas générer de html inutile. Ce html qui est généré par la technique hiddenStructure est gênant pour certains moteurs de recherche, par exemple Yahoo: géologie Île de la Possession site:fr.wikipedia.org retourne comme résultat Île de la Possession alors que le mot géologie n'apparaît ni sur la page ni dans le wikitext. - phe 12 avril 2008 à 11:31 (CEST)Répondre

oui, ce procédé est préférable, mais avec les balises HTML (et non avec du code wiki + modèle {{!-}} etc. - quelle horreur) --- c'est l'objet de la recommandation "Tableau"   <STyx @ 29 août 2008 à 16:03 (CEST)Répondre

hiddenStructure modifier

La technique décrite ne doit pas être utilisé class="{{{param|hiddenStructure}}}" à la place il faut utiliser |- {{#if:{{{param|}}}||class="hiddenStructure"}}. Le problème de la méthode actuellement préconisé est que param peut contenir une chaîne arbitraire de caractères donc des noms de classes définit dans les .js ou .css, par exemple {{foo|param=ceci est un entete}} donnera les classes "ceci", "est", "un" et "entete", d'ou des résultats imprévisible. - phe 12 avril 2008 à 11:31 (CEST)Répondre

oui, c'est un argument de plus contre ce procédé. Ma formulation n'est sans doute pas assez ferme. Le procédé est à proscrire !   <STyx @ 29 août 2008 à 15:33 (CEST)Répondre

Valeur des paramètres modifier

Dernier commentaire : il y a 15 ans5 commentaires2 participants à la discussion

La recommandation de toujours formater les paramètres dans les modèles ne va pas, pour les infobox par exemple elle force la création de modèle inflexible ou tout ce qui n'a pas été prévu dans l'infobox ne peut être exprimé ou bien doit demander une modification de l'infobox, un exemple typique est le paramètre pays de bon nombre d'infobox où l'on ne peut plus tout simplement utilisé pays = [[Royaume-Uni]]<br />[[Chili]]<br />[[Argentine]] mais où il faut à la place alourdir l'infobox avec 3 paramètres pays différent.

Un autre exemple est localisation ou l'on doit pouvoir formater librement la localisation dans l'article, voir Sakhaline pour une utilisation de localisation. Par contre pour les paramètres numérique pourquoi pas : formatnum: a été prévu pour fonctionner même si la chaîne n'est pas numérique donc on peut quand même passer des params non numérique.

Le calcul automatique de la densité comme avantage est un mauvais exemple, il n'est jamais utilisé et ne le sera pas avant que quelqu'un n'ait le temps de s'attaquer au modèle qui fera le calcul correctement et non pas par un simple{{{population}}}/{{{superficie}}} tel qu'indiqué en exemple dans cette section.

hein ?!   <STyx @ 29 août 2008 à 23:54 (CEST)Répondre

L'harmonisation ne doit pas prendre le pas sur la flexibilité d'utilisation des modèles. - phe 12 avril 2008 à 11:58 (CEST)Répondre

Certes ; mais « la flexibilité d'utilisation des modèles » est ambigu. Il y a « la flexibilité de renseignement des modèles » et « la flexibilité d'utilisation des paramètres par les modèles ». Il y a un compromis à faire entre les deux.   <STyx @ 29 août 2008 à 23:54 (CEST)Répondre

pays modifier

Dernier commentaire : il y a 15 ans6 commentaires2 participants à la discussion

Même problème que ci-dessus, manque de flexibilité et force l'utilisation d'un drapeau - phe 12 avril 2008 à 12:07 (CEST)Répondre

  • « force l'utilisation d'un drapeau » : ben non justement
  • « manque de flexibilité » : simple bon sens (un pays est ... un pays), et cela rend la donnée exploitable   <STyx @ 29 août 2008 à 16:07 (CEST)Répondre
C'est pourtant ce que dit la page : « La valeur du paramètre pays doit être un simple nom de pays (pas de lien) dont le nom est recensé dans Catégorie:Modèle pays et drapeau. » et les infobox lient bien le paramètre avec {{}}, exemple Modèle:Infobox Volcan et la partie motivation indique que c'est pour pouvoir afficher le drapeau. - phe 29 août 2008 à 16:33 (CEST)Répondre

La recommandation force la création de modèle inflexible ou tout ce qui n'a pas été prévu dans l'infobox ne peut être exprimé ou bien doit demander une modification de l'infobox, un exemple typique est le paramètre pays de bon nombre d'infobox où l'on ne peut plus tout simplement utilisé pays = [[Royaume-Uni]]<br />[[Chili]]<br />[[Argentine]] mais où il faut à la place alourdir l'infobox avec 3 paramètres pays différent. - phe 12 avril 2008 à 11:58 (CEST)Répondre

Fiche modifier

Dernier commentaire : il y a 15 ans2 commentaires2 participants à la discussion

Cette section mélange la notion de présentation et de méta-données en tentant la convergence des infobox vers les métas-données. C'est une erreur de design de tenter de tout faire à la fois par infobox, une infoxbox présente des données, les modèles de type {{Métadonnées personne}} sont totalement différents, mélanger les deux ne peut que donner une usine à gaz. Cette méthode à pourtant été utilisé avec succès pour les taxobox mais l'approche était très différente, une taxobox par information, et un sujet bien défini, il y a a beaucoup moins de variabilité entre la description scientifique d'un animal et, par exemple, la variabilité des informations biographiques nécessaires suivant la personne. - phe 12 avril 2008 à 12:40 (CEST)Répondre

Tableau modifier

Dernier commentaire : il y a 15 ans4 commentaires2 participants à la discussion

« Il faut toujours employer la syntaxe HTML pour la construction de tableaux dans les modèles. » Ceci est faux ou très mal dit. - phe 12 avril 2008 à 16:09 (CEST)Répondre

  • C'est une recommandation, pas une vérité (encore moins un état des choses, malheureusement)
  • mal dit ?
  • En définitive, la bonne solution en d'encapsuler la syntaxe HTML dans des méta-modèles (comme les "Début ..." "Fin ...") et construire les modèles à la manière de {{Fiche Ville}} (voir son code)   <STyx @ 29 août 2008 à 15:27 (CEST)Répondre
Il existe une syntaxe wiki pour les tableaux, pourquoi utiliser du html ? - phe 29 août 2008 à 16:37 (CEST)Répondre
c'est dit dans "Motivation"   <STyx @ 29 août 2008 à 21:51 (CEST)Répondre

Méta-modèles modifier

Dernier commentaire : il y a 15 ans2 commentaires2 participants à la discussion

Comment prouver quelque chose pour démontrer le contraire : « En revanche, la modification des modèles les plus usuels est couteuse pour le serveur, il est donc recommandé d'agir alors avec circonspection. » et arriver à la conclusion qu'il faut créer des métas-modèles qui seront massivement utilisés, comment est-ce possible ? - phe 12 avril 2008 à 16:24 (CEST)Répondre

Pratique de « recherche des tronc communs » modifier

Dernier commentaire : il y a 15 ans2 commentaires2 participants à la discussion

L'exemple des chimiebox est assez éclairant, à rapprocher des taxobox. Avec ce type de modèle aucune complication, inutile de tester péniblement dans le modèle des tas de conditions pour savoir s'il faut afficher ceci ou cela, calculer ce truc, un simple macro remplacement sans exécution conditionnelle. On ne sait trop comment un modèle très complexe faisant tout cela à la fois serait plus efficace ? - phe 12 avril 2008 à 16:34 (CEST)Répondre

C'est plus un question de simplicité d'écriture (et de maintenance) que d'efficacité.   <STyx @ 29 août 2008 à 22:22 (CEST)Répondre

Vers une hiérarchie de classes modifier

Dernier commentaire : il y a 15 ans2 commentaires2 participants à la discussion

Il y a une confusion dans cette section entre réutilisation de code et héritage. On pourrait faire, peut être, de l'héritage avec les modèles. Après tout l'orientation objet n'est pas une caractéristique intrinsèque d'un langage mais il ne faut pas sous-estimer la difficulté d'implémentation et avec ce qui est disponible ce n'est même pas la peine d'essayer. Réutiliser du code, d'accord, mais évitons les buzz words comme héritage ou orienté objet, avec un langage qui n'est guère plus qu'un macro remplacement de texte avec quelques capacités maladroites de remplacement conditionnelles, ce n'est pas jouable. - phe 12 avril 2008 à 16:49 (CEST)Répondre

disons que la hiérarchie de classes sera plus conceptuelle que effective ; mais elle est naturelle pour les infoboxes.   <STyx @ 29 août 2008 à 21:48 (CEST)Répondre

latitude et longitude modifier

Dernier commentaire : il y a 15 ans3 commentaires2 participants à la discussion

Cette exemple est mal choisi, il n'y a guère d'avenir au formatage des coordonnées dans les infobox, on se dirige plutôt vers le formatage via {{coord}} dans les articles (avec un paramètre coordonnées = {{coord|....}} par exemple). C'est la seule façon sure de taguer correctement les articles avec les labels, le facteur d'échelle et surtout l'importance relative du lieu qui va bien pour la génération des données de localisation utilisé par le miniatlas. - phe 14 avril 2008 à 22:05 (CEST)Répondre

N.B. on pourrait formater dans l'infobox, mais on va se retrouver avec des tas de paramètres pour la géolocalisation automatique (type, scale, les coordonnées elle même (entre deux et huit paramètres suivant le format choisi) etc. - phe 17 avril 2008 à 12:27 (CEST)Répondre

Ni l'un ni l'autre, les paramètres type, scale, ... sont fixés dans le modèle et suivant ce modèle.   <STyx @ 29 août 2008 à 21:44 (CEST)Répondre

Souplesse modifier

Dernier commentaire : il y a 14 ans4 commentaires3 participants à la discussion

La technique des champs libres n'a encore jamais été utilisé, il faut l'envisager. Elle consiste a permettre de spécifier un libellé et la valeur associé à ce libellé, ce n'est pas plus lourd à coder que les paramètres optionnels mais un peu plus lourd à utiliser. Ce n'est pas tout à fait encore assez flexible car on ne peut pas spécifier la position d'insertion de la ligne de code dans l'infobox.

Dans l'infobox 

{{#if: {{{libellé1|}}} |
{{!-}}
! {{{libellé1}}} 
{{!}} {{{valeur1}}} }}

- phe 17 avril 2008 à 13:07 (CEST)Répondre

je suis même favorable a un paramètre (disons extra) "adlib". Par exemple dans l'article :
|extra={{Fiche/Point culminant|1678}}
ou dans un modèle dérivé :
|extra={{Fiche/Point culminant|{{{point culminant|}}}}}
{{Fiche/Ligne facultative|Climat|{{{climat|}}}}}
et à la rigueur (dans l'article)
|extra={{Fiche/Ligne|Climat|blablabla}}
 {{Fiche/Ligne|Végétation|blablabla}}


« on ne peut pas spécifier la position d'insertion de la ligne de code dans l'infobox. » : oui, cela est embêtant ; je ne vois pas de solutions satisfaisantes :(   <STyx @ 30 août 2008 à 00:11 (CEST)Répondre
Si je vous ai bien compris Phe dans cette technique, le libellé(x) qui correspond en fait à un paramètre(x) est laissé dans son interprétation (dénomination du champ à renseigner) à la discrétion de l'utilisateur qui mettra en inclusion le modèle dans l'article. Dans le cas des infobox sans parler des taxobox ceci est formellement à proscrire. En effet, chaque libellé ou paramètre fait l'objet de débats et de définition précise quant à la dénomination. Il suffit, par exemple, de jeter un oeil du coté des discussions autour des modèles d'infobox biographiques et des projets concernés pour s'en rendre compte.
D'autres part, même si l'on défini précisément une liste de paramètres dans la page de documentation du modèle, les utilisateurs qui pour la plupart ne sont pas informaticien auraient beaucoup de difficulté à inclure le modèle dans l'article. C'est déjà vrai par copié-collé avec des infobox toute simple qui pose des problèmes à certains utilisateurs. GLec (d) 18 avril 2009 à 08:23 (CEST)Répondre
Il ne s'agit pas de mettre n'importe quoi. « les utilisateurs qui pour la plupart ne sont pas informaticien » sauront se débrouiller si on les guident avec une assistance. Voir Projet:Infobox/Fiche/Exemples.   <STyx @ (en long break) 27 juin 2009 à 15:04 (CEST)Répondre

2 modèles V2 incompatibles modifier

Dernier commentaire : il y a 14 ans1 commentaire1 participant à la discussion

Bonjour, je voudrais signaler à votre attention deux modèles « V2 » aux champs incompatibles :

  1. Modèle:Infobox Maison d'édition
  2. Modèle:Infobox maison d'édition

Moi je vais utiliser le premier parce qu'il a une documentation et l'autre non, mais le second est encore utilisé sur 2 pages importantes (Presses de Sciences Po et HarperCollins, c'est pour ça que je suis tombé dessus en regardant comment on faisait sur des articles bien écrits). Il faudrait sûrement convertir ces deux pages de #2 vers #1 puis changer #2 en REDIRECT vers #1 ou quelque chose comme ça... 62.147.62.157 (d) 2 novembre 2009 à 21:05 (CET)Répondre

Modèle image annotée modifier

Dernier commentaire : il y a 14 ans3 commentaires2 participants à la discussion

Bonjour,

en:Template:Annotated image et en:Template:Annotation sont deux modèles liés. Même s'ils sont plûtot réservé à des experts, ils me semblent interessants pour les images, car cela permet d'utiliser la même image pour toutes les langues tout en ayant des zones clicables et des textes variables au dessus de l'image.

Je n'ai pas trouvé de modèle similaire ici, alors malgré mon allergie aux {{{{{{{{{{{{}}}}}}}}}}}}, j'ai commencé à jouer avec. Avant de me mettre à traduire les noms/paramètres et la documentation, je voudrais valider les éléments avec vous avec vous :

Objets à créer :

[[Fichier:{{{image}}}|300px|alt=|{{{caption}}}]]

{{{annotations}}}

[[Fichier:{{{image}}}|300px|frameless|alt=]]
{{{caption}}}

,

{{{3}}}

et Catégorie:Modèles graphiques

Pramètres : (en > fr) 

caption                 légende
alt 	                alt
image 	                image
imagemap 	        imagemap (?)
width 	                largeur
height                  hauteur
image-left 	        image-gauche
image-top 	        image-droite
image-width 	        image-largeur
annotations 	        annotations
float 	                float
outer-css 	        contour-css
image-bg-color          image-fond-couleur
image-css 	        image-css
annot-text-align 	annot-texte-alignement
annot-background-color  annot-fond-couleur
annot-font-family 	annot-police-famille
annot-font-size 	annot-police-taille
annot-font-weight 	annot-police-graisse (?)
annot-font-style 	annot-police-style
annot-line-height 	annot-police-hauteur
annot-font-family 	annot-police-famille
annot-color             annot-couleur

Merci de votre « feed back ». --Anneyh (d) 9 janvier 2010 à 13:38 (CET)Répondre

Bonjour,
La lecture de Aide:Tutoriel de création d'images complétées, mais aussi de Combinaisons d'images via CSS vous sera sans doute utile. Cordialement, --Temesis (d) 9 janvier 2010 à 14:14 (CET)Répondre
Bonjour, merci pour ces indications... en l'attente de plus de réactions, je vais utiliser ce qui existe. L'un des buts de
[[Fichier:{{{image}}}|300px|alt=|{{{caption}}}]]

{{{annotations}}}

[[Fichier:{{{image}}}|300px|frameless|alt=]]
{{{caption}}}

est qu'il gère les

et il pourrait sans doute faire plus pour l'accessibilité.
{{{3}}}
pourrait éviter de convertir les coordonnées en (y,x) (alors que pour l'images cliquables c'est dans le bon sens). Je vais aller voir où ils en sont sur l'accessibilité sur wp:en.
Pour mon cas particulier, j'ai commencé à soigner le texte alt de l'image pour inclure le texte surajouté, et il me reste a mettre tous les liens dans l'image cliquable. --Anneyh (d) 9 janvier 2010 à 17:28 (CET)Répondre

Terminologie "Revenu" sur Infobox Site Web modifier

Dernier commentaire : il y a 12 ans1 commentaire1 participant à la discussion

Bonjour, L'infobox Modèle:Site web contient un libellé "Revenu" qui me semble être une erreur : pour les sociétés, on parle de Chiffre d'Affaires (équivalent de l'anglais Revenue, ou de Résultat. Je pense qu'un changement est souhaitable. Quelle est la procédure à suivre? Appel à discussion du portail entreprise ici? Sur leur portail? Ailleurs? Merci de m'aiguiller. Cordialement, Deuxtroy (d) 31 janvier 2012 à 10:43 (CET)Répondre

Géolocalisation modifier

Dernier commentaire : il y a 10 ans1 commentaire1 participant à la discussion

J'ai pour habitude de mettre dans les Infox la géolocalisation dans l'ordre : Ville/Département/Région/Pays. Je fais ce choix car je pense que, quand on cherche un édifice, on cherche d'abord à savoir où il est situé dans son environnement le plus proche.
Pour certains, il semblerait que la logique soit inverse, sans que j'en connaisse bien la raison. J'ai essayé de savoir si ce point de vue se retrouvait dans Wikipédia en anglais. Sur les quelques fiches que j'ai consultées, j'ai constaté que l'approché était la même que la mienne. Peut-être que mon point de vue mérite d'être compris car il ne me paraît pas absurde. Cordialement--MOSSOT (discuter) 2 mars 2014 à 11:26 (CET)Répondre

Liste des paramètres problématiques modifier

Dernier commentaire : il y a 3 mois8 commentaires3 participants à la discussion

Bonjour

Je viens de faire une liste des modèles avec des paramètres problématiques (présence de tirets bas, de traits d'union, de points, de majuscules, de sigles en lettres capitales) : Projet:Modèle/Harmonisation/Liste de modèles avec des paramètres problématiques

Ces listes ne sont pas parfaites, j'ai fait ça vite avec des regexes simples, donc il y a sûrement des faux-positifs (notamment avec les traits d'union dans des mots composés) et des faux-négatifs, mais ça permet quand même de travailler.

En gros, on a 2716 modèles dont 977 infoboxes.

Après coup, je me demande si c'est bien utile, comme quasiment personne ne corrige ça, que ce sont des modifs qui ne changent pas l'apparence des articles (donc pas vraiment autorisées à faire par bot), que ça ne gêne pas plus que ça les contributeurs (même si ça crée un peu d'erreurs dans les paramètres, mais ce n'est pas la cause de la plupart des cas), et que surtout, des modèles avec de tels paramètres sont créés tous les jours, souvent par copie de modèles existants, pour rester dans la ligne des modèles précédents quand ce sont des modèles qui se répètent d'année en année.

Ça serait quand même bien de faire quelque chose, mais c'est plutôt en 2005 qu'il aurait fallu établir des règles, parce que là, ce sont de milliers de modèles qui ont ce genre de paramètres.

Un problème particulier est celui des modèles très utilisés, car ils sont parfois ajoutés avec des outils, et sans corriger tous ces outils, on ne peut pas résoudre le problème, ou bien on va se retrouver avec plein de modèles qui ne marchent pas car leurs paramètres n'existent plus.

Une chose à faire serait de vérifier les nouveaux modèles, comme ça on peut faire des corrections avant qu'ils ne soient placés sur des milliers d'articles, mais ça demande un travail continu.

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 17 janvier 2024 à 11:01 (CET)Répondre

Merci SyntaxTerror Émoticône !
Liste très intéressante, surtout pour ceux qui cherchent du boulot Émoticône.
Il y a en effet des faux positifs, par exemple, et al. dans {{Article encyclopédique}} et énormément de sigles dans la dernière liste.
Idéalement, il faudrait ignorer les alias. Par exemple, j'ai harmonisé {{Élu}}, donc à part faire passer un bot, il n'y a plus rien à faire.
Il faudrait aussi exclure dans la recherche les bacs à sable et les documentations.
Ainsi que tout ce qui est entre balises <NOINCLUDE>, ce qui éviterait les faux positifs comme dans {{Bot stop}} ou {{Chronologie de l'Océanie}}.
Sinon, il y a des modèles à harmoniser très facilement, par exemple {{Campagne de Monteverde}} qui ne contient qu'un seul paramètre non utilisé ! Idem pour le paramètre Alt de {{Carte cliquable de la région de Trenčín}}.
Il est donc possible de réduire pas mal cette liste, même s'il en restera beaucoup...
--FDo64 (discuter) 17 janvier 2024 à 15:03 (CET)Répondre
@FDo64 : il est marqué qu'il ne faut pas mettre de points aux abréviations [1], donc ce devrait être et al si on cherche la petite bête Émoticône.
Pour les bacs à sable, je ne sais pas comment ça marche, est-ce qu'un robot les met à jour périodiquement, ou restent-ils en l'état ?
Sinon, je vais peut-être piquer au hasard une infobox ou un modèle pas trop utilisé de temps en temps si je m'ennuie, et corriger les paramètres fautifs avec mon bot. Je viens de découvrir les trouver et remplacer complexes dans AWB, ça permet de remplacer facilement les paramètres dans des modèles qu'on définit, comme ça pas de danger de glisser dans les paramètres identiques d'un autre modèle.
J'avais demandé une regex pour faire ça sur StackExchange, mais personne n'avait réussi à concocter quelque chose de vraiment efficace. D'ailleurs, AWB a des problèmes avec certaines regexes, je ne comprends pas pourquoi, mais certaines ne marchent pas, alors qu'elles sont similaires à d'autres qui m)archent (et je teste tout sur regex101 en flavour .NET avant).
Faire ce genre de trucs est des modifs cosmétiques, mais c'est plus utile que de corriger des double espaces ou des redirections, et j'ai remarqué plein de bots qui font des modifs beaucoup plus cosmétiques que ça.
Si jamais je me fais choper, je les balance et les entraine dans ma chute. Smiley avec le masque d'Hannibal Lecter (psychopathe) Şÿℵדαχ₮ɘɼɾ๏ʁ 17 janvier 2024 à 17:41 (CET)Répondre
J'ai retiré les documentations et les bacs à sable, il reste quelques /test et /brouillon mais je ne suis pas sur de leur contenu. Şÿℵדαχ₮ɘɼɾ๏ʁ 17 janvier 2024 à 19:15 (CET)Répondre
Merci SyntaxTerror Émoticône pour ta réponse.
Les /Test sont également à ignorer.
Et pour ce qui est de {{Infobox Livre/Brouillon}}, c'est une erreur de Notification Patangel qui aurait du utiliser le bac à sable. C'est donc à supprimer.
Sinon, cette liste est figée ou elle sera regénérée régulièrement ? Si elle est figée, j'enlèverai à l'occasion des faux-positifs.
--FDo64 (discuter) 18 janvier 2024 à 22:43 (CET)Répondre
@FDo64 : c'est une liste figée, je l'ai faite avec le database scanner d'AWB sur le dump du 1er janvier 2024.
Je ne pense pas qu'enlever les faux positifs soit vraiment nécessaire
D'une, cette liste n'est pas destinée à être utilisée par un bot, c'est juste pour piquer dedans des modèles à traiter au cas par cas, et on voit vite les faux-positifs.
De deux, si jamais on refait une nouvelle version avec la même méthode, tout le travail de tri manuel sera rendu inutile, et on ne pourra pas comparer les deux listes, et par exemple avoir les nouveaux modèles et ceux qui ont été retirés.
D'ailleurs, j'aurais du mettre les regexes utilisées, pour pouvoir refaire la même chose , ou que quelqu'un de plus compétent en donne de meilleures.
Si l'on veut utiliser son temps de manière positive, il faut mieux travailler à éliminer les paramètres fautifs, ce boulot en lui-même ne sera probablement jamais fini.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 19 janvier 2024 à 02:16 (CET)Répondre
Bonjour SyntaxTerror. Dans la liste, il y a des modèles pour lesquels les paramètres aux noms problématiques sont déjà devenus des alias d'autres paramètres (correctement nommés). Pour une activité non intrusive, au fil de l'eau, des bots existants, il pourrait être utile de lister les remplacements de paramètres recommandés. Par exemple, pour le modèle:Infobox Match de football : équipe_1 → équipe1 ; équipe_2 → équipe2 ; score_mi-temps → score mi-temps ; score_90min → score 90min ; score_tab → score tab ; homme_du_match → homme du match ; femme_du_match → femme du match
Idem pour modèle:Infobox Temple de la renommée pour lesquels les paramètres sans majuscule ont été intégrés au modèle, les alias avec majuscule, toujours valides étant encore très présents dans les articles.
Suggestion de travail mutualisé. L'intégration aux divers bots actifs, surtout pour les modèles très utilisés, permettrait de gagner en efficacité, sans augmenter artificiellement les éditions de pages (modifications cosmétiques). Bien entendu, les bots doivent gérer le respect des mises en forme (indentations des paramètres).
Une telle liste pourrait aussi sensibiliser les rédacteurs/relecteurs à employer les paramètres principaux plutôt que les alias mal nommés. — Ideawipik (discuter) 21 janvier 2024 à 15:09 (CET)Répondre
@Ideawipik : je n'ai jamais dit que cette liste ne comprenait pas des alias corrects, ce sont (plus ou moins) tous ceux avec des paramètres problématiques.
Quant à compter sur un remplacement « au fil de l'eau » de toutes les occurrences, il ne faut pas trop y compter. Certains articles ne sont jamais touchés par les bots.
On pourrait faire un équivalent de Wikipédia:AutoWikiBrowser/Template redirects, qui permet de remplacer les redirections de modèles si la fonction d'AWB Apply general fixes est utilisée (à ce que je sais, ça n'a jamais permis de supprimer une seule redirection de modèle, trop peu utilisent AWB, et encore moins cette fonction).
Mais pour que ça marche, pour AWB il faudrait demander une nouvelle fonctionnalité (c'est pas gagné), et pour les autres bots, il faudrait qu'ils puissent comprendre la page, ce qui peut être compliqué avec les différents langages de programmation utilisés.
Si l'on veut vraiment régler ça, il faudra faire des passages sur toutes les transclusions des modèle qui posent problème.
Mais même si le lecteur ne voit pas de différence, renommer des paramètres est utile. Si en plus on fait des corrections mineures comme celles d'AWB (qui ne sont d'ailleurs pas toutes cosmétiques), tout ça améliore le code et facilite la maintenance et les éditions futures. Şÿℵדαχ₮ɘɼɾ๏ʁ 21 janvier 2024 à 17:23 (CET)Répondre
Ajouter un sujet
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Discussion_Projet:Modèle/Harmonisation&oldid=211722739 ».
Revenir à la page « Modèle/Harmonisation ».