Central Global Repository for Templates, Lua modules, and Gadgets
Open, NormalPublic

Description

This card tracks a top 10 wish from the Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

Original proposal: We could use a single location where to keep templates, Lua modules, and Gadgets that are used on all the wikipedia projects. Just like images from commons can be used on other projects, code from such site would be visible to all the projects. The current system of 100's of out of sync copies of the same templates or Lua modules occasionally synchronized with the original is very hard to maintain. --@Jarekt (talk) 20:06, 10 November 2015 (UTC)

Community Tech preliminary analysis:

Support: High. Strong support, but there are some important concerns expressed in the voting about the difficulty of using templates across wikis. Templates are already complicated, and this project could be offering a technical solution to a problem that needs social, consensus-based solutions.

Impact: High. Existing templates, gadgets and modules (across all wikis) will probably be affected.

Feasibility: Difficult. We're currently working (mid-January) on getting the Gadgets 2.0 Gadget Manager ready for review (see T31398). That doesn't include global gadgets, but it's a step in that direction. Creating a global repository will depend on using shadow namespaces -- there's currently an RfC about shadow namespaces on mediawiki.org. There are also notes and discussions from the Developer Summit in early January here: T115762.

Risk: High. Templates, gadgets, and modules are implemented differently and may need different solutions. Templates often transclude other templates. Adding translation support to templates will make them harder to maintain. We'll need to figure out how permissions will work, and how template and module editors can test on multiple wikis or provide a warning of changes. We need to also think about Gerrit-like code review needs for templates, gadgets and modules and possibly even a versioning system. It will be difficult to come up with a solution that will truly work across projects and will fit into the social structures of diverse communities.

Status: This work will probably depend on the shadow namespaces work, which is still being discussed, and probably won't be complete by the end of this year.

Project page: https://meta.wikimedia.org/wiki/Community_Tech/Central_repository_for_gadgets,_templates_and_Lua_modules

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

Global gadgets stored in where? meta, or mediawiki, or wikitech, or other?

Perhaps in a new wiki. A bit concerned that the extensive inter-site dependencies such a repository would create (a bad edit in the repository affects hundreds of projects) clash with the self-governance philosophy of Wikimedia projects. There are already some conflicts when Commons removes images that are in use in other projects.

I do prefer a Wiki for repo purpose only.

meta, mediawiki, wikitech are doing their own business, and there is already a conflict on meta that user pages are shared world-wide and should simultaneously support particular purpose for meta only.

Nothing else than self-administration should happen on repo wiki, and a gadget on meta, mediawiki, wikitech must not be automatically presented as a world wide solution for a problem that is specific to these wikis.

Sophivorus added a comment.EditedDec 14 2016, 8:13 PM

Isn't Commons meant to be a repo for "common" resources? To avoid further conflicts we could define new namespaces at Commons such as "Gadget" for gadgets. But if Commons isn't appropriate, then I also favor a new wiki.

The problem is that Commons:Gadgets namespace is reserved for gadgets to upload images, and to curate media files. The same mixture as on meta, mediawiki, wikitech.

Administration of these resources for their purposes is done by Commons sysops, elected for multimedia business, but administration of global software is to be sueveyed by a kind of global software reviewers.

Qgil added a comment.Dec 15 2016, 10:37 AM

The discussion about where should the repository be hosted is easy to start and has started in many places (I los count). Maybe we need a task specific for it? Although it is a discussion with technical implications, the drivers are more social than technical.

My opinion, for what is worth:

from a Collaboration point of view the ultimate goal is "To concentrate the development and distribution of all templates/modules and gadgets at mediawiki.org, together with the rest of the developer community and resources." It is a social goal (an integrated developer community) with clear implications in software quality (a centralized infrastructure allows for better review and quality of the software developed here and deployed elsewhere).

I am removing Developer-Wishlist (2017) because this task is just too big for it. See "Doable¨ at https://www.mediawiki.org/wiki/Developer_Wishlist#Scope

Maybe there are subtasks with an appropriate size that could be pushed to the Developer Wishlist?

T159334: Discussion: Create a Central Gadget Taskforce is in the Vienna's hackathon list of tasks. It is a first step to have this central repository created.

0x010C added a subscriber: 0x010C.May 16 2017, 9:21 AM
daniel added a subscriber: daniel.

Putting this on the platform team backlog. I expect that at least some work will need to be done on the platform to make this work.

Rical added a comment.May 19 2017, 8:38 PM

How to name this Central Global Repository ? Central ? Global ?
With which short name? c ?

Stryn added a comment.May 19 2017, 8:44 PM

C is already reserved for Commons.

Sent from mobile

19.5.2017 23.38 "Rical" <no-reply@phabricator.wikimedia.org> kirjoitti:

Rical added a comment.

How to name this Central Global Repository ? Central ? Global ?
With which short name? *c* ?

*TASK DETAIL*
https://phabricator.wikimedia.org/T121470

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *Rical
*Cc: *daniel, 0x010C, Metamorforme42, Trizek-WMF, Amire80, RandomDSdevel,
Schnark, Huji, Stevietheman, TerraCodes, MarcoAurelio, Thibaut120094,
Bodhisattwa, Sophivorus, Wesalius, robkam, santhosh, Antanana, MKar, Zppix,
zhuyifei1999, MZMcBride, Stryn, Nikki, Micru, T.seppelt, Jarekt,
Kopiersperre, MrStradivarius, waldyrious, JanZerebecki, Pasleim,
Daniel_Mietchen, Ltrlg, Niharika, Elitre, Spage, intracer, PerfektesChaos,
greg, Susannaanas, Edgars2007, Ankry, Psychoslave, 555, -jem-, Danny_B,
Johan, Yurik, RobLa-WMF, Legoktm, Qgil, He7d3r, Liuxinyu970226, Matiia,
Ricordisamoa, tarlocesilion, JEumerus, Rical, Shizhao, Aklapper,
StudiesWorld, DannyH, Marostegui, JJMC89, B20180, Samwilson, Nakon,
MusikAnimal, Fhocutt, Anomie, Jay8g, Krenair

Conny added a subscriber: Conny.Jun 16 2017, 11:06 AM
TerraCodes added a comment.EditedAug 1 2017, 8:41 PM

Maybe use code:?

Or use phab for code hosting.

robkam awarded a token.Dec 9 2017, 7:52 PM
robkam added a comment.Dec 9 2017, 7:55 PM

This should be treated as a MW bug, see T182504

I'm afraid it won't change a thing if it's treated as "a MW bug" or not. :)

CCicalese_WMF moved this task from Inbox to Watching on the MediaWiki-Platform-Team board.
Liuxinyu970226 removed a subscriber: Liuxinyu970226.

It's not totally clear to me how this task is distinct from older tasks such as T66475: Make crosswiki bits and pieces truly global (tracking). Is there something new here?

We started to move in this direction, for at least some use-cases, with https://www.mediawiki.org/wiki/Requests_for_comment/Shadow_namespaces#Applications.

Yurik added a comment.Mar 21 2018, 4:37 PM

@MZMcBride I think this task is the implementation of one aspect of T66475 . Also, I don't think shadow namespaces are a good approach, as discussed some time ago at a conference. Shadow implies local (per-language) override, whereas most of the time you don't want to override per language, you want to override per usecase, and that override may be useful for more than one language. To give an example, lets say you have an infobox that most wikis find useful, but it breaks in RTL wikis. You have two options - either fix the infobox so that it works on both (preferable, but might be very hard), or you could create a new infobox for RTL wikis, in which case it is useful to all RTL wikis, not just a single one. So instead of having a global + several local overrides, there should be two globals.

Also, I don't think shadow namespaces are a good approach, as discussed some time ago at a conference.

It depends on the use-case. Some of the past discussions focused on the difference between use-cases like Help pages v. User pages v. Template and Module pages. They may require different solutions, even though they can feel like similar problems.

You have two options - either fix the infobox so that it works on both (preferable, but might be very hard), or you could create a new infobox for RTL wikis, in which case it is useful to all RTL wikis, not just a single one. So instead of having a global + several local overrides, there should be two globals.

Two globals here could mean a central template repository with one page "Template:Infobox" and another page "Template:Infobox RTL", right? It does not necessarily mean multiple central template repositories.

Rical added a comment.Mar 21 2018, 5:36 PM

To try to solve the languages questions, I could propose a dedicated i18n table or even a strict rule.
In Central modules, see T135845, I use i18n tables to translate sentencies, which could be aproximative.
Here you probably need accurate translations in a dedicated i18n table.
My way to name modules in any wikis is:
Module:Central is for the central one.
Module:Central-s-fr is for fr.wikisource.org ... and so on.

Yurik added a comment.Mar 21 2018, 7:25 PM

Also, I don't think shadow namespaces are a good approach, as discussed some time ago at a conference.

It depends on the use-case. Some of the past discussions focused on the difference between use-cases like Help pages v. User pages v. Template and Module pages. They may require different solutions, even though they can feel like similar problems.

Correct, there is a clear "shadow" use case for localization, where the content is purely language-specific. I don't think Lua modules should have this feature at all. So lets not conflate two concepts - per-language separation (localization) and content structures (like templates and lua modules). The user page might be a special usecase, but it might be outside of the scope for this one.

You have two options - either fix the infobox so that it works on both (preferable, but might be very hard), or you could create a new infobox for RTL wikis, in which case it is useful to all RTL wikis, not just a single one. So instead of having a global + several local overrides, there should be two globals.

Two globals here could mean a central template repository with one page "Template:Infobox" and another page "Template:Infobox RTL", right? It does not necessarily mean multiple central template repositories.

Correct, that's what I meant - two templates in the same global repository.

Yurik added a comment.Mar 21 2018, 7:27 PM

@Rical take a look at the https://www.mediawiki.org/wiki/Module:TNT module -- it already allows one global translation table that can be used in any template anywhere. This allows a template or a module to be copy/pasted to any wiki without a single modification. Only requirement - the TNT module must be present on the wiki (many wikis already have it).

Rical added a comment.EditedMar 21 2018, 11:08 PM

@Yurik where to find an example of module already shared using TNT?
To see what include the module to share it. And for a template also. Thanks in advance.

@Rical take a look at Template:Graph:Lines -- that template's localized parameter documentation is stored in one place at the single location, and can be changed there without going to each wiki and copy/pasting things inside the complex template. Beyond that, the caption under the graph is also localized -- the string "See or edit raw graph data." is localized using the {{#invoke:TNT|msg|I18n/Template:Graphs.tab|source_table|{{#invoke:TNT|link|{{{table}}}}}}} (a bit cryptic, I know - it uses TNT twice, once to render the link, and once to render the whole message). The localized messages are actually stored here.

Using TNT from Lua modules should be very similar, and should be even easier to read than wiki markup.

Mvolz added a subscriber: Mvolz.Mar 26 2018, 4:51 PM
Izno added a subscriber: Izno.Jul 17 2018, 5:35 AM