Projet:Modèle/Harmonisation

Modèle:Navigation Modèle 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, des palettes...

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.

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

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

Titre des catégories

modifier

Modèle:Énoncé Modèle:Énoncé

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

Sous-pages

modifier

Modèle:Énoncé

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 liaison

modifier

Modèle:Énoncé Modèle:Énoncé 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ériques

modifier

Modèle:Énoncé

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

modifier

à débattre

Exemples

modifier

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) • (modèle de) lien, ...

Palette de navigation

modifier

Modèle:Catégorie principale Modèle:Énoncé

Notes :

  • Actuellement les menus (appelés palettes verticales) 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.


Jargon: Wikipédia:Jargon/Palette de navigation

Modèle:Énoncé

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


Jargon: Wikipédia:Jargon/Menu

Infobox

modifier

Modèle:Catégorie principale Modèle:Énoncé

Jargon: Wikipédia:Jargon/Infobox

Paramétrage

modifier

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 sûrement 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 discussions, il est utile de faire une synthèse. Autrement dit, il ne faut pas que l'Infobox 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ètres

modifier

Rappel des règles plus ou moins consensuelles

modifier

Modèle:Énoncé


  À faire   À éviter
{{Infobox Nom de l'infobox
 | nom     =  
 | image   = 
 | légende =
 | autre   = 
}}
{{Infobox Nom de l'infobox|
nom     =|
image   =|
légende =|
autre   =|
}}
{{Infobox Nom de l'infobox
|nom= 
|img= 
|lég=
|aut= 
}}

Notes :

Usage du "_"

modifier

Modèle:Énoncé 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'anglais

modifier

Modèle:Énoncé Motivation :

  • l'usage de l'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ètres

modifier

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

modifier
Formatage des valeurs
modifier

Modèle:Énoncé

  • 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 Wikipédia: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.

Paramètres non valorisés

modifier

Il faut éviter de mettre le caractère point d'interrogation (?) ou étoile (*), si la valeur du paramètre ne peut être déterminée et renseignée :

  •   Ce qu'il faut faire                :    | superficie =
  •   Ce qu'il ne faut pas faire   :    | superficie = * ou | superficie = ?

Il faut éviter de mettre des commentaires (<!-- commentaire -->) si le paramètre ne contient aucune valeur.

  •   Ce qu'il faut faire                :    | superficie =
  •   Ce qu'il ne faut pas faire   :    | superficie = <!-- commentaire -->

Jargon pour le paramétrage

modifier

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 • lien • texte • contenu • population • style ...

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 nom=Géorgie dans les infobox des articles Géorgie (pays) et Géorgie (États-Unis). De même, on écrira nom=Corse dans les infobox des articles Corse (langue) et 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

Modèle:Énoncé

Notes
  • Malheureusement, on trouve d'autre "nom" pour nom, par exemple nom français).
  • Conventionnellement, on emploie plutôt titre pour ... le titre ;) dans les modèles de cadres : encadrés, palettes de navigation, menus, ...


Jargon: Wikipédia:Jargon/Paramètre nom

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
  • certaines utilisent le modèle {{Coord}}
  • 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

Modèle:Énoncé


Jargon: Wikipédia:Jargon/Paramètre de latitudeWikipédia:Jargon/Paramètre de longitude
Convention

Modèle:Énoncé

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
Modèle:Pour chaque


Jargon: Wikipédia:Jargon/Paramètre pays

carte/géolocalisation

modifier
Convention

Modèle:Énoncé

Notes
Jargon: Wikipédia:Jargon/Paramètre carte
  • géolocalisation semble s'imposer.
  • Le recours à ce paramètre doit rester très marginal.

Subdivisions administratives

modifier
  • Il est recommandé d'utiliser « subdivision<numéro> » à la place de « région » et « lien subdivision<numéro> » à la place de « lien région » dans les modèles non spécifiques à la France.

couleur

modifier

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

Convention

Modèle:Énoncé


Jargon: Wikipédia:Jargon/Paramètre de couleur
Convention

Modèle:Énoncé

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.


Jargon: Wikipédia:Jargon/Paramètre style
Convention

Modèle:Énoncé

Note
  • On lui associe les paramètres suivants :
    • taille image, pour une taille d'image en nombre de pixel. Donnée numérique sans le suffixe « px ».
    • ou upright, pour ajuster automatiquement les dimensions des images en fonction des préférences de l'utilisateur.
    • légende : légende à afficher sous l'image.
    • alternative : alternative textuelle à l'image
  • Pour des types spécifiques d'images, et en prenant comme exemple les blasons, on utilisera la convention suivante : blason, taille blason, légende blason, alternative blason
Motivation

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 {{!}}.


Jargon: Wikipédia:Jargon/Paramètre lien


Jargon: Wikipédia:Jargon/Paramètre titre

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.


Jargon: Wikipédia:Jargon/Paramètre texte

Paramètre booléen

modifier
Définition

Modèle:Énoncé

Programmation des modèles

modifier

Programmation sémantique

modifier

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 style

modifier
Recommandation

Modèle:Énoncé

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.

Tableau

modifier
Recommandation

Modèle:Énoncé

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 codage

modifier

anglais (pattern design)

Modèle:Aide détaillée

Modèles de type switch

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

Méta-modèles

modifier

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

Les questions de fond

modifier

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").

Modèle:Énoncé

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é" :

Modèle:Énoncé

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 d'infobox 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 des Chimiebox (une dizaine de modèles 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" (affichage 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
{{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}}{{Infobox Subdivision administrative}}{{Ouvrage}}{{Article}} ou {{Coord}} (dans une moindre mesure)

Vers une hiérarchie de classes

modifier

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).

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

Infoboxes

modifier

Syntaxe de la première colonne

modifier
Convention

Modèle:Énoncé

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 manquants

modifier

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

Souplesse

modifier

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

Infobox générique

modifier

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.

Appel d'un modèle

modifier

L'appel d'un modèle se fait en mettant le nom du modèle entre accolades {{}} en ajoutant les paramètres nommés ou non nommés séparés d'un pipe |.

Exemples pour le modèle MonModèle :

  • {{MonModèle|paramètre1=...|paramètre2=...|paramètre3=...}} (paramètres nommés)
  • {{MonModèle|paramètre1|paramètre2|paramètre3}} (paramètres non nommés)

Recommandations :

  • il n'est pas nécessaire et non souhaitable d'y incorporer le nom de domaine, ne pas écrire : {{modèle:MonModèle|paramètre1|paramètre2|paramètre3}}.
  • mettre de préférence une majuscule à la première lettre du modèle : préférer {{MonModèle}} à {{monModèle}}

Pour certains modèles, comme les Infobox, il est préférable de ne pas utiliser cette syntaxe compacte. Lui préférer :

{{MonModèle
 |paramètre1 = ...
 |paramètre2 = ...
 |paramètre3 = ...
}}

Dans ce cas respecter les consignes suivantes :

  • mettre le | en début de ligne, jamais en fin de ligne
  • mettre au minimum un espace avant le signe =
  • mettre un et un seul espace après le signe =

Lorsque certains paramètres sont liés, il pourront être mis sur une ligne, par exemple :

|paramètre3.1 = ... |paramètre3.2 = ... |paramètre3.3 = ...

Modèle:Aide