Il s'agit d'un guide pas à pas pour une conversion rapide et facile des infoboxes wikitexte classiques en Infoboxes portables. Bien qu'il soit impossible de couvrir tous les types d'infoboxes — certaines étant plus exotiques que d'autres — vous constaterez que ces instructions sont largement applicables à la plupart des situations.

Il a été rédigé pour des personnes de tout niveau de compétence et n'est certainement pas destiné à être utilisé uniquement par des spécialistes des modèles portables. Il devrait être un bon guide pour construire de bonnes infoboxes dès le début. Des « bonnes pratiques » et des principes de portabilité sont disséminés un peu partout pour plus d'informations.

Fondamentaux[modifier le wikicode]

Avant de commencer, vous devriez idéalement vous familiariser avec :

Comme le balisage des Infoboxes portables est en fait XML, il sera également utile de savoir ce que l'on entend par « XML bien formé ». Toutefois, comme la migration avec la migration résulte naturellement en un XML bien formé, il s'agit généralement plus d'une compétence de diagnostic que d'une compétence réellement nécessaire pour fabriquer des Infoboxes portables.

Étape 0 : Trouver vos infoboxes[modifier le wikicode]

Avant de commencer le processus de conversion, vous devez d'abord déterminer quels modèles doivent être convertis. Cela signifie que vous devez trouver tous vos modèles. Si vous avez de la chance, la plupart d'entre eux se trouveront dans une catégorie, souvent appelée Catégorie:Infoboxes ou Catégorie:Modèles infoboxes.

Mais il arrive que les infoboxes ne soient pas classées avec soin. C'est alors que vous devez chercher des modèles par classification. En cas de doute, déterminez quel est le rôle prévu du modèle. Le meilleur endroit pour commencer est de consulter Spécial:Suggestions/templateswithouttype. Vous pouvez parfois voir des membres de Vanguard abréger les « modèles non classifiés » en « UTs ».

  • Regardez chaque entrée de modèle dans « Modèles sans type » qui semble être une infobox. Si c'est une infobox complète et autonome, classez-la comme Infobox. S'il s'agit d'un composant pour construire une partie d'une infobox, c'est généralement Données (s'il s'agit d'un changement de texte) ou Conception (si elle modifie l'apparence du contenu ou de l'élément).
  • Changez la classification de ces modèles en sélectionnant (en cliquant ou en appuyant) la classification (qui apparaît sous la forme d'un lien près du titre de la page du modèle) ou en utilisant le raccourci clavier « k ». Une fenêtre (appelée « modale ») apparaîtra pour sélectionner la nouvelle classification.
  • Si vous avez plusieurs modèles mis dans une catégorie, vous pouvez utiliser l'outil « Classification des modèles en vrac » pour les classer massivement. L'outil ne peut être utilisé que par les administrateurs locaux ou certains groupes de bénévoles, tels que SOAP et Vanguard.

NOTE : Les changements de classification n'apparaîtront généralement pas dans Suggestions avant le lendemain, car ils sont mis en cache une fois par jour. Les pages spéciales qui ne figurent pas dans Suggestions, comme Spécial:Modèles, sont mises à jour plus fréquemment (mais pas en temps réel).

Étape 1 : Suggestions[modifier le wikicode]

Spécial:Suggestions/nonportableinfoboxes est la colonne vertébrale du travail de portage d'infobox pour une communauté. Il arrive aussi que des faux positifs apparaissent (ou des modèles qui ne sont pas vraiment des infoboxes, ou qui n'apparaissent dans aucun article).

Faites défiler vers le bas la liste Spécial:Suggestions/nonportableinfoboxes et classez les modèles qui apparaissent sur 0 articles comme Hors article, ou toute autre classification appropriée. Comme les pages de documentation des modèles peuvent figurer dans cette liste — mais par définition ne sont pas destinées à des pages d'articles — Hors article est la classification appropriée. Voir l'étape 0 pour des instructions plus détaillées.

Inventaire des thèmes et variantes possibles[modifier le wikicode]

La première partie est assez simple. Pour les infoboxes à migrer, regardez les articles où les modèles sont en place avec Spécial:Pages liées (se trouvant sur la page Suggestions comme Utilisé sur X articles. Examinez le style visuel général de chaque modèle et notez s'ils utilisent un style ou un « look » cohérent, ou s'ils sont pratiquement identiques (mais pourraient être rendus cohérents), ou s'ils ont un aspect complètement différent. Chaque grande différence de style deviendra potentiellement un thème plus tard. Veillez à noter les éléments qui sont cohérents (comme la couleur ou les coins arrondis) dans la plupart des thèmes, afin que ces traits puissent être ajoutés au style par défaut .portable-infobox lorsque vous le créez.

La deuxième partie est potentiellement très difficile sur le plan technique, mais elle est nécessaire pour remplacer de manière cohérente les infoboxes classiques d'une communauté. Le plus simple est de consulter le code source de l'infobox classique pour trouver les endroits où le style est modifié par un paramètre, tel que class="{{{arrondi|10px}}}" ou style="width: {{{taille|250px}}}; background-color: {{{couleurap|white}}}". Dans ce dernier exemple, couleurap (couleur arrière-plan) est susceptible d'être utilisé comme paramètre thème-source.

Étape 2 : Bouton « Convertir ! », ce qu'il fait et ne fait pas[modifier le wikicode]

Lorsqu'un modèle est classifié comme Infobox mais n'utilise pas la syntaxe Infobox portable, un bouton « Convertir ! » apparaîtra dans la page Suggestions à côté du modèle (et dans le rail de la page du modèle). Ce bouton lance un outil de migration qui convertit partiellement l'infobox non portable en version de travail de l'Infobox portable. L'outil détectera généralement toutes les variables utilisées par une infobox classique et les convertira en une syntaxe d'infobox portable appropriée. Il connaît les modèles de code les plus couramment utilisés pour les libellés, les valeurs par défaut, et tente de les reconnaître et de les convertir pour les rôles d'Infobox portable.

Bien que cet outil soit utile et puisse effectuer une grande partie de la migration lui-même, il y aura généralement un certain travail qui devra être fait manuellement. La plupart des variables seront converties en élément <data>, généralement avec un élément <label> : l'outil de migration ne peut pas toujours distinguer les paramètres wikitexte destinés à être utilisés comme <title> et <data>, et ne détecte pas les autres éléments de l'infobox (tels que les en-têtes, les légendes, les valeurs par défaut et les autres éléments n'utilisant pas de variables).

Les infoboxes plus complexes qui nécessitent des thèmes, des groupes, des groupes intelligents, des balises <navigation> ou <format> ne seront pas non plus converties par l'outil de migration - celles-ci devront être effectuées manuellement, sur la base du code original utilisé par l'infobox classique. Cet outil peut toujours être un moyen de lancer la conversion d'une infobox, donnant un point de départ pour le code final de l'infobox portable - mais beaucoup de choses doivent être faites manuellement.

Étape 3 : Copier le code accessoire (noinclude et includeonly)[modifier le wikicode]

Les modèles fonctionnent par inclusion - l'insertion d'un modèle source dans tout article cible. Souvent, certaines parties d'un modèle ne sont pas utiles dans tous les cas, c'est pourquoi nous utilisons des balises de contrôle d'inclusion pour contrôler cela :

<noinclude> 
cache le contenu au sein de la balise dans l'article cible
Souvent, un modèle nécessite certaines sections cachées dans les articles. La documentation, les aperçus des infoboxes et les catégories de modèles en sont de bons exemples.
<onlyinclude> 
cache le contenu en dehors de la balise dans l'article cible
Cette balise est moins utilisée, mais sépare rapidement une infobox des autres contenus du modèle. En général, <includeonly> est préféré pour la clarté du code et la simplicité de compréhension.
<includeonly> 
cache le contenu au sein d'une balise dans le modèle source
L'infobox elle-même, les catégories d'articles qui l'accompagnent et les notes d'en-tête sont également susceptibles d'être cachées sur la page du modèle en elle-même. Cela permet d'éviter les bugs lors de la détection des nPI.

Conserver une partie vitale de la vieille infobox[modifier le wikicode]

Les infoboxes non portables originales seront probablement composées de deux parties : le tableau de l'infobox lui-même, et la documentation, la catégorisation, la navigation et d'autres informations complémentaires en dehors du tableau. Le tableau ressemblera souvent à ceci :

{|class="infobox"

. . . diverses lignes de code

|}

<noinclude>{{documentation}}[[Catégorie:Infoboxes]]</noinclude>

Copiez tout ce qui se trouve avant et après le corps principal du code NPI. C'est-à-dire, copiez tout ce qui se trouve au-dessus et en dessous du {| et du |}. Dans le code de la nouvelle PI, remplacez la documentation générée automatiquement dans la PI par ce que vous venez de copier de l'ancienne NPI. Dans l'exemple ci-dessus :

<noinclude>{{documentation}}[[Catégorie:Infoboxes]]</noinclude>

devrait être utilisé pour remplacer toute documentation générée automatiquement sur la NPI.

Étape 4 : Traduire la mise en page et les groupes de l'infobox classique[modifier le wikicode]

En raison de la façon dont certains modèles classiques sont codés, les paramètres wikitexte peuvent être interprétés de façon erronée ou n'ont jamais été conçus pour être visibles. La forme et la structure générales de ces infoboxes ne sont pas détectées avec l'outil de migration. La meilleure façon de la former correctement est d'aller de haut en bas et de commencer à placer les éléments dans l'ordre et les groupes appropriés.

Les Infoboxes portables sont automatiquement masquées si aucune valeur n'est fournie, de sorte qu'un code supplémentaire pour masquer ces données n'est pas nécessaire. En fait, si un <group> a un <header> à l'intérieur et qu'aucun élément du groupe n'a de valeur, l'en-tête ne s'affichera pas.

NOTE : De nombreuses communautés définissent les valeurs comme « Inconnu(e) » dans leurs infoboxes lorsqu'aucune valeur n'est donnée. Bien qu'acceptable, cette situation n'est pas idéale (et tend à produire un encombrement visuel), à moins qu'un quadrillage horizontal strict ne soit requis, ce qui devrait utiliser la fonction show="incomplete".

Types de données[modifier le wikicode]

S'agit-il d'une image, d'un titre, de données, de navigation, d'une en-tête, etc. Ce n'est pas toujours simple.

  • <title> gère les titres, et ces titres ne comportent pas de libellés visibles[1]. Pour être vraiment prêt pour les données, il doit également gérer les titres alternatifs, tels que ceux dans d'autres langues, les traductions de titres ou les sous-titres. En CSS, il est facile de styliser les titres secondaires avec quelque chose comme .pi-title ~ .pi-title.
    • De nombreuses infoboxes sont autogénérées avec <title source="name"><default>{{PAGENAME}}</default></title>. Afin de maintenir un code le plus propre possible, il convient de le modifier comme suit : <title source="name"><default><includeonly>{{{PAGENAME}}</includeonly></default></title> lorsque cela est possible.
    • Les titres par langue doivent être consolidés en un seul élément de données lorsqu'ils sont équivalents, comme les représentations kanji / kana / rōmaji du même titre[2][3]. Un indicateur visuel de la langue utilisée n'est généralement pas nécessaire, bien que l'utilisation d'un témoin pour représenter une langue soit une mauvaise pratique ; si une variété de traductions de titres (au-delà de la langue source et de la langue du wiki) sont fournies, celles-ci devraient être un <data> dans un <group>.
    • Les titres par région ou région linguistique doivent être séparés, comme les titres en langue espagnole qui sont différents en Espagne et en Amérique latine. En effet, il s'agit en fin de compte de données différentes.
    • Le logo d'un sujet doit être secondaire par rapport à la représentation textuelle d'un titre, il doit donc être soit un titre secondaire, soit un <data>.
  • <image> gère les images de taille standard, et ces images ne comportent pas de libellés visibles[1].
    • Les champs image ne gèrent que les données image. Une image et un texte mélangés n'afficheront que l'image[4].
    • Les champs images peuvent contenir soit un <tabber> ou une <gallery> enfant pour produire une galerie à onglets (ou une galerie à glissière sur les appareils mobiles). En raison de la simplicité du code, <gallery> est préférable. Selon la façon dont cette fonctionnalité est utilisée, il peut être nécessaire de passer à l'utilisation d'une fonction d'analyseur {{#tag:gallery}} à la place. Toutes les propriétés de la galerie qui sont disponibles en dehors d'une infobox ne sont pas disponibles à l'intérieur de celle-ci, comme les diaporamas.
    • La balise enfant <caption> gère les légendes. Si un champ image a un <gallery> à l'intérieur, la « légende » utilisée pour l'élément de la galerie devient le libellé de l'onglet.[5]
    • Les champs image ne nécessitent pas de chemins d'accès complets ni de liens internes Fichier:, bien qu'ils les acceptent dans la plupart des cas. Cependant, toute information de taille ou de légende ajoutée au lien Fichier: n'aura aucun effet.
    • Les champs image redimensionneront dynamiquement les images (qui sont plus larges que 130px) pour qu'elles s'adaptent au mieux à toute plateforme, jusqu'à un maximum de 270px – 300px. Les images plus petites, si elles décrivent vraiment le sujet de l'infobox, resteront simplement à leur taille native ; si l'image plus petite est une icône de jeu, ou une information complémentaire similaire, elle devrait plutôt être un champ <data>.
  • <data> est votre zone typique pour la plupart des autres paramètres.
  • <navigation> est une zone sans libellé[1] pour un wikitexte arbitraire.
    • Les icônes dans la zone supérieure « title » doivent être considérées comme une navigation, car elles ne sont ni explicitement un <title> ni un <image>[6].

Groupes[modifier le wikicode]

Habituellement, les groupes verticaux sont faciles à reconnaître. Pour les groupes horizontaux, il y a deux choix : la disposition traditionnelle « horizontale » et les groupes « intelligents ». Chacun d'entre eux peut être stylisé différemment, s'il y a lieu, mais il peut y avoir des raisons de choisir l'un ou l'autre. Les groupes horizontaux traditionnels sont rigides, et sont destinés à un nombre restreint et fixe d'articles lorsqu'il y a peu de variation. Par exemple, les champs Précédent et Suivant doivent utiliser des groupes horizontaux. Ils doivent être utilisés sur des groupes logiques où la mise en page est d'une ligne au maximum. Les groupes intelligents sont destinés à des ensembles d'éléments potentiellement plus importants et variés. Ils réagissent au nombre d'éléments et placeront chaque élément sur une nouvelle ligne de présentation lorsqu'ils atteindront le nombre maximum d'éléments défini dans la propriété row-items du groupe.

Libellés de données[modifier le wikicode]

Les libellés de données peuvent contenir la plupart des wikitextes. Ils doivent également respecter le <noinclude> (pour clarifier un libellé qui n'est pas affiché, à des fins d'édition) et le <includeonly> (pour afficher les parties d'un libellé qui ne doivent apparaître que dans un article, et non dans l'éditeur). Si elles contiennent en outre une infoicon, elles doivent veiller à éviter les problèmes d'accessibilité[7]<nom de la référence="span-titles"/>. Seuls les articles <data> ont des libellés visibles[1].

Du point de vue de la lisibilité et de l'accessibilité, il convient de noter que les libellés centrés verticalement ne définissent pas bien un élément de données plus grand, car l'œil humain a tendance à bondir dessus de manière inattendue. De plus, des libellés courts comme « ATQ » et « DEF » peuvent être utiles à un lecteur francophone, mais il faut utiliser <abbr> pour aider à la compréhension d'autres personnes qui peuvent ne pas être familières avec le sujet ou la langue[3]. En revanche, les très longues libellés sans saut de ligne peuvent être mieux simplifiés en mots plus petits. Une largeur de libellé égale à la valeur (c'est-à-dire 50 % de la largeur du libellé) est également moins lisible avec des éléments de données verticaux car elle éloigne l'emphase mise sur la valeur réelle (et ajoute généralement des espaces colorés), et doit être évitée dans les nouveaux modèles. Si la largeur d'un libellé doit être augmentée, la propriété CSS appropriée est flex-basis.

Étape 5 : Valeurs par défaut et formats[modifier le wikicode]

Il est généralement judicieux de disposer des données de saisie les plus simples pour alimenter le modèle, réduites à un simple type de données (telles qu'un nombre, des chaînes de texte, des liens ou des listes de ceux-ci). À cette fin, la balise <format> permet de remodeler les données d'entrée brutes en données d'affichage formatées. Par exemple, un article ayant un coût de « 10 po » (en supposant que « po » (pièce d'or) est la seule unité monétaire possible pour cette valeur de données) peut avoir une valeur saisie de « 10 » et utiliser la balise <format> pour afficher la valeur visible comme « 10 po » (ou utiliser un info-icône du jeu pour l'or, etc.). La balise <format> peut être utilisée dans les balises <data> ou <title>, mais pas <image> ou <navigation>.

Les valeurs par défaut avec <default> n'apparaissent que lorsque l'article ne fournit pas de valeur pour le paramètre nommé dans source=. La balise <default> peut être utilisée dans les balises <data> ou <title> ou <image>, mais pas <navigation>.

Les valeurs par défaut doivent éviter les valeurs par défaut de type « Inconnu(e) » ou « - » à moins qu'elles ne soient requises pour la mise en page. Les Infoboxes portables sont conçues pour ne pas afficher les valeurs qui ne sont pas utilisées lors de l'appel du modèle dans un article, de sorte qu'il n'est pas nécessaire d'avoir une logique pour le cacher ; en outre, si aucun élément de données dans un groupe n'est utilisé, le groupe et son en-tête n'apparaîtront pas à moins que l'attribut show="incomplete" soit ajouté au groupe.

ASTUCE : L'automatisation n'est pas toujours une bonne idée. En apparence, sauter le nom ou le titre en faveur du mot magique {{PAGENAME}} est efficace, mais peut être problématique lorsque le nom de la page change ou est précisé ou un homonyme, ou que le titre contient des caractères ou des balises qui ne peuvent pas être dupliqués avec un nom d'article. Le fait que d'autres éléments, comme les images, dépendent du nom de la page peut rendre les choses beaucoup plus difficiles si les utilisateurs d'une communauté ne comprennent pas la magie et la logique interne de votre modèle pour la saisie ou la maintenance de données de base. L'appel de modèles d'aide, de fonctions Lua ou de ParserFunctions imbriquées complexes peut contribuer à la confusion des utilisateurs si les modèles doivent être revus ou déchiffrés un jour.

Si une donnée ne nécessite aucun traitement (c'est-à-dire que seul le {{{paramètre}}} est utilisé et non modifié par des fonctions ou un style), les balises <default> et <format> ne doivent pas être incluses du tout. Cette fonction à elle seule simplifie considérablement certaines boîtes d'information classiques lors de la migration.Sinon, l'utilisation de <default> et <format> est effectivement au cœur de la migration des infoboxes, comme le font de nombreux modèles.

ASTUCE : Si vous ajoutez une catégorie qui dépend d'une valeur <data>, déclarer cette catégorie dans un commutateur ici vous évitera de le faire plus tard.

Étape 6 : Mise en forme[modifier le wikicode]

Voici un autre domaine où les infoboxes classiques perdent une grande partie de leur substance lors de la migration. La mise en forme des PI est réalisée à l'aide du CSS global. Le CSS en ligne (avec les attributs de style et de classe) est supprimé chaque fois que cela est possible.

Si tous les éléments d'un même type ont un style identique, ces styles doivent être déplacés vers la valeur CSS par défaut .portable-infobox ou un thème.

Si une valeur est stylisée différemment des autres de son type (par exemple, une transcription de Rōmaji en italique à côté de kanji ou de kana), un wikitexte (par exemple ''') ou une balise HTML appropriée (par exemple <dfn>) utilisée pour les décaler à l'intérieur de <format>. Le wikitexte qui n'utilise pas de CSS sont toujours considérés comme portables.

Il est fortement suggéré de ne pas modifier la largeur des boîtes d'information par rapport à la largeur par défaut en utilisant le CSS, car les images à l'intérieur des infoboxes commenceront à dépasser les limites de ces dernières. Les images qui sont réduites à l'aide du CSS se déforment inévitablement[8].

Couleur du thème et accentuation[modifier le wikicode]

La mise en forme des PI en CSS est un sujet plus complexe que ne le permet ce guide, mais il est traité de manière assez approfondie dans Aide:Infoboxes/CSS.

Étape bonus : Mise en place du CSS central et approbation des versions de travail[modifier le wikicode]

Les équipes Vanguard ont leurs propres règles et procédures pour approcher les communautés, mais les communautés peuvent choisir d'utiliser un grand nombre des mêmes outils et idées qui se sont révélés efficaces. En fonction de la complexité des CSS et du code supporté, un wiki sandbox séparé n'est généralement pas nécessaire. Développer le code du modèle directement sur la communauté principale en utilisant le système de Version de travail est simple et rend le test du nouveau modèle par rapport aux articles existants plus facile, car il fournira des résultats aussi bons ou meilleurs qu'un wiki de test autonome.

Le système de Version de travail est très efficace pour pouvoir tester rapidement les modèles appliqués à une page, en prévisualisant la page avec /Version de travail ajouté à la fin du nom du modèle. Cela est similaire à l'utilisation de /sandbox. Il fonctionne sur tous les modèles, pas seulement sur les infoboxes.

Il peut également être utile de placer .portable-infobox et d'autres CSS spécifiques aux PI dans une feuille de style séparée (MediaWiki:Themes.css) importée dans MediaWiki:Wikia.css. La ligne d'importation dans la feuille de style du thème principal @import url("/load.php?mode=articles&articles=MediaWiki:Themes.css&only=styles"); chargera Themes.css de manière optimisée.

Conclusion[modifier le wikicode]

Le portage des infoboxes classiques vers les PI peut les rendre beaucoup plus simples pour la maintenance future, et permettre des changements de style complets sans recoder de nombreux modèles. Le langage est conçu pour être à la fois flexible et puissant. Si vous rencontrez des problèmes de migration, n'hésitez pas à obtenir de l'aide sur le Portability Hub ou à contacter un membre de Vanguard.

Notes[modifier le wikicode]

  1. 1,0 1,1 1,2 et 1,3 Même si les libellés ne s'affichent pas dans les articles (comme c'est le cas pour <title> et <image>), elles s'affichent dans l'ÉditeurVisuel pour faciliter l'édition. <navigation> n'a pas de fonction de libellé.
  2. Un modèle commun que nous voyons souvent est un titre en langue japonaise présenté sous deux ou trois formes : kana, kanji et rōmaji. Idéalement, ces derniers utilisent un seul élément ><title> formaté et décomposé en texte en longueur, tel que <format><ruby lang="ja"><rb lang="ja-Hani">{{{titre-japonais}}}</rb>{{#if:{{{titre-japanese-kana}}}|<rp>(</rp><rt lang="ja-Hrkt">{{{titre-japonais-kana}}}</rt><rp>)</rp>}}</ruby>{{{#if:{{{titre-romaji}}}|<dfn lang="ja-Latn">({{{titre-romaji}}})</dfn>}}</format>.
  3. 3,0 et 3,1 L'élément <span> ne doit pas être utilisé pour les infobulles, car cela constitue une violation de l'accessibilité. L'élément <abbr> doit être utilisé pour les abréviations avec titres et <dfn> doit être utilisé (sans attribut title) pour spécifier un terme en langue étrangère.
  4. principe de portabilité : Ne pas mélanger les types de données dans un seul champ. Le texte est du texte, les images sont des images.
  5. Principe de portabilité : ne changer qu'une chose. La même action ne doit pas modifier plusieurs champs.
  6. Pour obtenir un bon effet d'icône en coin, placez les <navigation> et <title> à l'intérieur d'un <group>, avec le <navigation> d'abord, et mettre .pi-group > .pi-navigation pour qu'il flotte et se positionne.
  7. Pour éviter de mélanger le texte et les images, les infoicons doivent utiliser des caractères Unicode lorsque cela est possible, comme ℹ️ (INFORMATION SOURCE, U+2139). Il s'agit d'une utilisation acceptable de <abbr> et du titre pour transmettre de courtes descriptions non évidentes, mais peut également être utilisé pour faire un lien vers un article plus significatif.
  8. Il existe des méthodes utilisant le CSS pour réduire une image plus grande que souhaité, telles que max-height: 500px; width: auto;
Sauf mention contraire, le contenu de la communauté est disponible sous licence CC-BY-SA.