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.