Global templates/Proposed specification/it

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

C'è una eccezione al momento: alcune wiki hanno 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.

The most commonly reported issues in Content Translation are about templates. 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.

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

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

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

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

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

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

Template e moduli globali permetterebbero a tutti gli utenti dei vari progetti di collaborare più facilmente allo sviluppo del codice e di riutilizzarli fra le varie versioni, senza essere costretti a imparare da capo ogni volta come gestire le differenze e le eccezioni.

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

All wikis should 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
Semantic means that other software components, especially Visual Editor and Content Translation, must have a way to understand that a template exists and that it provides certain functionality, so that it will be possible to insert it into an article as an infobox, a citation, a maintenance tag, etc., and not only as a generic template. Currently, the closest thing there is to making templates semantic is TemplateData, but it only describes the template’s parameters. It doesn’t, for example, help Visual Editor add an “Insert infobox” button to the toolbar.

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

Come rendere semantico un template
Templates have never been robustly semantic, in the sense of being easy to handle by software that processes articles.

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

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

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 people, among them Kunal Mehta (in the “Shadow namespace” project), Greg Grossmeier, Brion Vibber, Tim Starling, and others. This document tries to address related questions of how it works for the user who edits an article 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.

I template devono restare modificabili facilmente
An important feature of how templates currently work is that they are edited just like wiki pages and immediately become functional after publishing without review or deployment. This is somewhat dangerous because a bad edit can ruin many pages, but the fact is that it works mostly well.

This ease must be preserved. Community members who maintain templates will most likely reject moving to a new system that will require them to learn completely new skills and drag every change through an exhausting review and deployment phase. This probably rules out storing the templates in Gerrit, unless, perhaps, the process for review and deployment will be much easier than it is for extensions.

Deve essere possibile non rendere globali alcuni template
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.

Deve essere possibile sovrascrivere una funzionalità o la forma di un template globale
No community should feel that a functionality is imposed on it by some powerful external player, like the English Wikipedia community, the Wikidata community, the WMF, or anybody else. Global templates should be developed and used collaboratively for the common benefit. Most of the time it should work for everybody. 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.)

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.

Un template globale deve essere riutilizzabile immediatamente in ogni wiki
Just like a global user page is immediately available in every wiki in which there is no local user page, a template or a module that is created on the global infrastructure must be immediately usable in every wiki. This must not require copying wiki pages, creating wrapper templates with a local name, administrator intervention, waiting for hours for caches to refresh, etc.

Deve essere possibile tradurre tutte le stringhe rivolte all'utente
Core MediaWiki, extensions, and some tools are translated conveniently and robustly on translatewiki.net. This localization process is familiar to at least some editors in all languages.

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.

The template documentation pages must be translatable as well. It's mostly enough to do it using the page translation feature of the Translate extension, but it may require some adaptations.

In quale lingua mostrare le stringhe all'utente?
Templates are primarily used when they are integrated into content, so by default the translated messages must be shown in the wiki’s content language.

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.

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

Scrittura e archiviazione dei messaggi fondamentali
Messages should be represented as keys, similarly to how it is done in MediaWiki core, extensions, and tools.

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.

Riorganizzare i messaggi
The Translate extension organizes messages by groups, which can be further organized by aggregate groups. For example, Article Placeholder, Score, and Poem are all groups that represent the corresponding MediaWiki extensions, and they are all included in the “Extensions used by Wikimedia - Advanced” aggregate group, along with many other extensions.

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.

Each template should be a message group. Closely related templates should be grouped in an aggregate message group. They can be similar to the categories in which they are stored, and in fact, the categories may even be reused. Editing files in a Git repository to organize these message groups is probably not desirable, because it’s too complex and slow.

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.

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

Alcune note sui moduli
Lua modules can load and parse translatable MediaWiki strings, but there is no defined way for storing these strings for Lua modules that are maintained as wiki pages. It is possible to package Lua modules as parts of extensions, and then they are able to load translatable strings from the extensions’ i18/*.json files, but this is done in very few extensions at the moment. Rewriting templates in Lua may be a more robust solution from the engineering point of view, but Lua will not necessarily be embraced by all existing template maintainers, and their cooperation will be crucial to the project’s success, so this cannot be done to all templates.

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

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

Per rendere più facile le traduzioni, i template comuni dei progetti più grandi devono diventare globali
The most popular source language for translation in Content Translation is English, by far. After it come Spanish, Russian, French, German, Catalan, Ukrainian, Italian, Chinese, and Portuguese. Because of this, it makes sense that the common templates in the most common languages, especially those in English, are the ones that are the most important to make global for the benefit of all other languages.

Paradossalmente, gli utenti delle comunità più grandi sono anche quelli meno interessati a renderli globalmente riutilizzabili:


 * The templates already work well for them and most people there don’t directly care about the convenience of translation to other languages.
 * Rewriting the templates so that the strings will be translatable may be time-consuming and may force them to change their template maintenance skills.
 * Making the templates suddenly used by many more projects may make it harder to achieve consensus about making future changes in how the templates work.

This is more a consideration of practicality and community relations than a consideration of engineering, but it must be taken into account when making technical architectural decisions. Without doing proper preparation in this area, the whole project may fail.

Deve essere possibile usare i template sia con il wikitesto, sia con il 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 funzionalità di un template deve funzionare (e funzionare bene) sia in modalità wikitesto, sia col Visual Editor.

Localizzazione dei parametri
Parameter names are different in every language. They are usually based on words in each language, so it’s important for editing the transclusion in wiki syntax conveniently.

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?

Parametri senza nome
Nameless numbered parameters must continue working, of course.

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

Tradurre i valori dei parametri
In addition to making the templates’ functionality and design shared, some thought must be given to making the template parameter values shared, as well as not shared.

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

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

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

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

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

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

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

TemplateData

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

TemplateStyles

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

TemplateSandbox

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

TemplateWizard

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

Wikibase

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

VisualEditor

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

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

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

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

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

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

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

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

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

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