Global templates/Proposed specification/it

  Татары, узбеки и ненцы И весь украинский народ, И даже приволжские немцы К себе переводчиков ждут. И может быть в эту минуту Меня на турецкий язык Японец какой переводит И в самую душу проник. —Осип Мандельштам

Questa è una bozza per definire una proposta di requisiti minimi per i template e i moduli globali.

You can also read a one-page version of this proposal.

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

The eventual goal is to form a cross-team and cross-project commitment on implementing these things, with proper architecture, product and project management, community engagement, etc.

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


 * 1) che creano e curano template e moduli;
 * 2) 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, Wikizionario, 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 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 “riutilizzare” in un altro progetto ciò che si è imparato su un 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.

The most commonly reported issues in Content Translation are about templates.

Content Translation has a template adaptation feature, which automates some parts of this process, but it works only if a corresponding template exists in both languages, and if all the parameters were meticulously mapped by the template maintainers. This must be done for each template in each language separately and manually, and continuously maintained when the source template changes. This happens even though the templates’ function across the languages is the same most of the time.

Ideally, the templates and their parameters should be transferred to the translated page almost completely automatically, so that the translators could focus on writing the prose, as writing the prose is the area where human work is most needed.

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.

Templates mix together algorithmic logic, human-readable text strings, and formatting. Because of this there is no robust way to translate the templates’ user interface strings, as it is done with core and extensions.

Difficulties for editors in smaller wikis
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).

Difficoltà per gli sviluppatori di software
Per coloro che sviluppano codice per MediaWiki o le sue estensioni, bot o altri mezzi per analizzare, generare o modificare contenuti nelle pagine wiki è difficile sviluppare caratteristiche che dipendono dalla presenza o meno di un determinato template in una wiki. Gli sviluppatori di estensioni come GrowthExperiments, PageCuration, ContentTranslation, alcune componenti di Wikibase e così via, hanno la necessità di testarle in ambiente di produzione (che è una pessima idea) o di importare i template necessari sulle proprie wiki o su una wiki di test.

I ricercatori che estraggono dati sui contenuti wiki basandosi sui template sono spesso costretti a scrivere uno script separato per ogni wiki, così che spesso e volentieri si limitano a un progetto solo. Un esempio abbastanza eclatante è l'utilizzo dei template di progetto su Wikipedia in inglese per analizzare gli argomenti delle voci e valutarne la qualità.

Extensions vs Templates: Similarities and differences
One of the main assumptions of this project proposal is that templates and modules are very similar to MediaWiki core and extensions: They are software, and they implement features that the editors community needs. In particular, since templates are usually developed by the editors themselves, it’s obvious that the community really needs them. The big differences between lie in how they are developed, localized, and deployed.

Templates and modules should become similar to extensions in some key properties that they currently lack, and preserve some good properties that extensions lack. (For ease of understanding by English readers, in the table, examples of templates are given from the English Wikipedia. They could also come from any other wiki and any other language.)

Competenze nel creare template e moduli
Un'altra importante serie di considerazioni su cui si basa questa proposta è la seguente:
 * Saper sviluppare un template o un modulo non è banale, dal momento che entrambi hanno un sacco di funzionalità complesse.
 * Anche se molte delle funzionalità più importanti sono implementate tramite modelli e moduli, queste competenze sono spesso sottovalutate e date per scontate.
 * Ci sono decine di utenti, sparsi per le varie wiki, che hanno queste abilità. Tuttavia, spesso si concentrano sulla propria wiki e comunicano relativamente poco con gli utenti di altre comunità o progetti. Anche se la tecnologia di base è la stessa ovunque, non c'è nessuna vera comunità globale di sviluppatori di template che sia paragonabile alla comunità globale di sviluppatori di MediaWiki. Esistono dei casi di collaborazione cross-wiki su alcuni template, ma sono pochissimi e poco coerenti fra loro.
 * Ci sono anche molte wiki in cui non ci sono utenti che posseggono queste abilità. Questi possono limitarsi a copiare template e moduli da altre wiki, senza però comprendere appieno come funzionino o senza la possibilità di tradurli o mantenerli in modo efficace, oppure ancora potrebbero non usarli affatto.

Questa situazione è ben lontana dall'essere ottimale. Le competenze degli sviluppatori di template e moduli necessitano di essere maggiormente apprezzate, perché sviluppano funzionalità davvero necessarie che sono parte integrante delle loro comunità. In molte wiki di lingue diverse, gli sviluppatori di template inventano nuovi modi di strutturare, presentare e modularizzare dati e contenuti. Queste innovazioni potrebbero essere utili in tante wiki, ma non esiste ancora un meccanismo adeguato per raggiungere questo obiettivo.

E, naturalmente, qualsiasi soluzione a questi problemi non deve proporre tecnologie completamente nuove che mettano da parte anni di esperienza pratica acquisita dagli sviluppatori di template. Pertanto, bisognerà apportare il minor numero possibile di cambiamenti nella sintassi per lo sviluppo di template e moduli. Quello che deve cambiare è il modo in cui vengono distribuiti e riutilizzati fra le varie wiki e il modo in cui le stringhe di testo vengono tradotte.

The proposed solution: Summary
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.

It must be possible to store templates and modules in a global repository, too, and to localize them as robustly as it is done with extensions.

Global templates and modules will empower template maintainers in all wikis by letting them collaborate more easily on developing the templates’ code.

Global templates and modules will empower translators and localizers by allowing them focus on translating just the user interface strings (“messages”), without having to look for strings in the code, and by allowing them to use the same skills and tools for translating templates and MediaWiki extensions.

Global templates and modules will empower content editors in all wikis to write and translate content that uses these templates without having to dive into the differences and to relearn different rules and skills in each wiki.

The syntax for developing templates and modules, and the general template maintenance and deployment cycle will not change, so all the skills that the template maintainers have acquired over the years will remain relevant.

All wikis will be able to use the global templates, but not forced to do this. Communities will keep their capability to override any global functionality, design, workflows, and data.

Localizing templates will be as convenient as localizing MediaWiki extensions.

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 template generico. 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 fortemente semantici, nel senso che il software che elabora le pagine non è mai stato in grado di gestirli facilmente.

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 un sacco di codice per configurare Citoid sulla wiki che intende utilizzarlo);
 * 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, vedi anche );
 * 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 migliaia 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: per la maggior parte degli utenti, modificare una pagina wiki è molto più semplice e immediato 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 sviluppatori, per esempio riguardo il cosiddetto nel progetto del “namespace ombra”. Questo documento tenta di chiarire, invece, come tutto questo possa funzionare per gli utenti che modificano una pagina che utilizza un template o per coloro che gestiscono quel template: come scriverlo in modo da poterlo localizzare in futuro, come tradurlo, 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. Questa considerazione rientra nello sforzo di rendere i template più semantici.

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.

Sometimes some communities will have strong opinions about wanting to have particular functionality or design that will be different in their language or project, or to show an infobox with information that is different from what is shown in other projects, or not to show it at all. The capability to override things locally must be allowed from the start. (Or rather, it must not be taken away.)

Un template globale deve essere immediatamente utilizzabile 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 che non devono esserci passaggi extra, come dover copia-incollare intere pagine wiki, creare dei template che traducano i parametri stranieri, richiedere l'intervento di un amministratore, aspettare ore e ore l'aggiornamento della cache, eccetera.

Una volta aggiornata la versione centralizzata, i cambiamenti verranno mostrati immediatamente ovunque. Per prevenire vandalismi, la comunità provvederà ad adottare linee guida sulla protezione delle pagine e sulla possibilità di modificarle.

Qualora le stringhe di interfaccia (o “messaggi”) non siano ancora tradotte, il template sarà comunque utilizzabile e le stringhe mostrate nella lingua di fallback (per maggiori dettagli, si rimanda al paragrafo sulla localizzazione).

Deve essere possibile tradurre tutte le stringhe rivolte all'utente
Le stringhe di interfaccia (anche conosciute come “messaggi”) di MediaWiki, delle sue estensioni e di alcuni tool (come Pageviews) 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 dove è attiva l'estensione Translate.

La stringa tradotta dovrà essere 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.

I traduttori dovrebbero essere in grado di concentrarsi esclusivamente sulla traduzione del testo. La presenza di codice rende più difficile contribuire a coloro che non hanno esperienza di programmazione o con i file JSON. Inoltre, modificare le traduzioni in lingue scritte da destra a sinistra in file di testo non elaborati è estremamente scomodo. L'estensione Translate risolve già tutti questi problemi.

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. Questo potrebbe essere ancora più importante in siti multilingua come Commons, Wikidata, Meta e Mediawiki.org.

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, si potrebbe inserire automaticamente il nome globale del template nella chiave del messaggio.

Tool di transizione
Si potrebbe sviluppare un tool che possa aiutare nella transizione verso template o moduli globali, che compia indicativamente i seguenti passaggi:
 * 1) esportare il template da una wiki e importarlo nella wiki globale;
 * 2) esportare a cascata tutti gli eventuali template aggiuntivi utilizzati dal primo template;
 * 3) identificare le stringhe, convertirle in una lista di chiavi e contemporaneamente sostituire all'interno del codice le stringhe con le chiavi corrispondenti;
 * 4) importare la documentazione e il TemplateData relativi al template.

In molti casi, questo processo automatizzato non basterà a creare un modulo o template pienamente utilizzabile da subito, ma almeno aiuterebbe molto nel processo di transizione.

Organizzare i messaggi
L'estensione Translate organizza i messaggi per gruppi (anche detti “progetti”), 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 apportare delle modifiche al sistema con cui l'estensione Translate gestisce attualmente i gruppi di messaggi, per poterlo adattare anche alla traduzione di template.

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.

I template devono essere mostrati come gruppi di messaggi sulla pagina speciale dedicata alle statistiche (Special:LanguageStats) dell'estensione Translate. Questo aiuterà i traduttori a capire quali siano i template che necessitano di essere tradotti. Teoricamente, questa cosa dovrebbe funzionare come qualsiasi gruppo di messaggi, ma ci sono delle considerazioni aggiuntive da fare:
 * Ci saranno migliaia di template, quindi sarebbe bene che il design della tabella sia più o meno corrispondente.
 * La tabella dovrebbe mostrare su quante voci o pagine ciascun template è utilizzato, rendendo possibile ordinare le righe per questo parametro, in modo da poter capire quali template siano prioritari nella traduzione.

Capire come tradurre un template
Ogni manuale di template deve avere un link diretto all'interfaccia di traduzione nella lingua dell'utente.

Some templates use Wikidata labels as part of their UI instead of hard-coding strings. This is done at the moment in Wikidata Infobox on Commons, Infotaula persona (Infobox person) in the Catalan Wikipedia, and in several other templates. These labels and values can be localized in Wikidata itself. Such usage cannot cover all the needs of template localization, but it is legitimate and useful for particular purposes. As long as this is properly described in the template documentation, this can continue to be used, and probably doesn’t need special infrastructure adaptations. (Perhaps the translation of the relevant labels and values can be somehow integrated into the Translate interface for localizing the template, but this is optional.)

Parametri e “parole magiche” dei messaggi
Molti messaggi di MediaWiki e delle sue estensioni usano dei parametri (talvolta chiamati anche “segnaposto” o “placeholder”). Sono indicati come “$1”, “$2”, “$3”, eccetera e sono riempiti nel tempo di esecuzione. Questi segnaposto sono particolarmente importanti per facilitare la traduzione dei messaggi, perché lingue diverse hanno un ordine delle parole diverso.

Una funzione del genere servirà anche per i template globali - non necessariamente in forma “$1” o “$2”, si potrebbe adottare anche una forma più simile a quella dei template, ossia con le triple parentesi graffe ( { – } ). Questo aspetto va deciso dopo aver considerato anche le necessità relative al parsing e alla localizzazione.

Tuttavia, le “parole magiche” PLURAL, GENDER e GRAMMAR devono essere supportate anche per i messaggi dei template, così come lo sono per i messaggi di MediaWiki.

Documentazione dei messaggi
I messaggi traducibili di MediaWiki e delle estensioni hanno la possibilità di essere documentati, per la comodità di sviluppatori e traduttori. La documentazione include informazioni su dove appaiano i messaggi, spiegazioni sui parametri, se il parametro è un verbo o un aggettivo, eccetera. Questa documentazione è memorizzata come uno pseudo-linguaggio con il codice “qqq”.

Una documentazione del genere sarebbe utile anche per i template. Come memorizzarla rimane un problema di architettura tecnica - forse si potrebbe utilizzare TemplateData, forse si potrebbe utilizzare il codice qqq, forse si potrebbe adottare un'altra soluzione.

Lingua originale
I template che saranno importati sulla piattaforma globale non proverranno solo dai progetti in lingua inglese, ma anche da progetti in altre lingue. A maggior ragione, i tool di traduzione e localizzazione devono supportare la traduzione da e verso ogni lingua e non solo da e verso l'inglese.

Messaggi obsoleti
Qualora un messaggio di MediaWiki o di un'estensione venga aggiornato nella sua versione inglese, il messaggio viene automaticamente marcato come obsoleto, tramite un'evidenziazione in rosa. La traduzione, laddove presente, continua a funzionare, ma viene mostrato ai traduttori come “da aggiornare” (anche se il responsabile della traduzione può anche contrassegnarlo come “non da aggiornare”).

Un meccanismo simile sarà necessario per la localizzazione dei template. Tuttavia, siccome sarebbe bene non costringere gli utenti ad adottare l'inglese come lingua di partenza, ci dovrebbero essere altri metodi di segnalare i messaggi come da aggiornare.

Considerazioni sulla traduzione dei 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 i messaggi 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.

Alcuni moduli tecnici e molto specifici che vengono comunemente utilizzati, raramente modificati e che non richiedono internazionalizzazione (come, per esempio, No globals e Arguments) possono probabilmente essere spostati senza grossi problei all'interno dell'estensione Scribunto.

Un template può avere un nome diverso per ogni lingua, ma deve essere comunque connesso a un repository centrale
Global templates and modules are supposed to be immediately usable in all wikis without any extra steps, so it must be possible to transclude a global template in a local wiki page using its global name. The cross-wiki editors community shall decide what will be the policy for these global names.

Come per i parametri, anche i template possono avere nomi differenti a seconda della lingua. Questa è una caratteristica che deve essere mantenuta e dovrà essere individuato un modo per tradurre il nome dei template. Forse Wikidata potrebbe avere un ruolo in questo, ma non necessariamente.

Se questo non viene garantito, gli utenti eviteranno di usare i template globali, li ingloberanno all'interno di template locali o utilizzeranno altre soluzioni che comunque interromperanno il contatto con il template globale. Questo non solo non è desiderabile, ma è completamente l'opposto di quanto si prefigge questo progetto.

Template names must only be translated to languages that can be content languages of wikis. Translation to Formal German or British English are probably unnecessary. There may be a way to have aliases or redirects. Language variants, for example for Serbian and Chinese, must be supported according to these languages’ needs.

If a local template exists in a wiki and it has the same name as a localized name of a global template, the local template will be used. This is similar to how local files with identical names override global files on Commons, and how local messages in the MediaWiki space override the localization coming from the code.

Lua module names are often localized, too. Their names can be localized for direct invoking from wiki pages, but since code usually uses English-like identifiers, the internal global names should probably be preferred for use in the code itself, for example in  statements.

Traduzione dei nomi 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 all'interno dello stesso template;
 * ...altro?

Il processo di traduzione dei nomi dei parametri potrebbe, alla fine, risultare diverso da quello delle stringhe di interfaccia. I primi hanno dei vincoli tecnici da rispettare e devono rimanere stabili: in altre parole, cambiare il nome a un parametro potrebbe causare problemi alle inclusioni esistenti, quindi dovrebbero esserci dei meccanismi di salvaguardia in proposito.

Automatic parameter translation
If the localized template names and all the localized parameter names are stored centrally, it will possible to have a simple service that gets a valid template with parameters, a source language name, and a target language name, and outputs a localized template. For example:

Input:

Output:

In visual editing and in 2017-style wiki syntax editing, simply copying and pasting a template from wiki in another language will do the parameter translation automatically.

For plain wiki syntax editing, there should be a simple way to operate this service, for example a special page or a dialog box where an editor can paste the template and the source language, and get the template with translated parameters.

In both cases only the names of the template and the parameters will be translated. Translating the parameter values is discussed separately.

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.

Alcuni valori sono gli stessi in tutte le lingue per loro stessa natura, come per esempio la pronuncia fonetica di un dato posto (per esempio, [dɛn ˈɦaːx] per L'Aia), l'anno di fondazione di una città, la formula chimica di un composto, eccetera. Almeno questi dovrebbero direttamente essere inseriti in Wikidata e da lì richiamabili all'interno del template.

Altri parametri, invece, dovranno essere tradotti o anche traslitterati, come per esempio i nomi propri di persone o di cose, i motti degli Stati, eccetera.

I template globali dovrebbero rendere tutto questo possibile, ma bisogna anche ricordarsi che è ancora pratica comune copiare e incollare queste informazioni da una wiki all'altra.

Alcun parametri possono essere facilmente tradotti o localizzati in modo automatico e l'infrastruttura dei template globali deve poter supportare questa funzionalità. Per esempio, numeri e cifre sono lievemente differenti rispetto ai nostri in birmano, in varie lingue dell'India e in altre lingue, ma questa cosa potrebbe essere tranquillamente gestita dal software.

I valori validi e funzionali dei parametri devono essere riutilizzabili in più lingue e non essere relativi a una sola. Per esempio, usare “yes” o “no” come valori booleani è troppo anglo-centrico: un cambio del genere non richiede probabilmente cambiamenti nell'infrastruttura, ma più probabilmentete un accordo nella comunità globale di sviluppo di template, riguardo come adattare un template perché serva più lingue.

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.

Bot
Molti template in molte wiki sono regolarmente modificati da bot. Questa possibilità deve essere mantenuta.

Questo non dovrebbe richiedere alcun cambio nell'infrastruttura attuale del software, ma viene comunque citato perché è un caso di utilizzo molto importante.

Transizione dei template dalle wiki più grandi al repository centrale
 וּמֵעֵבֶר לְשׁוּרַת הַבְּרוֹשִׁים עָבְרָה הָרַכֶּבֶת אֲבָל אֲנַחְנוּ רַק שָׁמַעְנוּ אוֹתָהּ, וְלֹא רָאִינוּ. וְכָל הַדְּבָרִים שֶׁדִּבָּרְנוּ בֵּינֵינוּ הִתְחִילוּ בַּמִּלִּים, „אֲבָל אֲנַחְנוּ”. —יהודה עמיחי La lingua più utilizzata come base per le traduzioni tramite Content Translation è, di gran lunga, l'inglese, seguita dallo spagnolo, dal russo, dal francese, dal tedesco, dal catalano, dall'ucraino, dal cinese e dal portoghese. Per questo, ha senso che i template più comuni di queste comunità linguistiche (e in particolare quelli della versione 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é rifare da capo 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 su delle eventuali modifiche necessarie;
 * Editors from different major wikis will have to work on reaching consensus about merging some templates.

Più che una considerazione tecnica, si tratta di una considerazione pratica e rivolta alle relazioni fra le comunità. Tuttavia, anche questi aspetti vanno presi in considerazione quando si prendono decisioni che hanno un impatto sull'architettura tecnica di un sito. Se non lo si facesse, l'intero progetto fallirebbe miseramente.

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.

Deve essere possibile utilizzare i template sia con la sintassi wiki, sia con Visual Editor
Questo è un concetto ovvio, ma lo si menziona lo stesso: 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 con Visual Editor.

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.

Core MediaWiki
There should be on-wiki tools for showing at least basic analysis of templates’ and modules’ usage on pages: the number of transclusions and invocations grouped by wiki, and lists of pages that use the templates and the modules. The feature that shows which templates does a page transclude while it’s being edited must continue working with global templates.

The What links here page must keep working, and remain useful for global transclusions.

TemplateData

 * È possibile tradurre le descrizioni dei template e dei parametri in TemplateData e visualizzare le traduzioni nella lingua scelta dall'utente nella finestra di dialogo apposita di VisualEditor. Questa è una buona funzione che va preservata. L'interfaccia può essere ovviamente migliorata, ma almeno si parte da una buona base. L'aggiunta di un supporto per TemplateData nell'estensione Translate può essere una potenziale soluzione, ma non necessariamente l'unica.
 * I parametri di formattazione in wikitesto (inline, block, custom e così via) devono continuare a funzionare. Allo stesso modo, dovrebbe essere possibile per le singole wiki personalizzare questi parametri - per esempio, alcuni progetti potrebbero preferire vedere scritto il template su un'unica riga, altri potrebbero preferire vederlo scritto su più righe.

TemplateStyles

 * Deve esserci la possibilità di realizzare delle sottopagine per gli stili di un template all'interno dello stesso repository dei template, che possano essere richiamabili automaticamente di default ed eventualmente sovrascribili in locale.

TemplateSandbox

 * Special:TemplateSandbox deve continuare a funzionare.
 * Deve essere possibile modificare un template nel repository centrale e vedere in anteprima l'effetto delle modifiche su una determinata pagina di una determinata wiki.

TemplateWizard

 * L'attuale sistema di ricerca si basa sul motore di ricerca wiki. La lista dei risultati dovrà in futuro essere adeguata, per mostrare se il template è locale o globale.
 * TemplateWizard prende le informazioni sui template dalla API di TemplateData, quindi finché si continua a mantenere questa struttura, non dovrebbero esserci problemi. Inoltre, la localizzazione già funziona.

Wikibase

 * Wikidata può essere utilizzato per richiamare alcuni valori dal repository centrale alle wiki. Wikidata è già proficuamente utilizzata in varie Wikipedie (come quella francese, ebraica, italiana, basca, catalana, estone, eccetera), anche se l'implementazione varia da caso a caso. Questa funzione deve continuare a funzionare, ovviamente. Unificare il modo in cui i template richiamano determinati valori da Wikidata potrebbe essere una delle aree di maggiore impatto di questo progetto.
 * Questo potrebbe rendere più semplice l'integrazione di Wikidata Bridge, il progetto che permetterebbe di editare i dati su Wikidata tramite i template locali. Le modifiche ai template stessi sarebbero quindi effettuate solo una volta sul template locale e non su ciascuna wiki.

VisualEditor

 * Ovviamente, VisualEditor deve essere in grado di inserire sia i template globali, sia i template locali.
 * VisualEditor mostra un link alla pagina di descrizione del template nella schermata di dialogo. Questo link deve puntare ovviamente al template globale, quando usato.

Rendere i template riutilizzabili anche su progetti non Wikimedia potrebbe essere una buona idea
Potrebbe avere senso rendere i template riutilizzabili più facilmente non solo per i progetti Wikimedia, ma anche per altri siti basati su MediaWiki - anche se questo non porta direttamente benefici ai progetti Wikimedia. Questo sicuramente richiederà del lavoro aggiuntivo, ma potrebbe contribuire a migliorare la modularizzazione e, quindi, essere di beneficio anche per noi.

Una funzionalità del genere sarebbe molto simile alla possibilità per i siti non Wikimedia di richiamare le immagini da Wikimedia Commons.

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.

Il progetto “Platform Evolution” (2018) ha indicato, fra i suoi obiettivi, l'intenzione di fornire supporto in futuro allo sviluppo dei template globali. Nella pagina “Platform Evolution/Recommendations”, dove vengono discusse delle idee per aggiornare la modularità dei contenuti, c'è scritto:
 * ... i “box” sono un focus ideale per creare pagine modulari. Rappresentano funzionalità autonome, ma anche un'opportunità per consentire un'equa condivisione delle funzionalità degli utenti tra progetti e lingue, stabilendo una base tra progetti per condividere i template. Questo progetto ci costringerà anche a considerare come gestire il layout e la struttura del contenuto separatamente dal contenuto dei singoli pezzi.

Nella pagina “Platform Evolution/Goals”, fra gli obiettivi si legge:
 * Aumentare l'equità e il potere degli mezzi per contribuire. Vogliamo supportare i contributi in più modalità, compresi i file multimediali, in modi più interattivi e su tutti i progetti. Ciò significa adeguare alcuni strumenti già esistenti, come i template, per riutilizzarli in tutti i progetti e in tutte le lingue. Questo significa anche migliorare i tool di traduzione per eliminare i “silos di contenuti”. Infine, vogliamo anche rendere più semplice agli utenti la creazione di nuovi tool di contribuzione, localizzabili su più progetti.

Al di là di questi obiettivi, tuttavia, non c'è nessun piano dettagliato che descriva come questa funzione possa funzionare. Questa pagina è un tentativo di ottenere un primo feedback dalle comunità riguardo un'idea del genere.

Link utili
Pagine che discutono argomenti simili a questo:
 * Platform Evolution/Goals
 * Platform Evolution/Recommendations
 * Multilingual Templates and Modules - An attempt to implement a similar feature using bots
 * meta:Community Wishlist Survey 2015/Results - Central Global Repository for Templates, Lua modules, and Gadgets came in as #3 in the Community Wishlist vote. Listed as “In development - Parsing team”, but not actually done.
 * meta:Which templates should be global? - una lista informale, fatta da vari utenti, di template che potenzialmente dovrebbero diventare globali
 * Requests for comment/Shadow namespaces - una richiesta di pareri (attualmente inattiva) su una proposta di implementazione tecnica di tale infrastruttura
 * Manual:$wgEnableScaryTranscluding - un meccanismo esistente, ma rudimentale, per trascludere contenuti fra progetti; considerato inefficiente e non sicuro, è attualmente disabilitato sui progetti Wikimedia
 * meta:Global-Wiki - a similar proposal, with a wider scope. Was open for discussion for several years, and closed as "consensus". Some things in it were implemented, such as global user pages and preferences, but it also includes global templates, which are not yet done.