Global templates/Proposed specification/it

  Татары, узбеки и ненцы И весь украинский народ, И даже приволжские немцы К себе переводчиков ждут. И может быть в эту минуту Меня на турецкий язык Японец какой переводит И в самую душу проник. —Осип Мандельштам Questa è una bozza per definire una proposta di requisiti minimi per i template e i moduli globali.

'''Questo NON è un progetto attualmente in corso, né ufficialmente approvato e prossimo a partire in un qualsiasi momento (almeno per adesso). Si tratta solo di un'idea, per quanto molto dettagliata.'''

L'obiettivo finale è di creare un gruppo di utenti e di tecnici che sia interessato a realizzare questo progetto, con tutti i requisiti necessari in termini di pianificazione, realizzazione, coinvolgimento delle comunità, eccetera.

Questo documento non entra nei dettagli tecnici riguardo archiviazione, memorizzazione nella cache, consegna, progettazione del codice PHP, eccetera. Lo scopo è cercare di definire i requisiti di come una tale funzionalità possa funzionare dal punto di vista degli utenti:


 * 1) coloro che creano e curano template e moduli;
 * 2) coloro che creano e curano pagine che contengono template e moduli, includendo in questa definizione tutti gli utenti e tutte le tipologie di pagine:
 * 3) * tutti i livelli di esperienza, da coloro che sono completamente a digiuno dell'argomento a coloro che hanno migliaia di edit alle spalle;
 * 4) * tutti gli strumenti di modifica, dal wikicodice a Visual Editor e Content Translation, a tutti gli altri mezzi (compresi i bot);
 * 5) * tutte le wiki: Wikipedia, Wiktionary, Wikivoyage, Wikidata, Incubator, eccetera, compresi eventuali futuri nuovi progetti;
 * 6) * tutte le lingue: inglese, francese, russo, spagnolo, armeno, persiano, zulu, manipuri, eccetera;
 * 7) * tutti i tipi di pagine: voci, pagine di discussione (delle voci, degli utenti o del progetto), pagine di progetto, categorie, manuali dei template, eccetera.

In poche parole
Una larga parte delle funzionalità dei progetti Wikimedia si basa su template e moduli Lua. Purtroppo, allo stato attuale, queste funzionalità non sono facilmente trasferibili da una wiki all'altra e sono male integrate con i nuovi strumenti di creazione e modifica delle voci, come Visual Editor e Content Translation. Questo causa uno spreco di tempo per gli utenti e grosse difficoltà in particolare per gli utenti nuovi e per gli utenti delle comunità più piccole. Migliorare la possibilità di condividere queste funzionalità renderà più veloce e stabile lo sviluppo del software e consentirà agli utenti di concentrarsi maggiormente sulla creazione di testi.

Il problema
Nota: salvo dove diversamente specificato, il discorso sui template vale anche per i moduli Lua/Scribunto.

I template permettono di sfruttare una consistente parte delle funzionalità dei progetti Wikimedia. Alcune di queste sono estremamente importanti (per esempio, gli infobox, le note, le “citazioni necessarie”, eccetera): tutti i lettori possono vederle e tutti gli utenti le incontrano quando modificano una voce.

I template sono inoltre usati in moltissimi aspetti della manutenzione dei progetti, come le procedure di cancellazione o di problematicità, le discussioni sulle linee guida, la creazione di wikiprogetti, eccetera.

I template sono un meccanismo molto efficiente per realizzare, implementare e riutilizzare velocemente e su larga scala pezzi di codice e di markup su più pagine. Tuttavia, i template portano con sé anche dei problemi di accessibilità per tutte le categorie di utenti.

Utenti che usano il wikitesto
I template, alle volte, sono difficili da comprendere o modificare per gli utenti che usano il wikitesto. Gli utenti più esperti (ma non tutti!) magari possono incontrare meno difficoltà nel riconoscere e modificare uno di questi template, ma gli utenti meno esperti potrebbero rimanere sconcertati da quell'ammasso criptico di parentesi graffe, caratteri pipe, segni di uguale, eccetera.

Usare una funzionalità di un template significa innanzitutto sapere che esiste un template, conoscerne il nome e poi digitarlo fra parentesi graffe ( – ) o copiarlo così com'è da un'altra voce o pagina. Questo non è affatto ovvio per un nuovo utente e, alle volte, anche gli utenti esperti sono costretti a consultare il manuale del template.

Alcune wiki hanno “risolto il problema”, inserendo un bottone apposito nelle toolbar per gli utenti. Tuttavia, nonostante molti dei template siano uguali o molto simili su tutti i progetti, questi bottoni restano localizzati sui singoli progetti.

Utenti che usano Visual Editor
Gli utenti che usano il VisualEditor hanno qualche facilitazione in più quando usano i template, ma anche loro possono incontrare dei problemi. Per esempio, anche in questo caso l'utente deve essere a conoscenza dell'esistenza del template, utilizzare la funzionalità “Inserisci → Template” nell'apposito menu e digitarvi l'apposito nome.

Il menu “Inserisci” del VisualEditor ha funzioni apposite per inserire formule matematiche, geroglifici, spartiti musicali e altre funzioni ancora, ma non ha delle opzioni apposite per i template “Infobox”, “Senza fonte”, “Converti unità”, “Citazione”, eccetera. In altre parole, tutti i template sono gestiti come se fossero tutti uguali (pur sapendo che questo non è affatto vero).

C'è una eccezione al momento: alcune wiki hanno il pulsante “Cita”, che permette di inserire note già formattate con gli appositi template di citazione. Questa, però, è la classica eccezione che conferma la regola. Inoltre, questa funzione necessita di essere configurata manualmente perfino per le sue caratteristiche di base - col risultato che moltissime wiki semplicemente non dispongono affatto di questo pulsante.

Un'altra eccezione simile, aggiunta nel settembre 2019, è il supporto aggiuntivo per i template “Citazione necessaria”, ma anche questi vanno configurati manualmente progetto per progetto perché possano funzionare.

Difficoltà per gli utenti che contribuiscono su più di un progetto
Molti template esistono in un progetto, ma non sono presenti in un altro progetto, oppure esistono, ma alcune delle funzionalità sono assenti o funzionano in modo diverso. Per questo motivo, spesso è difficile o addirittura impossibile “trasferire” ciò che si è imparato su un progetto in un altro progetto. Questo non succede solo fra progetti in lingue diverse (per esempio, Wikipedia in italiano e in inglese), ma anche su differenti progetti nella stessa lingua (per esempio, Wikipedia in italiano e Wikisource in italiano).

Inoltre, i template rendono più difficili le traduzioni per gli utenti che contribuiscono su progetti in lingue diverse, sia se realizzate manualmente sia se fatte tramite Content Translation. Spesso gli utenti sono costretti a saltare a piè pari i template, oppure ad aggiungerli o sistemarli in un secondo momento, oppure ancora un template può scoraggiare un utente dal completare la traduzione.

Moltissimi dei problemi riscontrati con Content Translation riguardano proprio la gestione dei template. Nonostante l'estensione abbia una funzionalità che permette di tradurre o quantomeno di automatizzare parte del processo di traduzione, questa funzionalità funziona soltanto se il template ha un corrispettivo nella lingua in cui si sta traducendo e se esiste una traduzione dei parametri corrispondenti. Tutto questo va realizzato per ogni lingua, per ogni template, per ogni parametro ed eventualmente per ogni modifica - nonostante, spesso, le funzionalità dei differenti template siano le stesse.

In teoria, dovrebbe essere possibile trasferire e tradurre automaticamente o quasi tutti i template e i relativi parametri, per permettere agli utenti di concentrarsi sulla traduzione della voce o della pagina vera e propria (che poi è l'area dove il contributo umano è più necessario). Un template può essere, in effetti, esportato da una wiki all'altra, ma una volta compiuta l'esportazione, di fatto il template diventa un fork della versione originale, rimanendo così com'è oppure venendo sviluppato a sé (e dunque diventando più o meno incompatibile con il template originale). Alcuni utenti possono periodicamente aggiornare a mano le differenti copie, ma questo non è affatto un metodo scalabile o che possa funzionare per tutte le svariate centinaia di progetti che abbiamo.

Anche i parametri di un template possono variare nel nome fra versione e versione, ma avere la stessa funzionalità. Si potrebbe ricorrere agli alias in TemplateData per mappare le differenze di traduzione, ma si tratta di una soluzione sub-ottimale: non è questo lo scopo degli alias e, soprattutto, si è comunque costretti a gestire manualmente ogni traduzione.

Un template è un combinato di logiche, stringhe di interfaccia e formattazione che ne rendono impossibile una traduzione lineare, come invece succede con il codice di base di MediaWiki e delle sue estensioni.

Difficoltà per gli utenti delle comunità minori
Un nuovo progetto Wikimedia viene creato installando le funzioni fondamentali di MediaWiki e un certo numero di estensioni di default. Tuttavia, questo non basta a mettere sullo stesso piano un nuovo progetto e un progetto già esistente, perché larghissima parte delle funzioni fondamentali viene in realtà implementata tramite i template (infobox, citazioni, tabelle, eccetera).

Una proposta di soluzione, in sintesi
Ci sono già molte funzioni di MediaWiki che sono globali: le immagini (tramite Commons), i blocchi, gli account (tramite CentralAuth), le preferenze, le pagine utente, i javascript e i CSS personalizzati degli utenti, eccetera.

Anche template e moduli dovrebbero, quindi, essere resi globali, gestendoli tramite un repository globale e permettendo la loro localizzazione similmente a quanto accade con le estensioni di MediaWiki.

Template e moduli globali permetterebbero a tutti gli utenti dei vari progetti di collaborare più facilmente allo sviluppo del codice, così come di tradurre voci e pagine che li utilizzano, senza essere costretti a imparare da capo ogni volta come gestire le differenze e le eccezioni fra template.

La sintassi di template e moduli e, più in generale, la loro manutenzione e gestione non cambieranno, quindi tutte le capacità acquisite lungo questi anni dagli utenti non diventeranno obsolete.

Tutti i progetti dovrebbero poter utilizzare i template globali, ma non necessariamente costretti a farlo. Ciascuna comunità dovrà mantenere la possibilità di sovrascrivere qualsivoglia funzionalità, aspetto grafico, dato o altro, se necessario.

Localizzare i template dovrà tuttavia essere utile tanto quanto localizzare le estensioni MediaWiki.

I template devono essere semantici e globali
Per semantico si intende che tutte le altre componenti di MediaWiki (e in particolare Visual Editor e Content Translation) dovranno avere modo di individuare un determinato template con determinate funzionalità, così da poterlo integrare in una traduzione come infobox, template di citazione o di manutenzione, eccetera, e non come un generico template. Al momento, la cosa che più si avvicina all'obiettivo è TemplateData, che però descrive soltanto i parametri dei template e non permette, per esempio, a Visual Editor di inserire un pulsante “Inserisci infobox” nella toolbar.

Per globale si intende che il codice di un template vada posto in un repository centralizzato, che permetta il suo riutilizzo in qualsiasi wiki.

Come rendere semantico un template
I template non sono mai stati pensati come semantici, nel senso di rendere più semplice la loro gestione dalle estensioni che aiutano nelle traduzioni.

Tuttavia, esistono alcuni esempi di template che sono stati resi semantici:


 * vari fra i template Cita, che sono utilizzabili tramite il pulsante “Cita” nella toolbar di Visual Editor (e che però richiedono che venga prima scritto e localizzato un sacco di codice per configurare Citoid);
 * il template “Citazione necessaria”, che è stato adattato per Visual Editor lo scorso settembre 2019 (e che ugualmente richiede uno sforzo di configurazione su ogni wiki);
 * i template per menzionare gli utenti tramite Flow (anch'essa da configurare localmente);
 * alcuni tool utilizzati per compiere ricerche sui dump di Wikipedia oppure sui template di monitoraggio dei progetti di Wikipedia in inglese (spesso presenti nelle pagine di discussione);
 * l'estensione PageTriage, configurata per funzionare con i template di disambiguazione di Wikipedia in inglese.

In quest'ultimo caso, di fatto l'estensione codifica in modo rigido i template di un progetto, rendendoli inutilizzabili in un altro progetto senza una significativa riscrittura. Ma anche nei casi in cui la configurazione su wiki sia poca cosa, come per Flow, comunque serve configurare qualcosa. Questo non può funzionare in modo efficiente per tutti i 900 e oltre progetti Wikimedia attualmente esistenti e per le centinaia di futuribili progetti che verranno.

Queste funzioni dovrebbero essere globali di default, almeno nella loro configurazione di base, in modo che possano essere utilizzabili da subito da estensioni, bot, programmi per analizzare i dump, eccetera.

Dove conservare i template
La soluzione potrebbe essere conservarli su una wiki centralizzata (Meta, Commons o una nuova wiki apposita) oppure su un repository (come Gerrit o un altro).

La migliore soluzione potrebbe forse essere una wiki apposita, in modo tale che i template e i moduli non vengano confusi con le immagini, le discussioni generali della comunità, eccetera.

Usare Gerrit è tecnicamente fattibile, ma si perderebbe un importantissimo elemento di accessibilità per chi gestisce e cura i template: modificare una pagina wiki è molto più semplice e immediato per la maggior parte degli utenti che fare un commit e aspettare una revisione del codice. Quindi Gerrit non dovrebbe diventare il metodo primario per raccogliere e conservare i template.

Inoltre, il repository dovrebbe permettere la modifica di template e moduli al maggior numero possibile di utenti. Le regole di protezione e i permessi speciali, almeno inizialmente, dovrebbero essere uguali a quelle di tutte le altre wiki: tutto dovrebbe essere aperto di default, ma dovrebbe essere altrettanto possibile proteggere i template più comuni, sensibili o frequentemente vandalizzati. Ulteriori regole e livelli di protezione possono essere discussi dalla comunità più in là.

Il modo in cui saranno richiamati i template nelle wiki di arrivo è una questione di infrastruttura e architettura, ma è importante affrontare anche tutti gli altri requisiti. Queste cose sono state già discusse in passato da altri utenti, come Kunal Metha (nel progetto del “namespace ombra”), Greg Grossmeier, Brion Vibber, Tim Starling e altri. Questo documento tenta di chiarire, invece, come tutto questo possa funzionare per gli utenti che utilizzano o curano un template: come scrivere un template in modo da poterlo localizzare in futuro, come tradurre un template, come configurarlo localmente, eccetera. Questi aspetti non sono stati affrontati in maniera sufficiente nelle passate discussioni in materia.

I template devono restare modificabili facilmente
Un aspetto importante dei template è che funzionano come tutte le altre pagine di una wiki: questo significa che gli effetti di qualsiasi modifica si applicano direttamente, senza revisioni o distribuzioni di sorta. Sebbene questo costituisca un pericolo (un solo edit vandalico potrebbe rovinare tante pagine), la verità è che questo sistema funziona quasi sempre bene.

Per questo, questa comodità deve essere mantenuta: gli utenti che si occupano di template molto probabilmente si rifiuterebbero di passare a un nuovo sistema che richiederebbe loro di imparare tutta una nuova serie di cose e che li costringesse a passare attraverso un'estenuante fase di revisione e distribuzione. Questo probabilmente rende l'idea di usare Gerrit non praticabile - anche se, forse, il processo di revisione e implementazione dei template sarebbe molto più veloce rispetto a quello in atto per le estensioni.

Deve essere possibile non rendere globali alcuni template
Non tutti i template devono essere resi globali per forza.

In realtà, alcuni template andrebbero considerati “locali” perché servono a garantire delle funzionalità che sono uniche di un dato progetto o di una data lingua. Per loro stessa natura, tali template non devono essere tradotti e, anzi, dovrebbe esserci un modo per segnalare ai traduttori umani e ai tool di traduzione (come Content Translation) che quei template non necessitano di traduzione e che possono essere ignorati o sostituiti.

Deve essere possibile sovrascrivere una funzionalità o la forma di un template globale
Nessuna comunità dovrebbe essere messa in condizione di pensare che una data funzionalità venga imposta da una qualche forza esterna più “potente”, come la comunità anglofona di Wikipedia, la comunità di Wikidata, la WMF o chissà chi. I template globali dovrebbero essere sviluppati e usati in modo collaborativo per il bene comune. La maggior parte delle volte questo dovrebbe funzionare per tutti.

In alcuni casi, alcune comunità potrebbero volere che un dato template abbia una certa funzionalità che funzioni in un dato modo, oppure che permetta di mostrare le informazioni in un dato modo, oppure ancora non volere una certa funzionalità. Questa capacità di prevalere localmente sulle funzioni comuni deve essere garantita (o, per meglio dire, non deve essere tolta) fin dall'inizio.

Finché esisteranno template comuni importanti che però non sono ancora globali, Content Translation dovrà continuare a supportarli. Se l'infrastruttura per i template globali venisse creata e la migrazione dei template avvenisse con un ritmo sostenuto, allora gli sviluppatori di Content Translation potrebbero considerare di interrompere il supporto (e magari, un giorno, deprecare il codice) per alcuni template non globali.

Il ritmo di migrazione dei template dalle wiki maggiori verso il repository centrale potrebbe essere uno dei parametri per misurare la buona riuscita del progetto.

Un template globale deve essere riutilizzabile immediatamente in ogni wiki
Così come una pagina utente globale è oggi disponibile in automatico in ogni wiki in cui non esiste una pagina utente locale, un template o un modulo creato tramite l'infrastruttura globale dovrà essere immediatamente utilizzabile in ogni wiki. Questo significa non copia-incollare intere pagine wiki, non creare dei template che traducano i parametri stranieri, non richiedere l'intervento di un amministratore, non aspettare ore e ore l'aggiornamento della cache, eccetera.

Deve essere possibile tradurre tutte le stringhe rivolte all'utente
MediaWiki, le sue estensioni e anche alcuni tool sfruttano translatewiki.net per tradurre in modo veloce e semplice i messaggi di sistema. Questo processo di localizzazione è sufficientemente familiare per alcuni utenti in tutte le lingue.

Al momento, non è possibile fare la stessa cosa con i template. Siti multilingua come Commons o MediaWiki.org hanno il sistema “TNT” per tradurre alcuni template, ma si tratta di un sistema molto complesso e che non può essere riutilizzato anche su Wikipedia, Wikisource, eccetera.

In teoria, dovrebbe essere possibile tradurre i template così come si traducono i messaggi di sistema, ossia usando una wiki con l'estensione Translate attiva.

La stringa tradotta dovrà essere immediatamente utilizzabile, subito dopo averla tradotta tramite l'interfaccia di traduzione.

Potrebbe essere possibile modificare le stringhe anche dalla pagina, ma in generale dovrebbe essere preferibile farlo attraverso un'interfaccia di traduzione.

Allo stesso modo, anche le pagine di documentazione dei template devono essere traducibili. Potrebbe bastare l'attuale estensione Translate per farlo, ma non si può escludere che servirà fare qualche piccolo adattamento.

In quale lingua mostrare le stringhe all'utente?
I template sono utilizzati perlopiù all'interno delle voci o delle pagine, quindi dovrebbe essere possibile mostrare di default i messaggi e i parametri nella lingua propria del progetto.

Alcuni template, tuttavia, sono utilizzati come elementi dell'interfaccia utente, quindi potrebbe essere necessario anche permettere di mostrare messaggi e stringhe nella lingua preferita dall'utente, laddove sia differente da quella del progetto.

Laddove non esista una traduzione, dovrebbe essere in generale utilizzata la normale catena di fallback di MediaWiki.

Scrittura e archiviazione dei messaggi fondamentali
Ogni messaggio dovrebbe essere rappresentato come “chiave”, similmente a quanto accade oggi per i messaggi di MediaWiki, delle estensioni e dei tool.

Scrivere stringhe traducibili sarà probabilmente il cambio maggiore da affrontare nel processo di sviluppo dei template. Le stringhe fisse dovranno essere gestite separatamente e spostate nei messaggi, organizzati per chiave. Questo processo deve essere reso il più semplice possibile, sia per i traduttori, sia per chi effettivamente scrive i template, altrimenti nessuno di loro accetterà di usare queste funzioni e, anzi, rifiuteranno di farlo.

Per fare in modo che le chiavi siano uniche globalmente, è forse plausibile inserire automaticamente il nome globale del template nella chiave del messaggio.

Riorganizzare i messaggi
L'estensione Translate organizza i messaggi per gruppi, i quali a loro volta sono suddivisibili in sotto-gruppi: per esempio, “Article Placeholder”, “Score” e “Poem” sono tutti sotto-gruppi che si riferiscono alle estensioni corrispondenti di MediaWiki e che sono tutti inclusi nel gruppo “Estensioni usate da Wikimedia - Avanzate”, assieme a tante altre estensioni.

I progetti che riguardano le estensioni di MediaWiki sono configurati tramite appositi file YAML su Translatewiki.org e mostrati, attraverso l'interfaccia di traduzione, che permette di selezionare un determinato gruppo di messaggi relativi a un determinato progetto.

Siccome ci sono molti più template che estensioni, potrebbe essere necessario fare delle modifiche all'attuale sistema di traduzione dei messaggi, in particolare nella gestione dei gruppi di messaggi.

Ogni template dovrebbe costituire un gruppo di messaggi a sé. Template simili fra loro dovrebbero poi essere aggregati in macro-gruppi, un po' come succede oggi con le categorie (anzi, si potrebbe ricopiare in parte l'attuale sistema di categorie). Utilizzare un repository Git per organizzare questi messaggi è probabilmente una soluzione non efficiente, perché troppo complessa e lenta.

Sarebbe carino mostrare nomi di template e gruppi nella lingua preferita dall'utente, ma andrebbe bene ugualmente mostrare la versione in inglese. Quello che va bene ai traduttori delle estensioni, andrà bene anche ai traduttori dei template.

Come trovare un template da tradurre
Ogni manuale di template deve avere un link diretto all'interfaccia di traduzione nella lingua dell'utente.

Alcune note sui moduli
I moduli Lua possono caricare e analizzare le stringhe traducibili di MediaWiki, ma non c'è un modo ben definito per centralizzare queste stringhe per quei moduli Lua ospitati sulle pagine wiki. Si potrebbe impacchettare i moduli Lua come parti di estensioni, per permettere loro di caricare le stringhe traducibili dai rispettivi file i18/*.json, ma questo avviene in pochissimi casi.

Riscrivere da capo i template in Lua potrebbe essere una soluzione più sostenibile sul lungo periodo, anche da un punto di vista tecnico, ma non necessariamente tutti gli utenti potrebbero voler utilizzare Lua - e la cooperazione di questi utenti è cruciale per il successo del progetto, quindi questa soluzione non può essere applicata a tutti i template.

Direzione del testo
I template devono essere adattati alla direzione del testo (da sinistra verso destra o da destra verso sinistra) della wiki su cui vengono utilizzati.

Per questo, un template deve essere realizzato utilizzando il meno possibile gli allineamenti di testo a sinistra o a destra.

Per rendere più facile le traduzioni, i template comuni dei progetti più grandi devono diventare globali
La lingua più utilizzata come base per le traduzioni tramite Content Translation è, di gran lunga, l'inglese. Seguono lo spagnolo, il russo, il francese, il tedesco, il catalano, l'ucraino, il cinese e il portoghese. Per questo, ha senso che i template più comuni di queste lingue (e in particolare quelli in inglese) siano quelli che più di tutti devono essere resi globali, per il bene di tutte le altre comunità.

Paradossalmente, gli utenti di queste comunità più grandi sono anche quelli meno interessati a raggiungere quest'obiettivo:


 * perché il template funziona bene per loro, quindi non c'è un motivo apparente per sforzarsi di rendere più facile la traduzione in altre lingue;
 * perché riscrivere un template per renderne più facile la traduzione potrebbe richiedere molto tempo e potrebbe costringerli a doversi caricare nuove o differenti responsabilità nella manutenzione;
 * perché ampliare il numero di progetti che usano un determinato template potrebbe rendere più difficile in futuro raggiungere un consenso sulle modifiche necessarie.

Questa è una considerazione più pratica e più rivolta alle relazioni fra le comunità che tecnica, ma anche queste cose vanno prese in considerazione quando si prendono decisioni che impattano sull'architettura tecnica di un sito. Se non lo si facesse, l'intero progetto potrebbe fallire miseramente.

Deve essere possibile usare i template sia con il wikitesto, sia con il Visual Editor
Questo è un concetto ovvio, ma lo si ribadisce ugualmente: la possibilità di modificare una pagina in formato wikitesto rimane, così come la possibilità di modificare un template così come si è fatto finora. Semplicemente, non deve diventare più complesso di com'è ora.

Tuttavia, Visual Editor viene utilizzato sempre più da utenti nuovi e vecchi, quindi ogni template deve funzionare (e funzionare bene) sia in modalità wikitesto, sia col Visual Editor.

Localizzazione dei parametri
I nomi dei parametri sono differenti in ogni lingua. Solitamente, si basano sulle parole corrispettive nelle differenti lingue, quindi è importante tenere quest'aspetto in considerazione per modificare comodamente la trasclusione nella sintassi wiki.

In teoria, un template globale dovrebbe avere dei nomi generici per i parametri per permetterne la traduzione in differenti lingue. Questo è, in un certo senso, alle etichette delle proprietà di Wikidata, ma si potrebbe rendere ancora più semplice: dal momento che l'inglese è una sorta di lingua franca per gli sviluppatori di software e che i template sono una sorta di software, si potrebbe utilizzare l'inglese come lingua di default al posto di numeri generici (come succede in Wikidata).

Le traduzioni dei parametri comunque vanno validate, per cui:


 * non devono contenere caratteri non validi;
 * non devono essere ripetuti più volte all'interno della stessa traduzione di un template;
 * ...altro?

Parametri senza nome
I parametri numerici e senza nome di un template devono, ovviamente, continuare a funzionare.

Tuttavia, bisognerà affrontare il problema di come localizzare questo tipo di parametri.

Tradurre i valori dei parametri
Oltre a rendere condivise le funzionalità e il design dei template, bisogna pensare alla possibilità di rendere anche i valori dei parametri condivisi - o non condivisi.

Some parameter values are the same in all languages by their nature. For example an IPA pronunciation of a place’s native name (e.g. [dɛn ˈɦaːx] for The Hague), the year of foundation of a city, the chemical formula of a compound, etc. At least some of these should probably be stored in Wikidata and easily loadable in a template.

Some parameter values have to be translated or transliterated, for example people’s names, translations of country mottos, etc.

Global templates must make this possible, but in practice, these things are still often copied across wikis, and this must be taken into account as well.

Some parameter values can be reliably and predictably converted automatically, and the global templates infrastructure must support this. For example, number formats and digit characters are often different in Burmese, in languages of India, and in some other languages, but they can be reliably converted using simple software.

Un template può avere un nome diverso per ogni lingua, ma deve essere comunque connesso a un repository centrale
Similarly to parameter names, templates may have different names in different languages, and this must be preserved. There must be a structured way to translate template names. Perhaps Wikibase sitelinks can play a role, but not necessarily.

If this is not done, editors will either avoid global templates, or wrap the global template in a local template with a translated name, and this will probably cause the template to lose the connection to the global entity. This is not desirable and misses the whole point of the project.

Funzionalità extra
Ci sono delle funzionalità extra dei template che devono continuare a funzionare (e che, per farlo, potrebbero necessitare di qualche aggiustamento) nell'era dei template globali.

TemplateData

 * Template description must be translatable, just like other user interface strings.
 * Parameter names, aliases, and descriptions must be centrally translatable.
 * Wikitext format parameter (inline, block, custom) must keep working.

TemplateStyles

 * There must be a possibility to write Template Styles pages in the same central repository as templates. The central style must be loaded by default, and it must be possible to override it locally.

TemplateSandbox

 * Special:TemplateSandbox must keep working.
 * It must be possible to edit a template in the central repository and preview it in a page in the target wiki.

TemplateWizard

 * Uses a wiki’s standard search to find templates. The results are presented in a list that might need to be changed to make the global/local status visible.
 * TemplateWizard gets its information for templates from the TemplateData API, so as long as that keeps returning the same structure there shouldn’t be any issues, and i18n is already working.

Wikibase

 * Wikidata can be used to bring in some parameter values from a central repository to the wiki. This is used productively in several wikis, among them French, Hebrew, Basque, Catalan, Estonian, and some others, although the actual implementation may differ. This must continue working, of course. Unifying the way in which it is done across different wikis may become one of this project’s most significant impact areas.
 * It may also affect the project of editing template values from within wikis.

VisualEditor

 * VisualEditor obviously needs to be able to insert both global and local templates.
 * VisualEditor shows a link to the template description page in the template editing dialog. This link should point directly to the global template when it is used.

Rendere i template riutilizzabili anche su progetti non Wikimedia potrebbe essere una buona idea
Even though it doesn’t directly benefit Wikimedia projects, it may make sense to consider making templates easily reusable not only across Wikimedia projects, but also on other MediaWiki sites. Doing this will probably require some more work, but it may contribute to better modularization, and this may eventually benefit Wikimedia projects, too.

This is comparable to the capability of direct embedding of images from Commons on non-Wikipedia websites.

Immagina un mondo
Immagina un mondo in cui ogni singolo essere umano possa condividere la somma della conoscenza umana - e in cui sia semplicissimo farlo perché i template sono diventati globali.

(Nota: quanto scritto nell'ultima colonna parte dal presupposto che l'infrastruttura di base esista per tutti i progetti Wikimedia e che i template più utilizzati siano centralizzati)

Stato della proposta
Come già scritto all'inizio, allo stato (ottobre 2019) questa pagina descrive soltanto una bozza di idea e non costituisce alcun impegno da parte di alcuno a realizzare un qualsivoglia progetto in tal senso.

The Platform Evolution project (2018) indicated some intentions to have support for global templates in the future. The page Platform Evolution/Recommendations discusses ideas for updating content modularity, and says:
 * ... “boxes” are an ideal focus area for creating modularity. They represent self contained features and also an opportunity to enable equitable sharing of user features across projects and languages be establishing a cross-project service to share templates. This project will also force us to consider how to handle content layout and structure separately from composable pieces content.

The closely related page Platform Evolution/Goals lists this as one of the goals:
 * Increase equity and power of contribution tools. We want to support the contribution of more content types of content, including media, in more interactive ways and across all projects. This means making some existing tools - like templates - available for consistent reuse across all projects and languages. It also means improving translation tools to remove silos of content. Finally, we also want to make it easy for contributors to create new cross-project, localizable content tools.

Other than these goals, however, there is no detailed plan for how such a feature will work. This page is an attempt to propose such an idea and listen to feedback from editing communities.

Link utili
Pagine che discutono argomenti simili a questo:
 * Platform Evolution/Goals
 * Platform Evolution/Recommendations
 * Multilingual Templates and Modules - un tentativo di realizzare una funzione di template e moduli globali tramite bot
 * meta:Community Wishlist Survey 2015/Results - la proposta per un repository centrale per template, moduli Lua e gadget globali arrivò al terzo posto nella classifica di quell'anno, è stato segnalata come "in fase di sviluppo", ma ancora non se n'è fatto niente