Aiuto:Conversione infobox

Questa è una guida passo-passo per una semplice e veloce conversione degli infobox classici di wikitext in infobox portatili. Benché sia impossibile coprire ciascun tipo di infobox — dato che alcuni sono più esotici degli altri — troverai che queste istruzioni sono largamente applicabili nella maggior parte delle situazioni.

È scritta per persone di tutti i livello di abilità, e sicuramente non è intesa solo per l'uso da parte di specialisti di infobox portatili. Dovrebbe essere una buona guida per costruire dei buoi infobox da zero. Ci sono anche "buone pratiche" e principi di portabilità diffusi qua e là per chiarezza aggiuntiva.

Fondamenti

Prima di iniziare, dovresti idealmente avere familiarità con:

• il codice wikitext;
• la nozione di selettore CSS e proprietà;
• il fatto che i termini infobox classico, infobox non-portatile, e NPI o nPI significano tutti la stessa cosa.

Poiché il markup degli infobox portatili è in realtà XML, potrebbe anche aiutare sapere che cosa si intende per "XML ben formato". Tuttavia, dato che la migrazione produce naturalmente risultati in un XML ben formato, questa è tipicamente più una abilità per diagnosticare problemi rispetto ad una attivamente necessaria per creare un infobox portatile.

Passo 1: Trova i tuoi infobox

Prima di iniziare il processo di conversione, devi prima capire quali template devono essere convertiti. Questo implica trovare tutti i tuoi template infobox. Se sei fortunato, la maggior parte saranno elencati nella pagina speciale Speciale:NonportableInfoboxes.

In alternativa, sono spesso raggruppati a seconda della wiki in una o più categorie, chiamate magari Categoria:Infobox oppure Categoria:Template infobox.

Passo 2: Inventario dei temi e delle potenziali variazione

La prima parte di questo è abbastanza semplice. Per gli infobox da convertire, dai un'occhiata agli articoli dove sono inseriti i template usando Speciale:PuntanoQui (disponibile tra gli strumenti per la pagina nella colonna di destra). Esamina lo stile di ciascun template e nota se usano uno stile o look consistente, oppure se somigliano uno all'altro (ma potrebbero essere resi più consistenti), oppure se sono completamente diversi. Ciascuna grande differenza potrebbe potenzialmente diventare poi un theme diverso. Assicurati di annotarti quali componenti sono consistenti (come il colore o gli angoli arrotondati) nella maggior parte dei temi, così che questi tratti possano poi essere aggiunti allo stile .portable-infobox di default quando lo creerai.

La seconda parte è potenzialmente molto difficile tecnicamente, ma è necessaria per una sostituzione consistente degli infobox classici di una community. Il modo più semplice per farlo è guardare al codice sorgente di un infobox classico nei punti in cui lo stile è modificato attraverso un parametro, come class="{{{roundy|10px}}}" oppure style="width: {{{width|250px}}}; background-color: {{{bgcolor|white}}}". Nell'ultimo esempio, bgcolor sarò probabilmente usato come parametro theme-source.

Passo 3: Copiare il codice accessorio (noinclude e includeonly)

I template funzionano tramite inclusione - l'inserimento di un template sorgente in un articolo bersaglio. Molto spesso, alcuni parti di un template non sono utili in tutti i casi e pertanto si utilizzato alcuni tag per controllare ciò che viene incluso:

<noinclude>

nasconde nell'articolo bersaglio il contenuto posto al suo interno

Molto spesso, un template necessita di nascondere alcune sezioni quando è incluso in un articolo. Documentazione, anteprima dell'infobox e categorie del template sono tutti buoni esempi di questo.

<onlyinclude>

nasconde nell'articolo bersaglio il contenuto posto al suo esterno

Questo tag è usato meno frequentemente, ma serve a separare rapidamente un infobox dal resto del contenuto del template. In generale, è preferibile <includeonly> per la chiarezza del codice e la comprensione più immediata.

<includeonly>

nasconde nel template sorgente il contenuto posto al suo interno

L'infobox stesso, accompagnato dalle categorie per l'articolo e dagli appunti per l'inserimento, sono spesso nascosti sulla pagina del template di origine. Questo aiuta a prevenire bug nell'identificazione degli infobox non portatili.

Mantenere una parte vitale del vecchio infobox

I vecchi infobox non portatili sono molto probabilmente composti da due parti: la tabella infobox stessa e la documentazione, categorizzazione, navigazione e altre informazioni di supporto fuori dalla tabella. Appaiono cioè spesso così:

{|class="infobox"

. . . diverse righe di codice

|}

<noinclude>{{documentazione}}[[Categoria:Infobox]]</noinclude>

Copia tutto ciò che viene sia prima che dopo il corpo principale del codice dell'infobox non portatile; cioè, copia tutto ciò che è sopra e sotto rispettivamente {| e |}. Nel nuovo infobox portatile, sostituisci la documentazione generata automaticamente con quello che hai copiato dal vecchio infobox. Nell'esempio qui sopra:

<noinclude>{{documentazione}}[[Categoria:Infobox]]</noinclude>

dovrebbe essere utilizzato per sostituire qualsiasi documentazione generata automaticamente.

Passo 4: Tradurre il layout e i gruppo dell'infobox classico

Per il modo in cui alcuni template classici sono stati scritti, i parametri di wikitext non sono sempre interpretati in ordine, e addirittura alcuni non sono mai stati pensati per essere visibili. Il modo migliore per costruirlo di nuovo è andare da cima a fondo e iniziare a posizionare elementi nell'ordine e nei gruppi appropriati.

Gli infobox portatili nascondono automaticamente gli elementi se non vi viene inserito alcun valore, pertanto il codice aggiuntivo per nascondere questi elementi non è più necessario. Inoltre, se un <group> ha un <header> all'interno e nessun elemento del gruppo ha dei valori assegnati, anche l'intestazione non verrà mostrata.

NOTA: Molte community definiscono valori come "Sconosciuto" nei loro infobox quando non si conosce il valore. Benché accettabile, questo non è ideale (e tenda a produrre pesantezza visiva) a meno che non sia richiesto un rigoroso layout orizzontale, che dovrebbe utilizzare la funzione show="incomplete".

Tipi di dati

Cosa sono immmagine, titolo, dato, navigazione, intestazione, etc? Questo non è sempre semplice.

• <title> gestisce i titoli, e questi titoli non mostrano alcuna etichetta visibile. Per essere davvero pronto per i dati, dovrebbe anche gestire titoli alternativi, come quelli in altre lingue, traduzioni dei titoli o sottotitoli. Nel CSS, è semplice adattare lo stile dei titoli secondari con qualcosa come .pi-title ~ .pi-title
  • Molti infobox sono generati automaticamente con <title source="nome"><default>{{PAGENAME}}</default></title>. Per mantenere il codice più pulito, questo dovrebbe essere modificato in <title source="nome"><default><includeonly>{{PAGENAME}}</includeonly></default></title> quando possibile.
  • I titoli per lingua dovrebbero essere unificati in un unico elemento quando sono equivalenti, come le versioni kanji / kana / rōmaji dello stesso titolo. Un indicatore visuale di quale lingua si stia utilizzando non è tipicamente richiesto, ma usare una bandiera per rappresentare una lingua è una cattiva pratica; se vengono fornite diverse traduzioni del titolo (oltre alla lingua originale e alla lingua della wiki), queste dovrebbe essere elementi <data> in un <group>.
  • I titoli per regione o regione linguistica dovrebbero essere separati, come i titolo in lingua spagnola che sono diversi tra la Spagna e l'America Latina. Questo è perché sono essenzialmente due dati differenti.
  • Un logo come soggetto dovrebbe essere secondario alla rappresentazione testuale del titolo, quindi dovrebbe essere o un titolo secondario o un <data>.
• <image> gestisce immagini della dimensione dell'infobox, e queste immagini non mostrano alcuna etichetta visibile.
  • I campi immagine gestiscono solo immagini. Un misto di immagine e testo mostrerà soltanto l'immagine.
  • I campi immagini possono contenere o un tag figlio <tabber> o <gallery> per produrre una galleria a schede (o una galleria a scorrimento sui dispositivi mobili). A causa della semplicità del codice, il tag <gallery> è preferibile. A seconda di come viene usata questa funzione, potrebbe essere richiesto cambiarlo in una funzione parser {{#tag:gallery}}. Non tutte le proprietà delle gallerie che sono disponibili fuori da un infobox sono disponibili all'interno, come ad esempio gli slideshow.
  • Il tag figlio <caption> gestiste le didascalia. Se un campo immagina ha un <gallery> al suo interno, la "didascalia" usata per l'elemento della galleria diventa l'etichetta della scheda.
  • I campi immagine non richiedono il percorso completo al file, né link interni tipo File:, anche se sono accettati nella maggior parte dei casi. Tuttavia, qualsiasi informazione sulla dimensione o didascalia aggiunta dopo il link 'File: non avrà effetto.
  • I campi immagine riscalano dinamicamente le immagini (che sono più larghe di 130px) per avere l'esperienza migliore su tutte le piattaforme, fino ad un massimo di 2770px – 300px. Le immagini più piccole, se davvero descrivono il soggetto dell'infobox, rimarranno semplicemente alle proprie dimensioni originali; se l'immagine piccola è un'icona di gioco, o informazioni supplementari simili, dovrebbe essere invece un campo <data>.
• <data> è l'area tipica per la maggior parte degli altri parametri.
• <navigation> è un'area senza etichetta per wikitext arbitrario.
  • Le icone nell'area superiore al "titolo" dovrebbero essere considerate navigazione, dato che non sono né esplicitamente un <title> né una <image>.

Gruppi

I gruppi tipici verticali sono facili da riconoscere. Per i gruppi orizzontali, ci sono due scelte: il layout "orizzontale" tradizionale e i gruppi "intelligenti". Ciascuno stile può essere personalizzato differentemente, se c'è motivo per farlo, ma potrebbero esserci ragioni per scegliere uno rispetto all'altro. I gruppi tradizionali sono rigidi, e sono pensati per un piccolo insieme di elementi dove c'è poca variazione. Per esempio, i campi "Prossimo" e "Precedente" dovrebbero usare un gruppo orizzontale. Dovrebbero essere usati in gruppi logici dove il layoyt è al massimo uno per riga. I gruppi intelligenti sono pensati per insiemi di elementi vari e potenzialmente più grandi. Si adattano al numero di elementi, e mandano a capo ciascun elemento ad un nuova riga di layout quando raggiungono il massimo numero di elementi definiti nella proprietà di gruppo row-itemsy.

Etichette dei dati

Le etichette dei dati possono contenere la maggior parte del wikitext. Dovrebbero anche rispettare <noinclude> (per chiarire un etichetta senza che venga mostrato, per scopi di modifica) e <includeonly> (per mostrare parti dell'etichetta che dovrebbero apparire solo in un articolo, non nell'editor). Se in aggiunta contengono una infoicon, bisogna staere attenti ad evitare problemi di accessibilità. Solo gli elementi <data> hanno un'etichetta visibile.

Dalla prospettiva di leggibilità e accessabilità si dovrebbe fare notare che le etichette centrate verticalmente non definiscono bene un elemento più alto, dato che lo sguardo umano tende a saltare in giro in modi inaspettati. Inoltre, etichette corte come "ATK" e "DEF" potrebbero avere senso per lettori madrelingua inglesi, ma si dovrebbe usare <abbr> per aiutare la comprensione degli altri che potrebbero non essere famigliari con l'argomento o la lingua. Al contrario, etichette molto lunghe senza andare a capo potrebbero essere semplificate meglio in parole più corte. Una larghezza uguale per l'etichetta e il valore (cioè larghezza al 50%) è similmente meno leggibile dato che porta via l'enfasi dal valore effettivo (e tipicamente aggiunge spazi-bianchi), e si dovrebbe evitare nei nuovi template. Se la larghezza dell'etichetta deve essere aumentatata, la proprietà CSS correlata è flex-basis.

Passo 5: Default e formati

È tipicamente una buona idea avere i dati di input più sempplici possibile da fornire al template, ridotti a tipologie semplici (come un numero, uno stringa di testo, un link o una lista di questi). A questo fine, il tag <format> può plasmare l'input grezzo in un output formattato. Per esempio, un elemento con un costo di "10 lingotti" (assumendo che "lingotti" sia l'unica possibile unità di moneta per quel dato) può avere in input "10" usare il tag <format> per mostrare il valore visibile come "10 lingotti" (o usando una infoicon del gioco come lingotti, etc.). Il tag <format> può essere usato nei tag <data> o <title>, ma non in <image> o <navigation>.

I valori di default con <default> appaiono solo quando l'articolo non fornisce un valore per il parametro definito in source=. Il tag <default> può essere usato nei tag <data> o <title> o <image>, ma non <navigation>.

I valori di default dovrebbero evitare tipologie di default come "Sconosciuto" o "-" a meno che non siano richiesti per il layout. Gli infobox portatili sono progettati per non mostrare i valori che non sono usati nella chiamata al template dell'articolo, quindi funzioni logiche per nasconderli non sono necessarie; in più, se nessun elemento viene usato in un dato gruppo, quel gruppo e la sua intestazione non appariranno a meno che non venga aggiunto l'attributo show="incomplete" al gruppo.

Consiglio: l'automazione non è sempre una buona idea. In superficie, saltare il nome o il titolo in favore della parola magica {{PAGENAME}} è efficiente, ma può essere problematico quando il nome della pagina cambia o è qualificato o c'è una disambiguazione o semplicemente contiene caratteri o markup che non possono essere duplicati. Avere altri elementi, come le immagini, che dipendono dal nome della pagina può rendere le cose molto più difficili se gli utenti della community non capiscono la magia interna e la logica del tuo template per l'inserimento di dati o la manutenzione. Chiamare template helper, funzioni Lua, o funzioni parser complesse nidificate può tutto contribuire alla confusione dell'utente se il template dovessere mai essere revisionato.

Se un elemento non ha bisogno di processamenti (per esempio, viene usato solo {{{parametro}}} non modificato con funzioni o stili, i tag di <default> e <format> non hanno bisogno di essere inclusi. Questa funzione da sola semplifica drasticamente molti infobox classici dopo la migrazione. Altrimenti, usare <default> e <format> effettivamente è il cuore della migrazione degli infobox, così come molti processi con template.

Consiglio: se stai aggiungendo una categoria che dipende dal valore di un <data>, dichiarare quella categoria in uno switch ti salverà dal doverlo fare più avanti.

Passo 6: Stile

Ecco un'altra area dove gli infobox classici perdono gran parte del loro corpo durante la migrazione. La personalizzazione degli infobox portatili avviene usando CSS globale. Il CSS "inline" (con gli attributi di stile e classe) deve rimosso appena possibile

Se tutti gli elementi di uno stesso tipo hanno lo stesso stile, questi stili potrebbe essere utilizzati come il default .portable-infobox nel CSS o come un tema.

Se un valore ha uno stile diverso dagli altri del suo tipo (per esempio, una trascrizione Rōmaji in corsivo vicino a kanji o kana), si può usare del wikitext (per esempio, ''') o un tag HTML appropriato (per esempio, <dfn>) per distinguerlo all'interno di un tag <format>. Wikitext che non usa CSS è sempre considerato portabile.

Si è caldamente invitati a non modificare la larghezza degli infobox da quella di default usando il CSS, dato che le immagini all'interno possono eccedere dai bordi dell'infobox. Le immagini che sono compresse usando il CSS diventano inevitabilmente distorte.

Temi e colore secondario

Gli stili per gli infobox portatili tramite CSS sono un argomento più complesso di quanto possibile in questa guida, ma sono trattati con maggiore profondità in Aiuto:Infobox/CSS.

Passo Bonus: impostare CSS centralizzato a approvazione delle bozze

I team Vanguard hanno le proprie regole e procedure per approcciare le community, ma le community possono sceglere di usare molti degli stessi strumenti e idee che si sono dimostrati efficaci. A seconda della complessità del CSS e del codice di supporto, una wiki sandbox separata non è tipicamente necessaria. Sviluppare il codice del template direttamente sulla community principale usando un sistema di bozze è chiaro e rende più facile testare il nuovo template su articoli esistenti, dato che fornisce risultati uguali o migliori di una wiki di test a sé stante.

Il sistema "bozza" è molto efficace per essere in grado di testare rapidamente i templati applicandoli in una pagina, visualizzando l'anteprima della pagina con /bozza aggiunto alla fine del nome del template. Questo è simile all'usare /sandbox. Funziona con tutti i template, non solo con gli infobox.

Inserire .portable-infobox e altro CSS specifico agli infobox portatili in un foglio di stile separato (MediaWiki:Infobox.css) importato in MediaWiki:Common.css può anch'esso essere utile. La riga di import nel foglio di stile principale @import url("/load.php?mode=articles&articles=MediaWiki:Infobox.css&only=styles"); caricherà Infobox.css in un modo ottimizzato.

Conclusioni

Migrare gli infobox classici a infobox portatili può rendere molto più semplice la manutenzione futura, e permettere estese modifiche del loro stile senza la necessità di riscrivere il codice dei template. La lingua è pensara per essere sia flessibile che potente. Se ti imbatti in problemi nella conversione, sentiti libero di chiedere aiuto sul Portability Hub o contattare un membro di Vanguard.

Aiuto aggiuntivo e feedback

• Naviga e cerca altre pagine di aiuto su Contenuti.
• Esplora la Wiki della Community per ulteriori fonti di aiuto o supporto.
• Leggi come contattare Fandom per problemi o segnalare errori.