Topic on Talk:Global templates/Proposed specification

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