Page MenuHomePhabricator

Convert any module as central or centralisable
Open, LowPublic


How to implement the central modules themselves ?

Scribunto permit to convert any module as central, or even centralisable before an efficient central repository exists.

That permits to use central modules in many languages, in many projects, even in many small wikis without enought helpers.

  • That provides an easier and more efficient peer review.
  • That enhanses the mean abilities of modules for a same global effort.
  • That reduces the duplication of effort for a same result.
  • That increases the mean availability of coders and helpers.

A central module can help users and helpers, in their own languages and the wiki languages, by errors, warnings, categories, reports and tests.

  • Example: display a category in the helper language and link to the category in wiki language.
  • Example: for each project and each language, choose detailed categories names or only categories "users modules errors" and "internal modules errors".

A central module must be very stable, understandable and strong against small usual misuses.
For that it permits managements of arguments, wikidata, errors, messages and modules versions.

In the draft proposition, the Module:Central contains and installs the Library:centre and the Library:tools which support any other central modules in all the previous aspects.
This draft proposition is in fr.wikisource Central modules.

See also Multilingual Templates and Modules

Related Objects

Event Timeline

This task is not at all about the central repository,
But about how to implement the modules themselves.

We need to talk about many points to share this task from the draft proposition for Central modules.
Could you choose one or some places where we can update and talk some parts of that proposition? Now I work on MW test cases inside central modules.

If you want the result of this task come earlier, I invite you to really share it in the page Extension:Scribunto/Central modules.
Any developer can already convert any module as centralisable.

Before several LUA coders begin to work on central modules themselves and many LUA coders use them as tools, and to avoid many confusions, we must choose names of libraries and of their main functions.

How to distribute functions in one or some libraries?
How to also name main functions of these libraries?
How to continue the actual libraries names, add central modules and do not too constrain future developments?

See a draft base to talk in Central modules and the talk to rename.

Before several LUA coders begin to work on central modules themselves and many LUA coders use them as tools

Before anyone begins work, it would really help to have a concise, readable proposal that didn't include unrelated stuff like a library for converting roman numerals. You might want to seek out a collaborator or mentor to help you clean up your proposal; perhaps people working on T121470: Central Global Repository for Templates, Lua modules, and Gadgets could help you.

Now this task is implemented in centre and tools libraries already able to support central modules for 1 month. I work on tools.TestsCases_report to complete them.

Other parts are only means to use centre and tools in real use cases to finalize them:
The roman library is a very small example and use translations and errors detection.
The Module:Central is small and show many aspects of translations, errors, categories, versions, viewers ... in central modules. It also "install" centre and tools libraries using centre.new_library.
The Module:Author3 is a full use in fr.wikisource.
The Template:Author3 is the first motivation for central modules in fr.wikisource.
The page Utilisateur:Rical/Victor Hugo show some full uses in live.
I document many aspects in the documentation and I update it when a new step is enough stable.

The roman library also contains TestsCases to run like in gerrit, but with the tools library also available and the result can help me. How to ask? How to do?

Then we can probably share works on this task and some of you can begin to use centre and tools libraries and to talk about how to adapt and insert them between other parts of mediawiki.

@Rical , I believe you should listen to @Anomie's advice. The topic of centralization of Lua modules is complex and has many ramifications. As someone that has been requesting this feature for a long time, I welcome your interest and work in this area, but if you don't sync better these efforts with people like Anomie, @Legoktm or @brion , and with ongoing efforts like T91162: RFC: Shadow namespaces, I see a big risk of all this work becoming less useful as you expect today, and that would be really bad.

I understand that as a volunteer it is difficult to find the time to sync with others, especially in an old and complex topic like this one, but it is even worse when the precious time of a volunteer developer goes into waste because the lack of that initial sync.

PS: I am not a technical expert and I have no feedback about your technical plan versus other plans. I am just pointing to a pattern that we have seen in the past that frequently end up with more developer frustration than actual features deployed.

The draft of Module:Central already runs recursive Test cases = groups of groups of cases.
Search "Library:testsCases".
How to permit to Mediawiki to call these recursive Tests cases?
That fails:

local testframework = require 'Module:TestFramework'

For tests cases see details in talk Lua_reference_manual.
It seems that need a new phab task "Run tests cases in modules for Mediawiki tests cases".

See the advice given above. Also, maybe channels like #wikimedia-tech on IRC may help with quick questions.

From the question "how to name the central space and its shortcut?" we can ask 2 questions:

  • The shortcut cannot be "c" for commons, it could be "ct" for central or "gb" for global.
  • Where to find a list of shortcut ? like for languages: fetchLanguageNames.

Languages specifically use ISO 639 codes where possible; Wikipedia has a full list of ISO 639-1 codes (ISO 639-1 is the specific part of the standard that assigns two-letter codes). Because of this, assigning custom two-letter codes to be used alongside ISO 639-1 codes is generally a risky proposition, though in the specific cases of "ct" and "gb", both of those codes are unassigned in the standard. That being said, the codes might be undesirable for other reasons (e.g. "gb" is the ISO 3166-1 alpha-2 code for Great Britain, which might make it unsuitable for use).

@Rical: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!

Aklapper lowered the priority of this task from Medium to Low.Sun, Jun 19, 7:20 PM
Aklapper added a project: Epic.