Global templates/Proposed specification/it

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

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

Una sintesi di questa proposta si può trovare qui.

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

This document does not try to go into the details of technical implementation in terms of storage, caching, delivery, PHP code design, etc. It only tries to define the requirements of how this feature will work from the point of view of the users:


 * 1) People who create and maintain templates and modules.
 * 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) * All levels of experience: From those who are completely new to those who have made thousands of edits
 * 4) * All kinds of editing tools: wiki syntax editing, Visual Editor, Content Translation, and others (even bot operators)
 * 5) * All wikis: Wikipedia, Wiktionary, Wikivoyage, Wikidata, Incubator, etc., and any new future projects
 * 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 la funzione “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 questa funzione. 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).

Difficulties for software developers
For developers of MediaWiki core, extensions, bots, and other tools that analyze, generate, or modify wiki page content it is difficult to develop features that depend on the presence of certain templates in a wiki. Developers of extensions such as GrowthExperiments, PageCuration, ContentTranslation, some components of Wikibase, and many others, have to either test them in production, which is a bad idea, or to import the templates to their local wikis or an online test wiki.

Researchers who get data about wiki content based on templates have to write their analysis code for each wiki separately, and sometimes they end up doing for only one wiki. A notable example is using English Wikipedia’s WikiProject templates to analyze page topics and assess article quality.

Estensioni e template: similitudini e differenze
Uno dei principi di fondo di questa proposta è che template e moduli siano estremamente simili al codice di Mediawiki e delle sue estensioni. Parliamo, cioè, di un software che permette di implementare funzionalità che servono a una comunità di utenti - e questo è a maggior ragione vero per i template, che vengono sviluppati proprio dagli utenti in risposta alle proprie necessità. La differenza fra loro, tuttavia, è nel modo in cui vengono sviluppati, tradotti e implementati.

Template e moduli dovrebbero assomigliare di più alle estensioni per alcuni versi, mantenendo tuttavia determinate particolarità che al momento mancano alle estensioni. Facciamo qualche esempio:

Templates and modules development skills
Another important set of assumptions on which this proposal is based is the following:
 * The skills for developing templates and modules are non-trivial. Both templates and modules have a lot of obscure features.
 * Even though many of the sites’ most notable features are implemented as templates and modules, these skills are often underappreciated and taken for granted.
 * There are dozens of people who have these skills, and they edit many different wikis. They usually focus on their home wiki and relatively rarely communicate with people from other wikis or other languages. Even though the underlying technology is the same everywhere, there is no true global community of template developers that would be comparable to the global community of MediaWiki core and extensions developers. There are cases of cross-wiki collaboration on certain templates, but they are inconsistent.
 * There are also many wikis in which there are no editors who have these skills. They either copy templates and modules from other wikis without fully understanding how they work and without the ability to localize and maintain them effectively, or they don’t use templates at all.

This situation is far from optimal. The template and module developers’ skills need more appreciation. They develop truly needed features, and they are embedded in their editors communities. In wikis in many languages, the template developers come up with innovative features for structured content, data presentation, and modularization. These innovations could be useful in many wikis, but currently there is no convenient mechanism to achieve this.

And of course, any solution for these problems must not come up with completely new technologies that will discard the many years of hands-on experience that the template maintainers have acquired. Hence, there must be as few changes as possible in the syntax for developing templates and modules. The things that need to change are the way in which they are deployed and propagated across wikis, and the way in which the human-readable strings in them are localized (translated).

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 agli sviluppatori di template in tutte le comunità di collaborare più facilmente allo sviluppo del codice.

Template e moduli globali permetterebbero ai traduttori di focalizzarsi sulla traduzione delle sole stringhe di interfaccia (i “messaggi”), senza doverle cercare nel codice e usando lo stesso metodo che si usa per tradurre le estensioni di MediaWiki.

Template e moduli globali permetterebbero agli utenti di tutte le wiki di scrivere e tradurre voci da altre versioni, senza dover essere costretti ad apprendere regole e competenze diverse in ogni altra wiki per poterne tradurre anche i 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 potranno utilizzare i template globali, ma non saranno costretti a farlo. Ciascuna comunità manterrà la possibilità di sovrascrivere qualsivoglia funzionalità, aspetto grafico, dato o altro, se necessario.

Tradurre i template sarà utile tanto quanto tradurre 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 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.

Global means that a template’s code must be maintained in one place and usable in all wikis.

Making templates semantic
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.

There are few examples of templates that were made semantic:


 * Various reference templates, which are usable from the Visual Editor toolbar “Cite” button. They require writing a lot of separate code to configure Citoid on each wiki that wants to use them.
 * “Citation needed”, which is being adapted to Visual Editor as of September 2019. It also requires configuration on each wiki.
 * Templates for mentioning users in the Flow extension, which require local configuration, too.
 * Some dump processing and research tools can parse English Wikipedia’s WikiProject assessment templates, which are usually added to talk pages.
 * The PageTriage extension is configured to work with English Wikipedia’s hatnote templates (also known as “tags”).

In the case of PageTriage, the extension essentially hard-codes a single wiki’s templates, making it unusable in other wikis without a significant rewrite. Even if the on-wiki configuration step is small, as it is with the Flow example, it still needs to be done. This doesn’t scale well for the 900 wikis that Wikimedia has, and the thousands that it will have in the future.

These things should be global by default, so that they will be immediately usable in at least a basic default configuration on all wikis at once by extensions, bots, dump analyzers, etc.

Storage and delivery
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).

The best solution is probably creating a new wiki that will store them, without getting mixed up with images, general community discussion, etc.

Using Gerrit as storage for templates and modules code is technically possible, but it would lose an important element of accessibility for template maintainers: editing a template in a wiki page is much easier and familiar to the vast majority of template maintainers than making Git commits and waiting for code review. Therefore, Gerrit probably shouldn’t become a way for storing the template and module code, at least not the primary one.

Global templates and modules must be stored in a common repository that can be edited by most wiki editors. Rules about blocking and special permissions should initially be similar to the rules in other wikis: everything should be open by default, and it must be possible to protect very common, sensitive, or frequently-vandalized templates. Further rules about protection levels can be developed by the editors community later.

How the templates are delivered to the target wikis is a question of internal engineering and architecture, as long as the other requirements are addressed. These questions were discussed in the past by some platform developers, for example around the Shadow namespaces project. This document tries to address related questions of how it works for the user who edits a page that uses a template, or who maintains the template itself—how to write it in a localizable way; how is it translated; how is it locally customized; etc. These questions weren’t addressed sufficiently in the previous architectural discussions on the topic.

Templates must remain easy to modify
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.

It must be possible to make some templates non-global
Non tutti i template devono essere resi globali per forza.

In fact, some templates should be local because they implement a functionality that is unique to a certain language. By their nature, such templates don’t need to be translated, and there should be a way to give a hint to both human editors and translation tools (such as Content Translation) that they don’t need to be adapted, and can be skipped or substituted. This is a part of the effort to make templates more semantic.

It must be possible to override some functionality or appearance of a global template
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.

A global template must be immediately usable in every 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.

This must not require any extra steps, such as copying wiki pages, creating wrapper templates with a local name, administrator intervention, waiting for hours for caches to refresh, etc.

After the central version is updated, the updated version will be immediately shown everywhere. To prevent vandalism, the editors community will develop policies on permissions and protection levels.

If the user interface strings (messages) were not translated, the template will nevertheless be usable and the strings will be shown in the fallback language. See the sections on localization for more details.

It must be possible to translate all user-facing strings
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.

It’s currently not possible to do the same with templates. Multilingual sites such as Commons and mediawiki.org have the “TNT” system for translating some templates, but it’s very complicated and cannot be reused for Wikipedia, Wikisource, etc.

Ideally, it should be possible to translate templates just like core and extensions, using a wiki with the Translate extension.

The translated string must become usable immediately after the translation is submitted using the translate interface.

It can be possible to edit the user interface strings in raw wiki pages, but ideally they should be edited primarily through a dedicated translation interface.

Translators should be able to focus on translating nothing but text. Seeing any code around it makes it difficult for people who are not experienced with programming and JSON files to contribute easily. In addition, editing translations into languages that are written from right to left in raw text files is extremely inconvenient. The Translate extension already addresses all of these issues.

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.

The language in which the strings are shown to the user
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.

Some templates, however, are used as UI elements, so perhaps it makes sense to also allow showing the translated strings in the user language, when it’s different from the wiki content language. This may be particularly relevant for multilingual sites such as Commons, Wikidata, Meta, and mediawiki.org.

MediaWiki’s usual fallback chains must be used when a translation is not available.

Message keys and message storage
Ogni messaggio dovrebbe essere rappresentato come “chiave”, similmente a quanto accade oggi per i messaggi di MediaWiki, delle estensioni e dei tool.

Writing translatable strings will probably be the largest change in the template development process that template maintainers will have to get used to. Hard-coded strings will have to be separated and moved to messages organized by key. It must be made as easy as possible not only for the translators, but also for the template maintainers. Otherwise, they won’t actually do it, and the feature will be effectively rejected.

To easily make keys globally unique, it’s probably OK to automatically include the global template name in the message key.

Transitioning tools
A tool can be developed that will help the transitioning of a template or a module to central storage. It can do the following steps:
 * 1) Export a template from a local wiki and import it into the global wiki.
 * 2) Export all the templates that are used by this template (cascading).
 * 3) Identify the human-readable strings, convert them to a list with keys, and replace them with keys in the template’s source code.
 * 4) Import the template’s documentation page and TemplateData.

In most cases, this automatic process probably cannot create a fully usable and robust template or module, but it can help begin the transitioning process.

Organizing messages
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.

Projects that represent MediaWiki extensions are configured in YAML files in the translatewiki repository and shown in the Translate user interface in a project selector, also known as message group selector.

Since there are many more templates than extensions, some modifications may be needed in the way the Translate extension handles message groups to accommodate templates translation.

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.

It would be nice to show group and template names as localized in the selector, but it’s also OK if they are shown in English. If it’s good enough for extension localizers, it’s good enough for template localizers, too.

Templates must be shown as message groups on the Translate extension’s Language statistics special page (Special:LanguageStats). This will help localizers find what templates need translation. This should be generally similar to all message groups, but there are some special considerations for templates:
 * There will be thousands of templates, so it will be nice if the table’s design corresponds to this somehow.
 * The table should show on how many pages is each template transcluded and make it possible to order the rows by this number, to help localizers prioritize what is more important to translate.

Finding how to translate a template
Ogni manuale di template deve avere un link diretto all'interfaccia di traduzione nella lingua dell'utente.

Alcuni template utilizzano le etichette di Wikidata, anziché delle stringhe, come parte della loro interfaccia - come per esempio Wikidata Infobox su Commons o Infotaula persona (Infobox persona) su Wikipedia in catalano. Le etichette possono essere tradotte direttamente su Wikidata. Ovviamente, questi esempi non coprono la totalità delle necessità di traduzione dei template, ma sono legittimi e utili per scopi particolari. Fintanto che questa caratteristica sia descritta correttamente nella documentazione del template, può tranquillamente continuare a essere usata e probabilmente non necessita di adeguare appositamente l'infrastruttura. (Forse la traduzione delle etichette e dei valori rilevanti può essere in qualche modo integrata nell'interfaccia di Translate, ma questo è facoltativo.)

Message parameters and magic words
In core MediaWiki and extensions, many message have parameters (sometimes also known as placeholders). They are named $1, $2, etc. They are filled in run time. They are particularly important for making messages robustly translatable because different languages have different word order.

Something like this is needed in templates, too, although it is possible that the form does not have to be $1, $2, but template-like parameters with triple curly braces ( { – } ). This is to be decided according to considerations of parsing and localization convenience.

The magic words PLURAL, GENDER, and GRAMMAR must be supported in template messages as in MediaWiki messages.

Message documentation
In core MediaWiki and extensions, every translatable message is documented for the convenience of developers and translators. The documentation may include information about where the message appears, what the $1, $2, etc. parameters are, whether the word is a verb or an adjective, etc. This documentation is stored as pseudo-language with the code qqq.

Such documentation will be useful for template translation, too. How it is stored is a question of technical architecture—perhaps it can be combined with TemplateData, perhaps it can be stored as a qqq language, and perhaps it can be something else.

Source language
Templates will be imported to the global storage not only from English-language projects, but from wikis in many different languages. More than ever, the localization tools must support translation from any language and not only from English.

Fuzzying
In core MediaWiki and extensions and in translatable pages, if the source message in English changes, the message is automatically marked as outdated or “fuzzy”. The existing translations continue to work, but are shown to translators as needing an update. (The translation manager can also mark a message as not needing fuzzying.)

A similar mechanism will be needed for template localization. However, since it would be nice not to force English as the source language, there should be more ways to mark messages as fuzzy.

Localization considerations for modules
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.

Some very internal, technical modules that are commonly used, rarely changed, and don’t require internationalization can probably be painlessly moved into the Scribunto extension itself. Some examples are No globals and Arguments.

Un template può avere un nome diverso per ogni lingua, ma deve essere comunque connesso a un repository centrale
I template e i moduli globali dovrebbero essere immediatamente utilizzabili in tutti le wiki senza passaggi aggiuntivi, quindi deve essere possibile utilizzare un template globale in una pagina wiki locale usando il suo nome globale. La comunità wikimediana nel suo complesso deciderà le linee guida su questi nomi globali.

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.

I nomi dei template devono essere tradotti esclusivamente in lingue a cui corrisponde un progetto wiki. Traduzioni in tedesco formale o inglese britannico sono probabilmente inutili e, comunque, ci dovrebbe essere un modo di sfruttare alias e redirect. Le varianti di una lingua, come per il serbo o il cinese, vanno invece gestite coerentemente con le necessità di quella comunità linguistica.

Se esistesse un template locale con lo stesso nome (tradotto o meno) di un template globale, la priorità verrà data al template locale. Questo funzionamento è simile a quello che accade con i file di Commons o con i messaggi locali di MediaWiki: il contenuto locale sovrascrive sempre quello globale.

Anche i nomi dei moduli lua sono spesso tradotti. I loro nomi possono essere tradotti per richiamarli direttamente nei template, ma siccome spesso si utilizza l'inglese, dovrebbe essere data priorità ai nomi globali all'interno del codice, per esempio nelle dichiarazioni.

Localizing parameter names
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.

Ideally, the global template should have generic internal parameter names that have translations to different languages. This is somewhat similar to Wikidata property name labels, but it can be simpler: since English is a kind of a lingua franca for software developers and templates are a kind of software, it’s probably OK to have English as the default source language rather than generic numbers as it is in Wikidata.

These translations of parameter names must be validated:


 * they must not include invalid characters
 * they must not be repeated within one template in one language
 * Anything else?

The actual process of translating the parameter names may be different from translating user interface strings. These names have technical constraints, and they must remain stable because changing a name of parameter will break existing transclusions, so there should be some safeguards against this.

Traduzione automatica dei parametri
Se le traduzioni dei nomi dei template e dei rispettivi parametri venissero gestite centralmente, sarebbe possibile avere una funzionalità semplice che permetta di ottenere, data una lingua di partenza e una di arrivo, un template tradotto perfettamente utilizzabile. Per esempio:

Input:

Output:

Con il Visual editor o con la wikisintassi introdotta nel 2017, copiare e incollare un template da una wiki in un altra lingua permette di effettuare la traduzione dei parametri automaticamente.

Dovrebbe tuttavia esistere un modo semplice di realizzare questo anche per chi usa la wikisintassi normale - per esempio, utilizzando una pagina speciale o un box di dialogo dove un utente può incollare il template e selezionare la lingua di origine, ottenendo un template con i parametri tradotti nella sua lingua.

In entrambi i casi, sarebbero tradotti solo il nome del template e dei parametri. La traduzione dei valori dei parametri è discussa in un'altra parte del documento.

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

A decision is needed about how will their names be localized.

Translating parameter values
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.

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.

Valid and functional parameter values must be usable in multiple languages and not language-specific. For example, using “yes” and “no” as boolean values is too English-centric. This probably doesn’t require changes in the infrastructure, but mostly an agreement in the cross-wiki template development community on good practices for adaptation to multiple languages.

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

It must be convenient to write a template in a direction-neutral way, with as little explicit right and left alignment as possible.

Bot
Many templates in many wikis are regularly edited by bots. This capability must be preserved.

This is not supposed to require any changes in the software infrastructure, but it is mentioned here for completeness because it’s an important use case.

Transitioning the templates from the large wikis to central storage
 וּמֵעֵבֶר לְשׁוּרַת הַבְּרוֹשִׁים עָבְרָה הָרַכֶּבֶת אֲבָל אֲנַחְנוּ רַק שָׁמַעְנוּ אוֹתָהּ, וְלֹא רָאִינוּ. וְכָל הַדְּבָרִים שֶׁדִּבָּרְנוּ בֵּינֵינוּ הִתְחִילוּ בַּמִּלִּים, „אֲבָל אֲנַחְנוּ”. —יהודה עמיחי 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à.

Somewhat paradoxically, however, the editors in these largest languages are also the least interested in making them global:


 * 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;
 * * perché gli utenti delle principali wiki potrebbero essere costretti a discutere su se e come unificare determinati template.

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.

As long as there are important common templates that are not global, Content Translation will have to keep supporting them. If the infrastructure for global templates is created, and migration of existing templates proceeds in a good pace, then Content Translation developers may consider stopping developing and some day deprecating the code for non-global template adaptation.

The pace of migrating templates from large wikis to the central repository can be one of the success metrics for the project.

It must be possible to use templates completely in both wiki syntax and in visual editing
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.

However, Visual Editor is increasingly embraced by both experienced and new editors, so every feature of how templates work must work well in both Visual Editor and wiki syntax editing.

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.

MediaWiki
Dovrebbero esserci strumenti su ogni wiki per mostrare - almeno - l'analisi di base dell'uso dei template e dei moduli sulle varie pagine: in altri termini, il numero di inclusioni e invocazioni raggruppate per wiki e gli elenchi di pagine che utilizzano template e moduli. La funzione che mostra quali modelli sono richiamati da una pagina mentre viene modificata deve continuare a funzionare anche con i template globali.

Stesso discorso vale per le pagine “puntano qui”, che anzi sono utilissime anche per le trasclusioni globali.

TemplateData

 * It is possible to translate template and parameter descriptions in TemplateData, and the translations are displayed in the user interface language in Visual Editor’s template insertion dialog. This is good and must be preserved. The translation interface could possibly be improved, but the beginning is good. Adding support for TemplateData in the Translate extension can be a solution for this, but there can also be other solutions.
 * 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 - 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
 * 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.