Talk:Global templates/Proposed specification

Comments about these proposals are welcome!

This page is more for detailed discussions. For general pros and cons discussion, see Global templates/Discuss.

Some related discussions on other pages:

• w:fr:Sujet:V8o4rix4gln2uqp9 (in English, in the French Wikipedia)
• w:ca:Tema:V8qfiuebv24mqw1p (in Catalan, in the Catalan Wikipedia)

This long proposal, most of which I wrote, does not currently fully and precisely address a rather important issue: What does the mechanism that delivers the template from the repository to the local wiki actually deliver—the template's code or its output? The same question also applies to modules: should the Lua code of a global module run on the repo or on the local wiki?

I don't know nearly enough about the intricacies of template parsing and context and about Lua evaluation. But it will be necessary to decide about these things sooner or later, so I need professional help :)

What makes sense to me is that the code should be delivered and parsed on the local wiki, although I might be missing something. This way it will probably be easier to parse it on the local wiki and check whether local version of templates transcluded within this template need to be loaded, and to parse magic words in local context.

Since I am really not an expert on how this works, it's quite possible that I'm totally wrong about this, and that maybe they should be at least partly parsed on the repo.

Any thoughts?

Tagging some people who may have an idea; feel free to ignore if you're busy with something else :)

@DKinzler (WMF), @SSastry (WMF), @TK-999, @Tacsipacsi, @ערן, @Yurik, @Brion VIBBER.

(Originally, this post was much longer and detailed my naïve thinking process, but then I decided to just write that process' result. If anyone is interested for some reason, I can post the rest, but it's not really exciting.)

Use the same as Commons and Wikidata. Output can be translate to several languages using Mediawiki translation tolls (see how pages are translated in Mediawiki site ).

This is completely irrelevant here. The translation tools on Commons, Wikidata and MediaWiki.org deliver neither the code nor the output—they’re not global.

The current wikitext model requires the processed template output (= wikitext) to be merged into the top-level page before the output of the full page is converted to HTML. This is the preprocessing model where a transclusion ({{some-tpl|..args..}}) is evaluated. This preprocessing will fetch other templates where necessary, and so on recursively. I should go look at the code to be sure, but in the current model, every one of these template fetches will be resolved to a target. And, so if template target resolution goes through a global template repository, then it is likely every recursively referenced template will be impacted by that. An alternative model of course is to change the code so that during template preprocessing, all template references resolve on the local wiki where the top-level template target resolves to.

<tangent>Parsoid is eventually trying to get to a model where a transclusion is processed independent of everything on the page and so the output of the transclusion is always HTML / DOM (or if we are able to arrive at typed templates, then it will be some typed value, with the default being HTML/DOM always). In addition, we are trying to get to a place where Parsoid doesn't care what component generated it as long as the types match up. So, both the above preprocessing systems would be compatible with Parsoid. And, at some level, extension are no different than templates in that regard. Everything produces a typed value. So, you can build whatever transclusion system you want as long as you adhere to the type contract. Getting to this point is a bit slow since we are still trying to get to Parsoid being the only wikitext engine.

For example, Scribunto could be considered to be a different templating model from the native wikitext templating model. They look the same on the surface because editors have adopted a mechanism where the module #invoke calls are hidden behind a typical wikitext transclusion.

So, from the ideal Parsoid POV, the qn. of global templates vs local templates or some-other-form-of-templates is an implementation decision of the implementor and they can all coexist as long as they can be appropriately namespaced / disambiguated. But, of course from a product POV, wikis might choose to pick a single mechanism.</tangent>

Hope that helps.

It helps. I wish it be adopted soon for global templates and global template repository 👏🏼👏🏼👏🏼👏🏼

I think we can began with globalization of templates, using nowadays tools as Wikidata, TemplateData, Wikimedia translation tolls an so on. Global repository can be the second step. Another option is procrastination.

Where would you store the code of the templates before there is a repository?

Test Wikipedia? Wikimedia Commons? Data in Wikidata for TemplateData? Mediawiki (Extension / Translation tool)? Any other suggestions?.

We must begin with the most used template in Wikipedia .

If you are trying to transclude a template into a page on the Spanish Wikipedia, and the template's code is stored on Test Wikipedia, Wikimedia Commons, Wikidata, or Mediawiki.org, it won't work. The code must be on the same wiki. That's why a repository is needed first.

We must broke up this Ouroboros. First a test site (it was offered a Wikipedia to test it). This can use *existing* tools in Wikidata and other Wikimedia projects (as translation tool) to support the globalization. I suggest beging with the most used template in Wikipedia, as an example /test that the idea works.

It can use Mediawiki extensions / repository or third party repository. When you wan use a template from this repository, you can download it to a local Wikipedia. This can be the first step for globalization (downloadization).

Is there a existing Phabricator ticket that covers this? If not, should we open one?

Never mind; I found it: https://phabricator.wikimedia.org/T121470

Yes, it's the most common Phabricator reference for this topic. There is also the much older task T6547.

I plan to split task T121470 to something more manageable some time soon.

When?.

Already did. See the tree under "Related Objects" in https://phabricator.wikimedia.org/T121470.

Well, now I can see the fruits. 👍

With a good guru to help me to master the different steps at the beginning, I could try to participate to the move operation when being planned, allowing me to explore a new domain of skills as remaining in the translation field in the same time.

Christian FR (talk) 08:32, 23 June 2020 (UTC)

Can begin with simpliest step : global use of templates / template translation using Mediawiki translation tool.

Global use is currently impossible, as I've already written in replies to your comments in a few other places. First, the technology for cross-wiki transclusion must be developed, and there must be a repository to store the templates' code.

This is great! Volunteers will be needed when the infrastructure becomes available.

Even though it's early for this, I've already started writing a draft transition plan: Global templates/Transition. Your comments about it are very welcome.

Also, huge thanks for writing the translation for the very long document!

I think it can begin as Lingua Libre, in Wikimania. A demonstration needed.

From https://lists.wikimedia.org/pipermail/wikimedia-l/2019-December/094062.html:

Global templates is a great idea. It’s done by Miraheze in a sketchy way currently but I’ll explain it.

• create a template wiki
• setup an interwiki with transclude set to on
• set $wgEnableScaryTranscluding to true
• place {{raw:Interwiki:Template Name}} where you want to use it.,

More complex templates require more work and modules need to be shared etc etc

Cache will need to be properly purged but it will work.

Use Wikidata with TemplateData and translate TempareData for this template.

By Sketchy, It's only because if modules get involved and other dependencies it requires more work and the cache can purge randomly so they can break or it might be outdated for a while.

See https://template.miraheze.org/wiki/Interwiki_transcluding_templates

@Amire80: Sound good?

Thanks! Some questions:

• "setup an interwiki with transclude set to on" - how is it different from the next point, "set $wgEnableScaryTranscluding to true"? (Sorry if it's a silly question, I've never set up a wiki wgEnableScaryTranscluding myself).
• place {{raw:Interwiki:Template Name}} where you want to use it - What do the words "raw" and "Interwiki" refer to here? Is "raw" a part of wikitext? I've never encountered it.

Also, other than https://template.miraheze.org/wiki/Interwiki_transcluding_templates, is there anything else written on this topic? I was doing a bit of homework in October while I was writing the first drafts of Global templates/Proposed specification, and all I could find was https://template.miraheze.org/wiki/Miraheze_Template_Wiki, which mostly recommends importing and not transcluding, so it's not very different from what we have at Wikimedia.

Finally, the page "Interwiki transcluding templates" says: "Don't use the method on this page until it's fixed and the above warning has been removed". So does it actually work at Miraheze?

Anything you can write about the problems you have with functional bugs, caching issues, localization challenges, and so on, can be useful for implementing better global templates and for all MediaWiki users.

1. Creating an interwiki with transclude set to on is how you define which Interwiki links to which wiki. Setting that to true only allows it to work.
2. Raw pulls the template code rather than just transcluding the page. Interwiki is the name of the Interwiki link you created.
3. Not that I’m aware of
4. It does actually work as I’ve used it.
5. Not really

Thanks for drafting this proposal.

this would address the biggest challenge in setting up a new project of any size: comfort and east of use.

Thank you! 🌻 :)

Tell all your friends about it ;)

But it must not be a proposal. It must be a reality now.

It is time to use global template. We can use Wikidata an TemplateData. Time is now!!!

@Bouzinac added the following in the "Localizing parameter names" section:

It should be possible to use aliases. Eg "date" in enwiki, "data" in itwiki, "Дата" in ruwiki. Either "first" parameter names or aliased names should be working.

I am moving it here for discussion. Perhaps I don't understand the suggestion, but isn't this already what the "Localizing parameter names" idea is about in general? The current proposal is:

These generic parameter names will be the common default names. They will work in wikis in all languages. The localized names will work in the wikis that has that language as its content language.

According to this, "date" will work in English, Italian, and Russian wikis, "data" will work only in Italian, and "Дата" will work only in Russian.

As far as I can see, using a Russian parameter name in Italian or English is probably not so desirable. Using an English parameter in Russian is also not so desirable, but it's just a default fallback. If the parameters are localized in the template definition, then every time a transclusion is transferred from one wiki to another, the service described in the "Automatic parameter translation" section will translate them automatically.

@Bouzinac, does this sound OK, or do you suggest doing something else when you talk about aliases?

Hello, well, ok. Then, do you mean it is only possible to use "English" words to use for variable names, so OK you can revert my aliases paragraph...

Not exactly. Definitely not only English. I'm just saying that English should be the default and work everywhere if it's not translated, and translation should be allowed into all languages.

My biggest question for you is what do you mean by "aliases". Currently, each template works within one wiki, and each parameter can have several aliases in TemplateData. Sometimes they are in the same language, and sometimes they are in a different language; for example, the French Wikipedia can define parameter names in the French language, and add aliases in English. It is done consistently.

For the future, when templates can be shared by all wikis, I suggest the following:

• Each parameter has a default name. It will probably be in English, but this won't be forced; it will in any language in which the template developers want to write it. This default name will work in all wikis in all languages.
• It will be possible to translate every parameter to any language. The translated name will work in wikis in that language. So, the Russian translated name will work in the Russian Wikipedia and Russian Wikisource, but not in the English Wikipedia or Italian Wikipedia. I don't call these translations "aliases"; I call them "translated parameter names".
• There will be a service that automatically translates parameter names between languages. For example, imagine this template in the English Wikipedia: {{Infobox event|name=Storming of the Bastille|date=1789-07-14}}. If you copy this template to the Russian Wikipedia, it will be automatically changed to {{Событие|название=Storming of the Bastille|дата=1789-07-14}}. Note that the parameter values are not translated in this example, and the editor will have to do it manually. Such a thing may become possible some day, but that would be a different feature. But the parameter names will be translated automatically, and the editor won't have to look them up one by one.
• Aliases, as they are used TemplateData, will keep working without change.

Does this make sense?

Only templates and modules independent of cultural and community adaptions are able to be used as global resources.

• This goes for basic string manipulation, mathematical calculations etc.
• As soon as community or cultural adaptions are involved the global resource willl break.
• The reason to have local templates is to adapt issues to local requirements. Formatting needs to be adapted to local culture and may need different parameters.
• Everything dealing with visual presentation to the reader is no subject for global octroyment.
• Overriding local data structures by global resources are no acceptable way to deal with any problem.
• The local communities who are used to apply a local template with certain parameters according to local needs for more than a decade will not accept a different template for the same purpose with other name and differing parameter names and different value formatting.
• The reason why you have local templates with parameter names in local language and local (non-latin) scripting and local value formatting is that not every author is speaking English, even not reading latin ASCII scripting, and value formatting may depend on local culture.

The main viewpoint I take from the proposal is: Every Wiki in the world has to do everything in the same way English Wikipedia does.

• Then users of the Content Translation Tool can just C&P everything from enwiki, just translate some words in human language between, and the new article is written.
• The local community is left with a lot of foreign code sequences they neither understand nor are able to modify.

One simple example: German Wikipedia has rejected the concept of citation needed microtargeting. This global template is useless in dewiki, and nobody is permitted to insert.

• German Wikipedia has differing citation concepts not compatible with English Wikipedia.
• German Wikipedia will delete every template which is competing with templates which the community of German authors is used to apply for a decade.

The articles in the local Wikis are written matching the local culture, and to be maintained over long term period. They are not made to make an easy job for content translators, who show up once for a few minutes and leave a pile of mismatching syntax rubbish not fulfilling local requirements.

Thanks a lot for this comment.

I understand that the points you are bringing up here are among the most important for the editor communities, and this is why I tried to address them explicitly in the text. If I can make them any more explicit, I'll be happy to do it.

I shall now reply to your points, one by one. It's very important for me to note from the start that I'm not rejecting them. I fully agree with them, and I want this future system to be in agreement with them, too.

> Only templates and modules independent of cultural and community adaptions are able to be used as global resources.

Yes, absolutely. If I can make it any more explicit in the text, let me know how, or edit yourself.

> As soon as community or cultural adaptions are involved the global resource will break.

One of the main points of this document is that community or cultural adaptions must be supported. Otherwise the requirements are not fulfilled.

Generally, there can be a central template that implements common things, and each community can override any part that it wants to override. It can also choose not to use a global template at all and use something local instead.

I'll give more detailed examples below.

> The reason to have local templates is to adapt issues to local requirements. Formatting needs to be adapted to local culture and may need different parameters.

Yes. I address this in the section called "It must be possible to override some functionality or appearance of a global template":

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

Here is a made-up example: if the Russian Wikipedia community wants to show a "patronymic" parameter in an infobox, but the English Wikipedia doesn't, then this system must support it, period. How it is implemented is a separate question. This is a requirements document and not a development plan.

If you have a real example from German or from any other language that has different parameters, I'll be happy to research it.

> Everything dealing with visual presentation to the reader is no subject for global octroyment

I'm not sure what "octroyment" is, but I think I understand what you're saying :)

For example, the Infobox for cities in the French Wikipedia has an image of a compass in the background. The corresponding infobox in English and German Wikipedias don't have such an image.

What this document says is that the future global system must support this: to have a compass in French and no compass in English and German. I shall mention again the title of the section that I mentioned above: "It must be possible to override some functionality or appearance of a global template". I intentionally used the word "must", so it will be as explicit as possible. It's a requirement.

What I am trying to achieve here is to have a convenient way to share the 90% of the code that is common, and to change the 10% that the people want to change. And maybe it's not 10/90, but 5/95, or 30/70, or some other proportion. Maybe there's nothing in common at all, and that is fine, too. Nothing is supposed to be forced. In the beginning, the document says: "It must be possible to store templates and modules in a global repository". Note the emphasis on "possible". Global storage must be possible, but local changes must be possible, too.

> The local communities who are used to apply a local template with certain parameters according to local needs for more than a decade will not accept a different template for the same purpose with other name and differing parameter names and different value formatting

If they don't accept it, it's fine. It's not forced.

However, there have been cases in the history of several wikis that the community decided to make a massive change in the way that a certain template is used on many pages, and implemented such a change after consensus was reached, using a bot or manually. So it's not unthinkable.

If people want to use it, they will. If people don't want to use it, they won't.

> The reason why you have local templates with parameter names in local language and local (non-latin) scripting and local value formatting is that not every author is speaking English, even not reading latin ASCII scripting, and value formatting may depend on local culture

Yes, absolutely. That's why this document said from the start that it must be possible to allow localization of the template name and the parameter names. See the sections "Localizing the template name" and "Localizing named parameters".

If there is anything in these sections that is missing or wrong, please tell me.

> The main viewpoint I take from the proposal is: Every Wiki in the world has to do everything in the same way English Wikipedia does

Nope, that's absolutely not the viewpoint that I am trying to have here. If that's what you understand, then I guess I have to make the document clearer.

I am trying to say the exact opposite viewpoint. There is a lot of talent and innovation in making templates in a lot of wikis, not just in English. By making it easy to share the template code to different wikis, the template maintainers will meet each other and share innovations. I actually envision innovations coming to English and to all other languages from Hebrew, French, Catalan, Arabic, and other languages.

> Then users of the Content Translation Tool can just C&P everything from enwiki, just translate some words in human language between, and the new article is written.

The reality shows that "C&P everything from enwiki, just translate some words in human language between" is not nearly as easy as it sounds. It takes literally years.

And it doesn't have very much to do with Content Translation. This affects all editing, with or without Content Translation. The problem existed since 2005 or so, long before anyone even imagined Content Translation.

Content Translation just made it much more visible, precisely because Content Translation makes a lot of things other than templates much easier.

> One simple example: German Wikipedia has rejected the concept of citation needed microtargeting. This global template is useless in dewiki, and nobody is permitted to insert.

Cool! Then just don't use it.

> German Wikipedia has differing citation concepts not compatible with English Wikipedia.

Aha, so this is a particularly good example because citation templates are very common.

I'd like to know how are they different. Let's say this: Every journal article citation probably has data about authors, title, date, journal name, and doi. These fields are probably the same. If the same academic article is cited in a Wikipedia article in both English and German, then these fields and their values are probably the same (but correct me if I'm wrong). What can be different is their appearance: their order, the usage of italics, etc.

So the fields mapping can be central, but each language must have the freedom to decide on the design. And if the German Wikipedia has more fields, then it must have the freedom to have them, too.

If my understanding is too shallow and I am missing something and you can add any more details, I really want to know. These are exactly the problems I am trying to solve, and it's neither possible nor desirable to force a bad solution on anyone.

> They are not made to make an easy job for content translators, who show up once for a few minutes and leave a pile of mismatching syntax rubbish not fulfilling local requirements.

The main reason it creates mismatching syntax is that the templates aren't global. If the pieces that can be global will be global, the mismatching syntax will be reduced to zero. And as I said several times, not everything has to be global.

Further to Amir's detailed and very reasonable reply, consider, as an example, Module:Delink.

We've just had to import that from Commons to Wikisource; it also exists on 70 (yes, *seventy*) other projects [1]. Now suppose someone finds a bug in that code, or proposes an improvement. That change now needs to be applied *72* times.

If someone makes a change to the module on one project, and then a bug is discovered, and someone codes a fix based on the code in a different project. The bug fix might conflict with the earlier change, creating more work to find and resolve the new problem.

Hosting the code in a single, central repository - just as we do for images, on Commons - removes all these issues.

No sane organisation would host and maintain 72 copies of the same code.

[1] See: https://www.wikidata.org/wiki/Q13374587

@ w:en:Module:Delink introduced by Pigsonthewings:

• That one is not a good example for a culture independent implementation.
• It is expecting the values "no" and "yes" which are English words in Latn scripting; that is a very bad idea for Japanese, Russian, French, German.
• It is requesting the parameter names in English; well that might depend on the template feeding the module. While the module might be used globally, the template needs to be supported in local language; in non-English non-Latin parameter names and template name.
• The module might be maintained globally, but the connected template needs local parameter names and parameter values according to local culture.
• The comment from Pigsonthewings tells me what I did expect: Everybody in the world has to do things exactly in the same way as English Wikipedia Community does, providing English parameter names, English parameter values, and the code used by English Wikipedia is the best code the world has seen ever.
• I will return on the issues of global Lua modules later; first I do focus on template aspects. I will open several threads to keep overview; month after month.

One remark in advance: The digits 0 and 1 are understood in Japanese, Russian, Arabian, Hebrew, Greek and any Latin scripted language. And by VisualEditor. While English Wikipedia is expecting everybody in the world to use their code written for an English community, with values no and yes, and use that stuff as “global” modules, a real global approach will need all English community clutter to be rewritten for a global community.

• Useless to mention that German Wikipedia will interprete correctly in many templates 1, y, yes, true, ja, j vs. 0, n, no, false, -, nein (case independent).

@ “I'd like to know how are they different.” (on citation)

• I selected one example of many many issues regarding citation: There is simply a barreer when providing the names of authors and editors.
• German Wikipedia decided long ago to simplify life: We have just three parameters, one for all authors, one for editors, and one for translators. No co-authors (contributors).
• Names of a person are arranged in order how you talk to them:
  • Given name family name. Multiple persons are separated by comma.
• English Wikipedia style is using a lot of fields, for first name, middle name, family name, suffix and an additional field for authorlink; for authors, co-authors, editors, translators.
• If a combined form is used, English Wikipedia is ordering family name comma given name any-separator (w:en:Template:Cite book says “Free-form list” but does not specify separator between persons nor within single name). German Wikipedia inserts explicitly not the word und before last person in list. English Wikipedia uses often and instead of separator before last person in list, or both comma and “and”. Sometimes  Doe J, Anthony W – how to interprete that?
• Therefore you cannot feed a list of persons, even when combining splitted components in the right order. But the merged fields authors and co-authors or contributors and editors and translators are not compatible since family and given name are in wrong order and the separator between persons is not matching or not specified.
• In Russian there is also a patronyme, in other cultures there is a matronyme. Therefore you need for one person to concatenate first name, middle name, patronyme, matronyme, family name, suffixes (Jr./Sr.) and nobility titles. These are already 8 fields for each person.
• To map 15 authors, 10 co-authors and 10 editors and 3 translators more than 300 fields are required. This will not be appreciated by every Wiki and is a nightmare on VisualEditor form.
• As mentioned already, German Wikipedia is using three fields only, authors and editors and translators, in given name family name comma format (or native order for asian people). This is not compatible with English Wikipedia format which uses family comma given some-unspecified-separator format on combined fields.
• BTW, please note that I am using the term “given name” rather than “first name”. First name is already a cultural bias by English people. In Hungary and Asia the first name is identical with the family name.
• There are also countries using other components for the name of a person, like nickname in Thai or scandinavian traditions. Middle name is an U.S. concept as well as suffix (Jr./Sr.) and numbering Henry Ford II (please note: Jr./Sr. is a suffix subtype to be separated by comma, while II is another suffix subtype to be appended to Henry Ford without any comma; two suffix fields).
• Other cultures need special treatment of nobility or family ancestor structure, like in the iberian world.
• In German Wikipedia it is not permitted to mention academic titles for contributors of a publication, especially not in the combined fields.

Adding all these, you need a granularity of more than ten fields to describe one single person involved into a publication. That is no concept which you can ask other communities to follow in order to create interchangeable names of persons. Nor are the combined lists interchangeable.

I already replied to this briefly, but I'll reply again in a bit more detail:

> It is expecting the values "no" and "yes" which are English words in Latn scripting; that is a very bad idea for Japanese, Russian, French, German.

Good example. I mentioned it in the section Global templates/Draft spec#Translating parameter values.

> It is requesting the parameter names in English; well that might depend on the template feeding the module. While the module might be used globally, the template needs to be supported in local language; in non-English non-Latin parameter names and template name.

Indeed. There's already a whole section in the document dedicated to "Localizing parameter names".

> The comment from Pigsonthewings tells me what I did expect: Everybody in the world has to do things exactly in the same way as English Wikipedia Community does, providing English parameter names, English parameter values, and the code used by English Wikipedia is the best code the world has seen ever.

This is not what Pigsonthewing said at all.

> I will return on the issues of global Lua modules later; first I do focus on template aspects. I will open several threads to keep overview; month after month.

I am exploring the topic of making Scribunto modules global in more detail now, so I will really appreciate any comments that you have about modules. The earlier you can provide it, the better.

As for the long list of comments about given names, patronymics, academic titles, etc.: all of this is really useful, and all of this (and more) will obviously have to be respected. The proposal is only about sharing the code that can be usefully shared, and not about forcing things that different communities don't want.

> The comment from Pigsonthewings tells me what I did expect: Everybody in the world has to do things exactly in the same way as English Wikipedia Community does, providing English parameter names, English parameter values, and the code used by English Wikipedia is the best code the world has seen ever.

Let me please contest this assumption, and let me present the vision of a user from the Italian and Neapolitan community.

We've recently set up a new project, Neapolitan Wikisource, that is exactly the best example of how it is difficult for a new project to be set up and start from scratch. With a proposal such as this one, we could have had automatically all the templates we needed, instead of wasting more than one month in cleaning up the non-existent Multilingual Wikisource templates and replace them with other templates we needed (and needed to import separately).

Let me also do the example of Neapolitan Wikipedia, which I'm trying to revive with other users: we are having lots of problems in importing templates from the Italian Wikipedia (just because we're more used to them - but this is exactly the same problem you accuse English Wikipedia of), mostly because they became so complex that we need to import at least 10-12 Lua modules with them, without even being able to get to translating the parameters! All of this because it's "easier" to import templates that already have the possibility of calling data from Wikidata, instead of setting up new templates on our own, because we don't have the time or the skills.

Most of your perplexities are right, but the assumption that this proposal is going to hinder German Wikipedia's "independence" is theoretically and factually wrong. Moreover, and sorry for my bluntness, all I take from your interventions is that other users who need such proposal to become true for the benefit of their projects should be prevented from having what they ask, because of your fears.

" w:en:Module:Delink ... not a good example for a culture independent implementation ... expecting the values 'no' and 'yes'"

It is a perfect (and perfectly good) example.

Here is the current Module:delink on Arabic Wikipedia: https://ar.wikipedia.org/wiki/وحدة:Delink

Note that it incudes strings such as "if", "return", "else" and "local function", not to mention the comment "Check for newlines or multiple pipes" - and is expecting the values "no" and "yes".

There is no German equivalent for comparison, but the French, Italian and Spanish versions, for example, also expect the values "no" and "yes".

I'm quite sure that the German Wikipedia community are capable, if they so wish, of opting out of a shared Lua/template repository, just as they have opted out of a other good initiatives common to many other Wikipedias. That does not mean that you/they can prevent the creation of a service that will be useful on almost 300 other projects.

---

"English Wikipedia is expecting everybody in the world to use their code written for an English community" That statement is not only false and baseless, but offensive.

Two completions to my statements above:

1. Regarding "\u007FUNIQ%w*%-ref%-%d*%-QINU\u007F" in w:en:Module:Delink:
   • The pattern of the perfect (and perfectly good) module will match decimal digits 0-9 only and will fail as soon the <ref>  in link is the tenth in page since that one is numbered 0000000A and that does not fit the pattern in %d – it needs to be %x.
   • This code was never thoroughly tested.
   • The hexcode was in rMW/includes/parser/Parser.php #line 1170 sprintf( '%08X', $n++ ) also in 2013/14 when the Lua module has been written.
2. In addition to citation stuff, it is necessary quite often to write title and name of involved persons and publischer and location in current scripting.
   • Let us assume d:Q30487 Горбачёв, Михаил Сергеевич
   • In English, that is provided in latin letters: Mikhail Gorbachev
   • French people would add: Mikhaïl Gorbatchev with additional t and differing ï
   • German speakers announce: Michail Sergejewitsch Gorbatschow
   • Citation is very language and culture and policy dependant and not to be resolved just by pushing the one and only solution of a global template to be obeyed by everybody.

If you have any evidence of anybody "pushing the one and only solution of a global template to be obeyed by everybody" then please provide it; otherwise, it appears that you are deliberately ignoring what you are being told, by more than one person, about that not being the case.

Such behaviour is disruptive, and continuation of it will result in me and, likely, others, disregarding your posts.

> Citation is very language and culture and policy dependant and not to be resolved just by pushing the one and only solution of a global template to be obeyed by everybody

As I already noted a couple of times above, pushing the same presentation format to be obeyed by everybody is absolutely NOT the intention of this proposal.

The intention is to find a good way to share the internal code and internal data representation that can be shared without breaking anyone's stylistic, linguistic, and cultural norms.

Thanks for the long list of stylistic differences in the earlier comment. They are very useful. I edited the proposal to reflect some of them, and I will add some more things based on it.

I agree with the concern that English Wikipedia seems overpowering, largely due to it being the original language for many programming languages, as well as for Wikipedia, itself, and widely used. This makes it easy to define standards by it, which can limit others by ignorance. I believe the concern is off topic for this conversation, at this point, though. Similar feelings occur everywhere. I think many enwiki editors kind of fear WikiData in a similar way. I don't really see how this can be addressed from the perspective of this document any further. It is up to the template editors, who need support from those who care. For me, as a template editor, I feel such support from this document, with the understanding that it is not necessarily defining implementation, rather setting design goals. (It should be revisited if implementations don't meet this goal.) I don't really feel pressured to use this at all, let alone in any certain way. It appears to just be proposed as an available option, very valuable in certain cases. If a project decided to turn off local templates completely, I would feel limited, but that would be a concern of that project. You never know what will happen with a project, but this is going in the right direction. I appreciate the effort.

Thanks, @PC-XT, that's indeed the intention.

It's actually OK to think about the implementation and the impact early. I already used some of @PerfektesChaos' comments to improve the document. I'd just rather treat these comments as concerns, as suggestions for improvement, or as indications of potential problems, but not as blockers.

Good. I didn't mean to make it sound like the issues weren't helpful at the time they were posted, just that they currently seem to be addressed well.

Hello, quick comment.

Even though ideally we would have thousands of experienced editors in all projects, that is not feasible.

Some functionalities are, then, restricted to big projects, such as de wiki and en wiki. That is super bad, and locks smaler projects in a lower status.

I prefer using parameters in English to have some functionalities (ex: Lua modules importing data from Wikidata) than leave some projects forever without proper update on some topics. Of course, cultural distinctions and internal consensus are important, but some things shared across projects need to be common.

Thanks @TiagoLubiana :)

Even though I am promoting the idea, I am even more reserved about formulating it: Instead of saying that some things need to be common, I am saying that it must be possible that some things will be common.

Hell @Amire80,

I appreciate your reservation, it is good to make a more neutral starting point.

I did not intended to mean that you implied this. To be clearer, in my view (and considering my needs as editor) we really need this for ptwiki and other smaller projects.

Yes, we need this for all wikis, big and small :)

Hi, excuse me if I ask about topics already talked or known by the group.

In cawiki we've the more used infoboxes running in multilingual, it is, are able to show the results in language of your preferences or that given in lang= parameter.

Now, we're preparing a beta version of Infobox person able to handle some requirements of this project, like understand manual parameters in local language and be able to personalize infobox labels when desired a different value that infobox get from WD. I have several questions to ask/share in order to know/define how to build the solution. The first is about a global aspect of project.

A template, for instance the infobox person, runs in an environment of modules and templates installed in cawiki. Most of them are similar, may be equal, in all the WP. But, before we arrive to the perfect world, to install this infobox in another WP or in the future common space for Global templates, will require be aligned with the version it expected.

For instance, this "infobox person" includes 10-12 own sub-templates, that obviously don't exist in target platform, and 10-15 "pseudo global" templates, like "If empty", "Dir", "String", "Align", etc. With this second group, we may have to verified that installed version (the invoked one) in the new environment (local or global) fit with our requirements (in invoke one).

If it fits, the "global one" gets, de facto, a constraint for future changes (in order to keep compatibility) when we try to upgrade it with new local improvements. Otherwise, if do not fit our requirements, we will need to import our version, renaming it to avoid collision with the present one. Does our (imported) version accomplish Global requirements when, initially, it's only used by our tempate ?.

In addition, does "the existing template fits" mean that accomplish 100% the "Global Template requirements"?. For instance: do we need to have local version of parameter names for those technical templates that are only used from another templates ?; what's the difference in comprehension skill between the english name of parameters and the wiki code itself ?.  I open this topic (that I'll discuss in future discussion entry) because, as more restrictions to be "Global", more versions we'll have.

The consequences are:

• We need to manage, in a common environment, several versions of a "conceptually equal" element.
• Change invocation to templates and modules inside other templates by a variable name in order to switch it when changed.
• To have a revision process to try to upgrade versions to the "global one".

In a few days we'll be ready to install this beta version in WD and we'll have a list of collisions and which solution we do. I do not expect to have heavy problems because there are few common templates in WD platform and our version is, by now, the best version. However, it will not be so easy in WP platforms.

Thanks for your comments or corrections

So, you are basically asking about template dependency management? It sounds like this is planned to be rolling/versionless. Currently, I use version information in the template name, if needed. For this, we could probably use a prefix to specify the global version for any cases where a local override would be problematic, but when we need to update a lot of local subtemplates to a new breaking API, for instance, the template should probably include a way to specify API version in the new API, and flag deprecated and broken APIs. Most of this sounds like it can be handled, but I'll be interested in hearing updates.