FANDOM


Cette page a pour but de définir des normes (une charte) pour les modèles en vue d'une campagne d'harmonisation des modèles (des infoboxes plus particulièrement). Il ne s'agit pas ici de juger des apparences des modèles (cela concerne plutôt, la charte graphique et la gestion des styles CSS), mais d'harmonisation des titres, du paramétrage, des techniques de codage, du jargon, des méta-modèles, des infoboxes...

Actuellement, l'on procède par petites retouches (ce qui multiplie les interventions de bots), sans coordination, et pas toujours dans le bon sens. Ce travail devrait aboutir à la création d'un standard (une sorte de label de qualité et de conformité) ce qui permettra une harmonisation plus efficace. Concernant les infoboxes, voir modèle de fiche.

Curly Brackets
Modèle
Aide et syntaxeFAQ
ListeModèles spéciaux
Aide:Modèles courants
ParserFunctionMots magiques
Espace Modèle
Projets
Demander un modèle
ModèleApparence
Projet d’harmonisation
Palette de navigation
{{Méta palette de navigation}}
Palette de navigation
Infobox
Demander une infobox
Apparence
Modèle infobox
Projet infobox
Projet d’amélioration

TitreModifier

Les noms (titres) de modèles obéissent aux conventions générales sur les titres. Il existe de plus une convention de titre de l'infobox particulière. À ce titre, les palettes de navigation en bas des pages obéiront à la même convention des titres que les Infoboxes; par exemple {{Palette Nom de la palette}}

Évitons ici de reformuler toutes ces conventions. On se borne ici à mettre le doigt sur certains "mauvais plis" et à rectifier certains points :

Titre des catégoriesModifier

On ne supprimera pas les mots de liaison dans les titres de catégorie.
Le titre d'une sous-catégorie de Catégorie:Espace Modèle doit commencer par le mot "Modèle".

Note : Ces conventions induisent de nombreux "renommages". Par exemple :

Sous-pagesModifier

Le (sous-)titre d'une sous-page doit commencer par une majuscule. On mettra donc toujours une majuscule après le "/".

Note : Cela contredit « On ne mettra pas de majuscule après le / » qui n'était pas du tout conforme à l'usage général.

Usage des mots de liaisonModifier

Toute ablation d'un mot de liaison dans le titre d'un modèle doit être marquée par une majuscule. Par exemple, "Infobox de ville" ou "Infobox Ville" ; mais pas "Infobox ville".
Lorsqu'un modèle appartient à un jeu (un modèle d'infobox, par exemple), il est fortement recommandé, pour des raisons fonctionnelles, d'omettre les mots de liaison.
Note : Cela contredit « On ne supprimera pas les mots de liaison : {{Infobox Province du Maroc}} et non {{Infobox Province Maroc}} ». Noter l'incohérence ; puisque le titre correct doit donc logiquement être {{Infobox de province du Maroc}}.

Modèles génériquesModifier

L'usage du préfixe "Méta <minuscule>..." est recommandé pour les modèles génériques.

Modèles de balises "Début" "Fin"Modifier

à débattre

Exemples Modifier

JargonModifier

Fixer le jargon est un effort du Projet:Aide, qui se concrétise par la création de patchs info pour le jargon technique. Concernant les modèles, il est nécessaire de définir un jargon :

Mieux définir les types de modèle, permettra tout d'abord, une meilleure catégorisation. De plus, à terme, on devrait aboutir à : « de tel type = basé sur tel méta-modèle ».

Types de modèles à mieux définir : infobox • palette (de navigation)/menu/encadré/boîte/tableau • (modèle de) lien, ...

Palette de navigationModifier

Nuvola apps kpager.svg
Il existe une catégorie dédiée à ce sujet : Palette de navigation.

Une palette de navigation est un large cadre horizontal contenant un ensemble important de liens relatifs à un thème donné. Elle se place en bas de page.

Notes :

  • Actuellement les menus sont assimilés à des palettes. Donc cette définition n'est pas consensuelle.
  • Le terme palette est associé à palette de navigation ou palette de couleurs. Cependant le terme palette de couleurs peut être remplacé par le terme Nuancier. Ainsi on utilisera exclusivement la typographie {{Palette <thème>}} pour les palettes de navigation.

MenuModifier

Un menu est un encadré, flottant à droite, contenant un ensemble de liens (agencés verticalement) relatifs à un thème donné. Il se place en tête des pages recensées dans le menu (entre autres).

Note : Les menus sont plus particulièrement adaptés aux pages non-encyclopédiques.

InfoboxModifier

Nuvola apps kpager.svg
Il existe une catégorie dédiée à ce sujet : Modèle infobox.

Une infobox sur Wikipedia est une fiche d'informations formatées qui est présente dans des articles de sujet similaire. Un modèle d'infobox est un encadré flottant à droite, qui se place en tête d'article.

Note : Une infobox est une généralisation d'une taxobox qui fait la somme des informations pour un organisme ou un groupe d'organismes.

FicheModifier

Cette page décrit une recommandation pour le développement d'infobox. Elle propose la construction d'une nouvelle génération d'infobox appelées « Fiche ». Initialement, cette recommandation mettait l'accent sur la catégorisation automatique des pages par le biais des infoboxes ; mais cette considération est désormais accessoire.

RecommandationModifier

Un modèle de fiche est un modèle infobox qui obéit à des conventions sévères, de création, de formatage et de paramètrage (à définir) afin d'être exploitable en tant que métadonnées (en savoir plus). Il est souhaitable que les infobox deviennent à terme des fiches. « Fiche » signifie donc : (prototype d') « Infobox nouvelle génération »

MotivationsModifier

Cette recommandation vise à concilier les faits suivants :

  • Les résultats du sondage concernant le terme "infobox se résume à : il serait préférable de renommer infobox en un terme français tel que "Fiche" ; mais ce travail n'est pas à entreprendre inutilement.
  • Cependant, une nécessaire harmonisation des modèles (notamment du paramétrage) entraînera fatalement le renamiement de quasiment tous les modèles d'infobox(es)
  • Il est préférable d'employer un terme neuf pour les modèles nouvelle génération, ceci pour éviter les confusions entre vieux modèles et ces nouveaux modèles.
  • De plus, la typographie (Infobox/InfoBox/infoboîte/...) et l'orthographe (des infoboxes/infobox) sont problématiques.
  • L'utilisation de ParserFunctions permet des modèles de meilleur qualité que la infoboxes existantes (grâce à l'utilisation de {{#formatnum: ...}} et {{#expr: ...}} notamment).
  • L'évolution de Aigles et Lys va vers l'incorporation de métadonnées dans les articles. Il est plus que souhaitable que cela ne se fasse pas en redondance avec les infoboxes.
  • Les deux raisons précédentes font que les valeurs de paramètres des infoboxes doivent le plus souvent possible être des données brutes.
  • Enfin WP doit acquérir un certain professionnalisme dans la programmation des modèles.
  • En matière de catégorisation des pages, un certain "laxisme" des wikipédiens et un goût immodéré du découpage ont entrainé un piètre état des choses. Le développement de la catégorisation automatique (c.-à-d., intégrée à l'infobox) est donc souhaitable pour remédier à cela.

CaractéristiquesModifier

On décrit les particularités propres aux fiches (elles restent à débattre)

  • Tout modèle de fiche doit avoir le marqueur {{Fiche ...}} dans son nom.
  • Une fiche respectent les conventions générales de Projet:Modèle/Harmonisation : en particulier on harmonisera le paramétrage des fiches
  • Codage CSS du style : l'apparence de la fiche est gérée par une feuille de style
  • Le code d'une fiche est morcellé code en briques afin de faire disparaitre tous les aspects techniques des tableaux.
  • Une fiche offre un modèle d'assistance pour son renseignement dans les articles.
Catégorisation
  • Le modèle "catégorise" les articles qui l'emploie selon un schéma rigoureux (à débattre) :
  • Le modèle {{Fiche <type>}} doit (dans la mesure du possible) "catégoriser" dans [[Catégorie:<type>]]. Toutefois, le choix de la catégorie peut être paramétré (selon la nationalité, par exemple).
  • Ce procédé de catégorisation doit être notifié dans la description de la catégorie avec {{Catégorisée par}} et dans la description du modèle avec {{Catégorise}}.
  • Le modèle de fiche ne doit pas être l'occasion d'entreprendre une catégorisation alternative à la catégorisation existante.
  • Avant de créer un modèle de fiche, assurez-vous que sa catégorie respectera les recommandations (de sur/sous-peuplement notamment), et annoncez-le dans le projet concerné et/ou dans le projet Modèle.

ExemplesModifier

{{Infobox Musique (œuvre)}} • ajouter

Avantages et objectionsModifier

  • La catégorisation des pages se fera en partie de manière automatique, et s'en trouvera ainsi facilitée.
  • Cette réforme permettra de mettre fin aux discordances en matière de paramétrage.
  • Le terme "Fiche" (qui reflète bien l'aspect technique) se substituera progressivement au terme "Infobox" qui choque certains.

Réponses aux objections concernant la catégorisationModifier

  • Cette recommandation est certe plutôt contraire à la recommandation ancienne (Utilisation de modèles qui "catégorisent" automatiquement -- 2004), mais elle est justifiée par l'évolution de Mediawiki et Aigles et Lys.
  • « On risque de se retrouver avec des catégories regroupant tout et n'importe quoi : articles, pages de discussion, sous-pages d'utilisateurs, pages Meta. » : Non grâce aux parserfunctions. Il faut utiliser {{#if:{{NAMESPACE}}||[[Catégorie:<nom de la catégorie>]]}}.
  • Le terme "fiche", devenant de facto un terme consacré, les wikipédiens sauront que la page utilisant une fiche est automatiquement catégorisée.
  • L'obligation d'annoncer la création de fiche permettra d'éviter les créations, à la va-vite, sources de certaines maladresses actuelles.

Voir aussiModifier

Note : La notion de fiche est donc au stade du prototype. Il s'agit donc d'une infobox conforme aux normes établies (/à établir) dans cette page.

ParamétrageModifier

Les noms (titres) de modèles obéissent aux conventions générales sur les titres.

Le manque d'harmonisation du paramétrage des modèles est surement le plus gros problème actuel ; le retard est considérable. Il existe déjà une petite convention des paramètres de l'infobox. Cela reste trop superficiel.

Une conception plus sérieuse des modèles passe par un typage des paramètres. Créer un jargon pour le paramétrage est une manière de définir des types standards.

Lors du choix des informations à afficher via les paramètres à renseigner, généralement lors de discussion, il est utile de faire une synthèse. Autrement dit, il ne faut pas que l'Infobox (ou la Fiche) se substitue à l'article. Une Infobox est une présentation sommaire d'un sujet donné, affichant des informations communes avec des variations sur le même thème. Inutile de trop spécialiser l'infobox ou de trop l'informer.

Nom des paramètresModifier

Rappel des règles plus ou moins consensuelles Modifier

Il faut, de manière générale, que le nom d'un paramètre reste au plus proche du français et soit autant que possible immédiatement compréhensible. Donc :

  • pas de typographies bizarres
  • pas de majuscules (donc ni « Titre » , ni « TITRE »)
  • pas d' "accolement" (donc pas de CamelCase)
  • pas d'abréviations, sauf, à la rigueur, les plus courantes (pas de points aux abréviations)
  • mettre les accents (mais éviter les mots accentués lorsque c'est possible)

Notes :

Usage du "_"Modifier

Ne pas employer de "_" entre les mots dans les noms de paramètres. Donc "nom local" et non "nom_local".
Motivation :

  • la possibilité de la présence d'espace dans les paramètres vaut pour une recommandation implicite ( à quoi ça sert que les MediaWikipédiens se décarcassent ? ;)
  • le contributeur moyen n'est pas initié à ces "façons" de programmeur

Note : l'usage courant étant apparemment 50-50, la proposition devrait donc faire l'objet d'une prise de décision.

Usage de l'anglaisModifier

Tout paramètre de modèles employés dans les articles doit être en français. En revanche, l'usage de l'anglais est permis (voire recommandé) pour les modèles à "usage interne" ; en particulier, lorsque ce paramètre fait référence aux mots-clés du langage HTML+CSS : class, float (puisque les valeurs sont en anglais), ...
Motivation :

  • l'usage de anglais est plus clair, plus explicite, dès que l'on rentre dans des considérations plus techniques ;
  • l'usage de anglais facilite le portage interwiki.

Valeur des paramètresModifier

Recommandations générales pour la valeur des paramètresModifier

Pour la valeur des paramètres, il faut employer, autant que possible, des valeurs brutes (c'est à dire, sans lien ni formatage). (bien sur, cette recommandation s'adresse aux développeurs de nouveaux modèles, non aux utilisateurs qui doivent suivre la documentation du modèle en place.)

Motivation :

  • les progrès des modèles permettent d'assurer un formatage automatique, et la déduction automatique de certaines valeurs (par exemple : densité=population/superficie pour les villes)
  • intégration des métadonnées (voir Aigles et Lys:Métadonnées personne)
  • Permet une meilleur exploitation du modèle : utiliser "Iran" plutôt que "Iran" permet la géolocalisation et l'usage de {{Iran}} : Modèle:Iran
  • Cela évite de mettre n'importe quoi.

Jargon pour le paramétrageModifier

On recommande ici la standardisation de certains paramètres généraux par l'emploi du "jargon". Définir un jargon pour les paramètres clarifiera leur usage et facilitera la documentation des modèles.

Paramètres à mieux définir : couleur • image • lien • taille • texte • contenu • pays • population • style ...

nom Modifier

Le paramètre nom est un paramètre facultatif qui devrait être commun à toutes les infobox. Il ne sert qu'à résoudre des problèmes d'homonymies : Ainsi on écrira et nom=Géorgie dans les infobox des articles Géorgie (pays) Géorgie (États-Unis). De même, on écrira nom=Corse dans les infobox des articles Corse (langue) Corse (département), mais c'est inutile dans celle de Corse.

Dans le code de l'infobox, on devrait trouver {{{nom|{{PAGENAME}}}}} (mais malheureusement, il est plus prudent (donc fortement recommandé) d'écrire {{#if:{{{nom|}}}|{{{nom}}}|{{PAGENAME}}}}

Le paramètres nom se place conventionnellement en tête des paramètres.

Convention

Aigles et Lys:Jargon/Paramètre nom

Notes
  • Malheureusement, on trouve d'autre "nom" pour nom ({{Infobox Communes de France}}, par exemple, emploie l'affreux nomcommune).
  • Conventionnellement, on emploie plutôt titre pour ... le titre ;) dans les modèles de cadres : encadrés, palettes de navigation, menus, ...

latitude et longitude Modifier

Les paramètres latitude et longitude sont un parfait exemple pour illustrer l'absence actuelle d'harmonisation ... et introduire l'usage du patch info pour le jargon du paramétrage.

  • beaucoup d'infobox ont des paramètres formatés en sexagésimal
  • {{Commune italienne}} utilise latitudegrade (grade ... hallucinant!) latitudeminute, latitudeseconde
  • {{Infobox Phare}} a deux paramètres position, localisation et s'emploie ainsi (Phare de la Lande) :
|position={{Coor dms|48|38|14|N|03|53|09|W|scale:2000_region:fr}}
  • etc. (il suffirait de fouiller un peu)

Dans tout ces cas, les coordonnées sont inutilisables (en l'état) pour la géolocalisation et geohack ... et la conversion décimale est difficilement faisable par un bot.

Convention

Un paramètre de latitude est une latitude exprimée en degrés entre -90 (au Pôle Sud) et 90. Il existe deux formats : numérique décimale (un « . » pour la virgule) ou la syntaxe DMS : « <dégrés>/<minutes>/<secondes>/<N ou S> » (en savoir plus).

paysModifier

Convention

Aigles et Lys:Jargon/Paramètre pays

Particularité
Motivation
  • Permet une meilleure exploitation du modèle : utiliser "Iran" plutôt que, tantôt "[[Iran]]", tantôt "{{Iran}}" ou autres, permet la géolocalisation et l'usage systématique de {{Iran}} : Modèle:Iran.
Note
Dans le cas où le pays peut être multiple, on emploiera un autre nom pour le paramètre : nations, nationalités ou autres.
Liste des pays actuels
 • </span>Afghanistan • Afrique du Sud • Albanie • Algérie • Allemagne • Andorre • Angola • Antigua-et-Barbuda • Arabie saoudite • Argentine • Arménie • Australie • Autriche • Azerbaïdjan • Bahamas • Bahreïn • Bangladesh • Barbade • Belgique • Belize • Bénin • Bhoutan • Biélorussie • Birmanie • Bolivie • Bosnie-Herzégovine • Botswana • Brésil • Brunei • Bulgarie • Burkina Faso • Burundi • Cambodge • Cameroun • Canada • Cap-Vert • République centrafricaine • Chili • Chine • Chypre • Colombie • Comores • République démocratique du Congo • République du Congo • Corée du Nord • Corée du Sud • Costa Rica • Côte d'Ivoire • Croatie • Cuba • Danemark • Djibouti • Dominique • République dominicaine • Égypte • Émirats arabes unis • Équateur • Érythrée • Espagne • Estonie • États-Unis • Éthiopie • Fidji • Finlande • France • Gabon • Gambie • Géorgie • Ghana • Grèce • Grenade • Guatemala • Guinée • Guinée-Bissau • Guinée équatoriale • Guyana • Haïti • Honduras • Hongrie • Inde • Indonésie • Irak • Iran • Irlande • Islande • Israël • Italie • Jamaïque • Japon • Jordanie • Kazakhstan • Kenya • Kirghizistan • Kiribati • Koweït • Laos • Lesotho • Lettonie • Liban • Libéria • Libye • Liechtenstein • Lituanie • Luxembourg • Macédoine • Madagascar • Malaisie • Malawi • Mali • Malte • Maroc • Îles Marshall • Maurice • Mauritanie • Mexique • Micronésie • Moldavie • Monaco • Mongolie • Monténégro • Mozambique • Namibie • Nauru • Népal • Nicaragua • Niger • Nigeria • Norvège • Nouvelle-Zélande • Oman • Ouganda • Ouzbékistan • Pakistan • Palaos • Panamá • Papouasie-Nouvelle-Guinée • Paraguay • Pays-Bas • Pérou • Philippines • Pologne • Portugal • Qatar • Roumanie • Royaume-Uni • Russie • Rwanda • Saint-Christophe-et-Niévès • Sainte-Lucie • Saint-Marin • Saint-Vincent-et-les-Grenadines • Îles Salomon • Salvador • Samoa • Sao Tomé-et-Principe • Sénégal • Serbie • Seychelles • Sierra Leone • Singapour • Slovaquie • Slovénie • Somalie • Soudan • Sri Lanka • Suède • Suisse • Suriname • Swaziland • Syrie • Tadjikistan • Tanzanie • Tchad • République tchèque • Thaïlande • Timor oriental • Togo • Tonga • Trinité-et-Tobago • Tunisie • Turkménistan • Turquie • Tuvalu • Ukraine • Uruguay • Vanuatu • Vatican • Venezuela • Viêt Nam • Yémen • Zambie • Zimbabwe

carte/géolocalisationModifier

Convention

La valeur du paramètre carte dans les infobox doit être un nom de code de la carte pour permettre l'emploi d'une meilleure carte que celle du pays.

Notes
  • géolocalisation semble s'imposer.
  • Le recourt à ce paramètre doit rester très marginal.

couleur Modifier

On trouve, de même, divers usages qui se traduisent par des valeurs différentes et incompatibles :

Convention

La valeur d'un paramètre de couleur doit être conforme à la syntaxe HTML pour les couleurs (en savoir plus).

styleModifier

Convention

Le paramètre style correspond à l'attribut style du langage HTML et sa valeur est un ensemble de propriétés CSS additionnelles. Ce paramètre est toujours facultatif. Il doit être réservé aux méta modèles ; donc ne pas être utilisé directement dans les articles.

Note
  • Un usage typique de ce paramètre est donc :
<div ... style="...;{{{style|}}}"> ... </div>
Motivation
  • l'utilisation de ce paramètre dans les articles est en désaccord avec le principe même d'une charte graphique.

imageModifier

lienModifier

Un jargon pour le paramètre lien est nécessaire pour préciser la possibilité (et le cas échéant la manière) d'utiliser une ancre ou le modèle {{!}}.

titreModifier

texteModifier

Un jargon pour le paramètre texte est nécessaire principalement pour signaler le problème de syntaxe récurrent : celui de la présence du signe "=" dans la valeur d'un paramètre non nommé. Voir par exemple Discussion Modèle:Référence souhaitée#Problème de syntaxe.

Paramètre booléenModifier

Définition

Un paramètre booléen (parfois appelé indicateur ou drapeau) ne prend que 2 valeurs : faux (0/false/nul/non/off/...) / vrai (1/true/non nul/oui/on/...). En tant que paramètre de modèle, ces valeurs sont : manquant ou vierge (faux) / quelconque (1 ou oui sont recommandées) (vrai).

ExemplesModifier

Quelques exemples de paramètres booléens dans les modèles :

  • le paramètre nohr de {{confusion}} permet de supprimer le soulignement :
Code wiki Rendu
{{Confusion|texte=Usage fictif}}
Page d&#039;aide sur l&#039;homonymie Usage fictif
{{Confusion|texte=Usage fictif|nohr=1}}
Page d&#039;aide sur l&#039;homonymie Usage fictif

Description détailléeModifier

Le bon sens veut qu'un paramètre booléen soit facultatif et prenne la valeur « faux » par défaut. Lorsqu'il prend la valeur « vrai », on dit d'un paramètre booléen qu'il est positionné ou défini.

Un tel paramètre <booléen> s'emploie uniquement ainsi dans le code d'un modèle :

{{#if: {{{<booléen>|}}}
|<!-- alors ... (vrai) -->
|<!-- sinon ... (faux) -->
}}

Voici un exemple de code de documentation de ce paramètre <booléen> :

:<code><booléen></code> : [[Aigles et Lys:Jargon/Paramètre booléen|paramètre booléen]] ; ... s'il est défini.

et un exemple d'usage dans le modèle <nom du modèle> :

{{<nom du modèle>|<booléen>=1}}

Les valeurs 1 ou oui sont recommandées pour "vrai". En revanche, l'utilisation de valeurs telles que 0, faux ou non sont à proscrire absolument, car elles sont ambigüe voire erronée


<span id="Codage" />

Programmation des modèlesModifier

Programmation sémantiqueModifier

Modèle:Exergue Il s'agit là d'un principe général (malheureusement trop abstrait et idéal)Modèle:Références nécessaires.

Il est clair que cet objectif concerne d'abord les développeurs de Mediawiki. Toutefois, voici quelques conséquences concrètes de ce principe :

Codage CSS du styleModifier

Recommandation

Il faut préférer le codage CSS (avec une feuille de style) du style plutôt que son codage wiki ; autrement dit : préférer l'usage de "class" aux commandes de "style".

Note 
Par « style », on entend l'apparence que prendra le modèle, sa mise en forme.
Exemple
Il faut préférer le code « <div class="error">...</div> » (avec « .error { color:red } » dans la feuille de style) au code « <div style="color:red">...</div> ».
Motivation
Limitation
Il faut toutefois veiller à conserver des feuilles de style de tailles raisonnables. Cela conduit à envisager un certain compromis notamment dans les infoboxes ; ce qui se traduit par le recours aux modèles de palette de couleurs. Cela reste à débattre.

TableauModifier

Recommandation

Il faut toujours employer la syntaxe HTML pour la construction de tableaux dans les modèles.

Description détaillée

Il faut employer les balises (HTML et wiki) <table>, <tr>, <td>, <th>, <caption> exclusivement (les autres balises HTML pour les tableaux n'appartiennent pas au langage wiki).

Motivation
  • La syntaxe purement wiki ({- |+ ! !! |- | || |}) est totalement inadaptée aux modèles car elle emploie les mêmes caractères clés : "{" "|" "}".
  • Elle est source de BUG car elle rend le code moins lisible
  • Elle est moins familière et plus dure à maitriser
  • Elle n'est pas supportée par les modèles de type "Début Fin"
  • Elle contient des BUG (un exemple)
  • De plus la syntaxe HTML permet de mieux mettre en forme le code (meilleur gestion des espacements
Voir aussi

Techniques de codageModifier

(en) (pattern design)

Aide détaillée : Aide:Modèle/FAQ.

Modèles de type switchModifier

Exemple
{{CIO2Pays}} • {{Infobox Musique (artiste)/Charte couleurs}} • {{Cadre1/Couleur}} • {{Géolocalisation/Iran}} ...

Méta-modèlesModifier

Cette section requiert des compétences particulières en matières de programmation des modèles et en générale. La croissance de la complexité de modèles fait qu'il faut se pencher sur leur optimisation.

Les questions de fondModifier

Modèle:Exergue Le problème principal est que malheureusement, il y a un défaut d'explications et de recommandations concernant le fonctionnement de MediaWiki et ses limites : coût serveur, job queue, mémoire, cache, saturation. En l'état, il est difficile de définir les bonnes pratiques : usage du subst:, versions développées (inline), usage intensif des méta-modèles, documentation intégrée, usage de sous-modèle, pratique de recherche des troncs-communs, pratique du tout-eu-un, appels récursifs ou croisés, ...

Par ailleurs, il est difficile de trouver des consultants, des experts pour résoudre les problèmes techniques (les "dirty tricks").

En l'absence de recommandations de la part des développeurs de Mediawiki, il n'y a pas lieu de se soucier d'optimisation. En revanche, la modification des modèles les plus usuels est couteuse pour le serveur, il est donc recommandé d'agir alors avec circonspection sur ces modèles.


En conséquence, il faut plutôt chercher à développer l'usage des méta-modèles (ou modèles génériques) car ils simplifient la maintenance des modèles ; soit en réduisant le nombre de modèles (par la pratique du « tout en un ») ; soit en réduisant les redondances (c.-à-d., les occurrences d'un même code) (par la pratique de « recherche des tronc communs »). De plus, cela contribue à une plus grande harmonisation de l'apparence graphique. Par ailleurs, le développement de modèles génériques est simplement la manière saine de programmer.

Il semble que le surcout général du à l'usage des méta-modèles soit, sinon nul, du moins négligeable (grâce au cache (+job queue) ; « les modèles sont "précalculés" » ). En revanche le remaniement d'un méta-modèle (usuel) à un cout important, il doit donc être protégé et en quelque sorte "verrouillé" :

Plus un modèle est générique et donc usité, moins il doit être remanié. En conséquent, un méta-modèle doit être conçues de manière quasi-définitive, et suffisamment souple, puis être protégé.

Voir aussi
Recommandation détaillée : Ne vous préoccupez pas de performance.
Discussion : Les questions de fond.

Ainsi, les avantages des méta-modèles en termes d'harmonisation et de simplicité d'usage sont clairs et justifient largement leur généralisation. On doit donc favoriser (sans excès) ces deux pratiques (tantôt complémentaires ou antagonistes) :

Pratique de « recherche des tronc communs » Modifier

C'est la pratique de recherche des fonctions primitives ("recherche de généricité") dont le principe est : « rassembler les troncs communs du code dans des modèles génériques ». Il s'agit là d'un processus naturel en programmation qui consiste à créer une librairie logicielle.

L'un des rôles de ces modèles est d'encapsuler les aspects techniques, les syntaxes difficiles (c'est le cas des modèles balises "Début" "Fin", de {{Lien avec icône}}, {{Wikilien}}, des Briques de fiche (prototypes), etc.)

Cette pratique entraine l'utilisation d'un grand nombre de sous-modèles (autrement dit, des modèles pour modèles ; et il est bien venu de les mettre en sous-pages puisque cela est désormais pleinement accepté).

Cela est donc conseillé pour construire des sous-modèles, non des modèles d'usage encyclopédique. Ainsi le principe de conception de Chimiebox (une dizaine de modèle pour une infobox !) n'est pas souhaitable.

Toutefois, la mise en cascade (l'imbrication) de modèles est déjà limitée par le serveur. Alors, un message d'erreur apparait et la page ne se charge plus entièrement.

En effet, l’expansion des modèles se fait évaluant de façon inconditionnelle tous les paramètres, même quand ceux-ci ne sont pas tous utilisés, et la réduction du code conditionnel inutile se fait ensuite ; il peut s’en suivre une surcharge en mémoire pour certains modèles qu’il faut alors optimiser pour éviter un dépassement de capacité.
C'est une limite actuelle de MediaWiki qui ne sait pas encore procéder à une évaluation entièrement paresseuse pour l’expansion des seuls paramètres qui sont strictement nécessaires, et qui pourrait de plus garder en cache lors de l’évaluation d’une page les différents appels de modèles ayant des paramètres identiques, pour que ceux-ci produisent les mêmes résultats sans avoir à les réévaluer complètement à chaque réutilisation).
De plus MediaWiki inclue complètement le modèle dans la page avant d’éliminer à la fin seulement le code en <noinclude> au lieu de gérer un cache séparé pour l’utilisation en "includeonly" (avec l’expansion et l’évaluation des paramètres déjà effectuée, séparément des appels avec paramètres non préétenus et non prévalués) et l’utilisation en "noinclude" (affiche direct de la page de documentation).

En définitive, il reste toujours aisé (dans de tels cas de figure) de "#subst:ituer" le(s) sous-modèle(s) tout en conservant le principe de conception (un usage virtuel de sous-modèle, en quelques sortes, semblable au code inline de C++).

Exemples de tels modèles 
{{Fiche}} • {{Coord}} • {{Géolocalisation}} (sous-modèles passés en argument) • modèles de type #switch • ...

Pratique du « tout en un » Modifier

La pratique du « tout en un » consiste à dire « un seul modèle pour tous les cas de figure (même les plus singuliers) ». Cette pratique crée des modèles complexes qui ont un grand nombre de paramètres souvent inemployés.

Il ne faut pas que cela se fasse aux dépens de la facilité de codage avec des millions de {{#if: ...}} qui s'emboitent les uns dans les autres. De manière similaire, les paramètres doivent être facultatifs et non optionnels ; ou autrement dit, les paramètres doivent être indépendant les uns des autres. Ainsi, parler de « cas de figures » dans la documentation est le signe d'une mauvaise conception du modèle.

Enfin, atteindre une centaine de paramètres serait excessif.

Exemples de tels modèles 
{{BUtilisateur}} • {{Fiche Ville}} • {{Ouvrage}} • {{Article}} ou {{Coord}} (dans une moindre mesure)

Vers une hiérarchie de classesModifier

Un méta-modèle s'apparente à une classe parent (héritage des paramètres, du code, de l'apparence). De même, le concept de hiérarchie de classes se retrouve dans les classes de CSS (C=cascading).

La hiérarchie des classes est plus particulièrement évidente pour les fiches (substitut des infoboxes) : "Fiche Ville Canada" dérive/hérite (conceptuellement sinon dans la pratique) de "Fiche Ville" qui dérive de "Fiche Lieu" (tout ce qui est "géolocalisable") qui dérive de "Fiche".

Cette notion est donc à prendre en compte pour une conception plus saine des modèles.

InfoboxesModifier

Syntaxe de la première colonneModifier

Convention

Il faut utiliser la syntaxe <th>, "!" en code wiki, (et non la syntaxe <td>, "|") pour la première colonne des infoboxes.

Motivation
  • Cela permet une différenciation plus aisée du style des colonnes dans les CSS.
  • C'est la syntaxe appropriée (d'un point de vue sémantique).

Gestion des paramètres manquantsModifier

Plusieurs techniques sont possibles lorsqu'un paramètre (disons param) n'est pas fourni :

technique du "#if:" Modifier
{{#if: {{{param|}}} 
 |...
}}
  • Avantage: fiabilité
  • Inconvénient: syntaxe très délicate
technique du "hiddenStructure" Modifier
  • À bannir, presque inutilisé actuellement

SouplesseModifier

Il s'agit ici d'étudier des moyens d'apporter de la souplesse aux infoboxes.

Infobox génériqueModifier

Une Infobox générique est un modèle qui peut inclure plusieurs types de thématiques. Comme par exemple {{Infobox Musique (artiste)}}, qui peut apparaître sur l'article d'un soliste, duo, trio, groupe, instrumentiste, ensemble classique, etc. Chacun de ces thèmes peut avoir sa propre charte graphique et des paramètres que l'on interchange dépendamment du thème.

Les avantages sont l'harmonisation, la réduction des Infoboxes pour un même thème, le rapatriement des paramètres similaires au sein d'un même modèle, la simplicité pour les néophytes.



Nuvola apps khelpcenter
{{Aide}} </center>
liste des mots-clés : Aide | B.A.-ba | Bandeau | Catégorie | Discuter | Image | Modèle | Ortho | Portail | Projet | Référence | Tableau | Utilisateur | Aigles et Lys

rechercher p parmi les projets - portails - catégories


 v · d · m 

Nuvola apps khelpcenter  Modèle  : Icon tools Nuvola apps kpager Nuvola apps khelpcenter  listes 
Nuvola apps khelpcenter  Aspects techniques  : HTMLCSSMediawiki:Common.cssMediawiki:Monobook.css(en) Wikia wordmark  Help Wikia wordmark  ParserFunctions (en) Wikia wordmark  Magic words 

Nuvola apps khelpcenter  Documenter  : {{Documentation modèle}} • {{Documentation modèle en sous-page}} • {{Modèle utilisant les ParserFunctions}} • {{Catégorise}} • {{Modèle obsolète}}

Interférence d'un bloqueur de publicité détectée !


Wikia est un site gratuit qui compte sur les revenus de la publicité. L'expérience des lecteurs utilisant des bloqueurs de publicité est différente

Wikia n'est pas accessible si vous avez fait d'autres modifications. Supprimez les règles personnalisées de votre bloqueur de publicité, et la page se chargera comme prévu.

Sur le réseau FANDOM

Wiki au hasard