Participants: Grant, Adam S. , Niklas, Fisch, Petr, Tobi, Reedy, Quiddity, Galder, Tgr, Daniel, Will D., TPT, Brooke
Facilitation: Brooke
Notes: Quiddity, Niklas, Amir, TPT

AA: Example. MLK article: https://en.wikipedia.org/wiki/Martin_Luther_King_Jr. This is the same article in the N'Ko language: https://nqo.wikipedia.org/wiki/%DF%A1%DF%8A%DF%99%DF%91%DF%95%DF%8D%DF%B2%DF%AB_%DF%9F%DF%8E%DF%95%DF%8D%DF%99_%DF%9E%DF%8C%DF%B2%DF%9C%DF%AD_%DF%98%DF%90%DF%B0%DF%A1%DF%8A%DF%B2 . This wikipedia started a few weeks ago! They asked "how do we make a table like this?" - referrring to bio infobox. They made a wikitext table, because don't have the skillset to make a complex template. Just one example out of thousands.
Making templates global has been a common request, since at least 2004. There were some steps towards the goal, but not enough.
See also the earlier topic about onwiki tooling.
Today I hope we can break the task up into smaller chunks. In particular:

• Frameworks (perhaps from Petr?) . I think it's something about: Get authors to write better templates and modules that don't break the parser. Hopefully the CPT can help.
• Doing just modules and first (and not templates) can perhaps solve 70% of the problems.
• Dependency tracking

What are the blockers to make modules global?
DK: It should be fairly straightforward? I don't know what's stopping us.
Reedy: Prioritization
Just dependency tracking ( https://phabricator.wikimedia.org/T238412 ). Needed for change propagation.
TPT Is getting the data from one wiki to the other efficient?
DK Yes, it has been made possible with the MCR migration (multiple content revision).

GT: Does it happen by magic, or does the user have to specify that "i want to use a global/local template". Global module A uses global moduel B. How do you use global module A, is there a specific call? And then local module B?
AA: The first question is a product-level question, and the answer to it is definitely "Magic". I want the conversations between the N'Ko editors (or from any other language) and me to not even have to happen. It must be immediately available. The second question is how ... Local overrides is necessary, but I don't know how it would be implemented.
DK: approach of name resolution, checking locally, if there's no local, go global. Then load global content into local context, and evaluate in local context, and resolution would happen. So that [? local resolution doesnt get applied to global code]. This all assumes that local and global usess the same names. If we want to have translated names for template/modules that gets more complicated.
AA: Translated modules probably isn't needed, because they're generally not used directly in articles. We can make it a recomendation/requirement not to use them in articles.
R: i guess it would be ok if we didn't have the wrapper. If it's just the basic things, is that a problem?
AA: The important requirement is that if there are wrpper templates in diff wikis, they're mapped to each other without ???? So it won't happen as it did with interlanguage links before wikidata (with mass duplication of effort)., If I make a change to the global, the changes need to be shown immediately. The connections between the names should be stored in a structured way, and if nobody translates the template name then it just falls back to the default. Similar to magic words.
Galder: I helped created templates for the Atikamekw Wikipedia. I had first to first copy the module for infobox, copied the module for navbar, for units, for collapsible list, linking, coordinates, infobox row, etc etc. Hopefully we can solve this issue. If i include a global module, it needs to call many other global modules.
DK: my assumption would be that we need a variety of global module that depend on other global modules, but that a global module cannot depend on a local module
AA: That said. how feasible is it to start work now?
GT: Parsoid is in a code freeze now, and any changes in this area requires changes to code parsers, so we'd have to wait for that. Probably a few months.
DK: Modules aren't part of core
TPT: It's a parser function
DK: Loading mechanisms [for templates?] are currently baked into the parser which is unfornatute, but for modules shouldn't be a problem.

GT: Global usage extension does dependency tracking for images. Can it do the same for templates (and modules?)
DK: Does that do purging?
GT: Works the same way as the global usage extension. But it has a long tail of bugs... not a very friendly extension. Not sure if that's a lack of maintenance.
AA: Already started bulding a long tail of bugs for the project, i just want to know how long the tail is.
Grant: how would people find these global templates? Where's the catalog?
AA: Good question, heart of problem. New wikis are completely empty and have no templates or modules. Just a main page. Copying things over is how things are done. People editing the wiki decide what to create or copy over, completely randomly. We're especially trying to help the 200+ existing small Wikimedia wikis to bootstrap themselves. We also want to help share the innovation that happens in dozens of wikis. There's no library of available templates, they're usually found by discovering them in another page, or another wiki. This discoverability is part of the goal.
Grant: or have some place people could go publish them first. A marketplace type thing.
AA: Would have to be very convenient. [???]
R: Would have to have some type of repository
Grant: Another wiki? it's essentially crowdsourced content.
AA: I'm afraid that approach, marketplace, people will have to yet again take 1 step to make each template usable. Ideally it should be 0 steps.
GT: for modules (not templates), need a package repository, as its essentially for developers.. Either: use a central wiki, edit in a wikipage. Or treat modules as code, edit in a git repo. In either case might need a wiki for documentation, or that could be done in an external tool?
AA: That's partially address in my naive spec document ( https://www.mediawiki.org/wiki/Global_templates/Draft_spec ). The Git approach probable doesn't need any new technology (or maybe very little). If nearly all module developers are comfortable doing it in git, then it's perhaps viable. Preserves current benefit of immediate availability. But having it in Git may impede the immediacy, and if it does, then it's not viable.
DK: I'm for moving gadgets and into gerrit and maybe making a marketplace for them, but for Lua it's basically a more expressive way to write templates. Templates and modules are designed to give communities the freedom to structure their content. Currently hundreds of people working on templates, code review would be a mountain. Easy to sandbox Lua. Change management, ???? follow along with changes and change tracking in gerrit, same problem.
Galder: this would be a solution like Commons is for files? immediate changes from Commons are shown in local wikis. If we already have the same module in 900 wikis but have to copy it everywhere manually... if an innovative tool or function is created, but someone changes the final template, but not the global module, you'll have a problem because it will break somewhere as you haven't updated it. Need a good and esay solution for the final end user, even if this is more difficult for us.
GT: currently can still break a few million pages if you do something wrong. With global modules could break tens of millions of pages. Currenly have copy module to usersubpage, special:templatesandbox, and test. We need standard development workflows, testing CI, etc. Worried we'll end up with something like th old code-review extension where we reinvent a bunch of things onwiki.
AA: [action item] - create a task for a testing framework.
Grant: ??? there are libraries that can reduce the risk of breakage
R: essentially flagged revs fortemplates... Still using old versions everywhere.
AA: Points to example: w:en:Module:No_globals - used on 13 million pages. ( https://en.wikipedia.org/wiki/Module:No_globals )
DK: ability to test these things sanely is more compelling than code-review requirements which can be covered by social processes (and admins anyway). If we're tlaking about Proposed Edits, staging, flagged edits, that's a considerable investment in infrastructure and new code. But if we dont' ?? that means breaking. And breaking at massive scales.
Grant: do we bind to a version?
DK: No.
AA: If you look at an old version of a wikipage, it will show it to you with the current version of the module/template/transclusions. Someone tried to solve it by using git, but too complicated.
AA: Did we clarify dependecy tracking.
GT: That's the first thing i would try and see if it break horrily.

AA: Localization. Many things are currently in translatewiki. The same cannot be done in for templates and modules. What options do we have? Modules have almost same API as PHP code. How can we build system that stores these messages in a manner that is easily translatable.
TPT: If everyone can read whatever is in the mediawiki namespace, and create messages from strings, yes and yes.
GT: Using messages, or finding a way to store old messages in a single page for a single module. I think it's something we should move towards. Like JSON pages have a nice interface. Could use the same global lookup system for messages. If you use mediawiki-messages i'm not sure about the performance implications.
AA: Is it possible to make messages translatable and cachable?
DK: ??? but we don't want that, we want it to render in the content language.
AA: kinda already done for centralnotice? in a kinda terrible way, but...
GT: what type of system can be used if there are a hundred translated messages so that there aren't a hundred seperate lookups. Anyone know?
AA: And how does it work with Wikidata?
Galder: in catalan wikidata module, creates auto templates from wikidata, takes from wikidata property level, or have ??? where you can override this. So we do have something like this already there too.
TPT: Suggestion: store all the messages for a templates in one MCR slot, to store one big json with or one json per language. Could do one load per language. Similar to what is already done with Lua tables. //offine comment: the messages could be encoded in the same JSON format as MediaWiki messages. Change propagation could be done by considering that a message change is a module change filtered on the content language).
AA: Sounds like it's kinda maybe possible.
AS: thought of some things: in terms of global templates and purging 100,000,000 pages all at once, can we have a staged rollout?
AA: yes staged, modules first, and see if templates are still necessary. Even just global modules would resolve a LOT of things
AS: tests for templates.
AS: Forced review of a few pages where the template is used. "This template is used on 3 million pages, here are 5 of them, does it still work properly?"
GT: protection and forced review can be left to the community. people tend to be sane
[laughter]
GT: Currently for a module maintainer, wants to propose a change, creates a sandbox version and manually creates a diff link that shows the changes. Anything better than that would be good.
R: are we going to have a new central mediawiki wiki? Dependencies, fallbacks, local overrrides. Very similar issues to Commons.
AA: Probably a new wiki. Starting a new wiki is not a big deal. Similar to Commons for files and Meta for globaluserpages. Making it usable to sites outside to Wikimedia is desirable, if it isn't difficult. Global templates for any wiki.
AS: lots of things that line up with federated wikibase.
GT: versioning issue. One possible approach: Make a change on global wiki and it happens everywhere. Versus: change in central location and each wiki has to click a button to update locally. I think this is worth considering. Non-magical updates makes a lot of things easier. Fewer change propagation issues, and benefits for project owner. Easier to track changes.
DK: Maybe automatic applying with each version is not the thing we want. How about proper releases? Similar to stable releases in software.
Grant: wondering what the lowest entrypoint is here. Discoverability. Is there a way we could use toolforge, sparkjob, put them all in elasticsearch. Transclusion-count.
DK: We already have that information (list of pages where a given template is used). We have a list of all templates, but there are many many thousands of them.
Grant: is there low hanging fruit in post processing that?
DK: No
AA shows Template transclusion count tool on wmflabs - https://tools.wmflabs.org/templatecount/index.php?lang=en&namespace=828&name=No+globals
TPT: talking about revision change propagation, to things. 1) might want to call out a specific revision. 2) propagation step, do you want to purge all pages it's used in, manual selection at first. A "rollout" button for propagating everywhere.
GT: Playing around in my testwiki. Came up with a workflow I like: central page with list of modules where you can see which modules have been updated in a central wiki. You can manually update and no magic. Have the ability to test beforehand. Kinda already supported, just need a nice user interface for it. Ablity for branches and pull-requests and that kind of thing.
AS: Has parallels with federation again, caching etc. are things pinned, are they fluid, how do 3rd parties pull them in, etc.

AA: Conclusion: Thank you. Two questions: 1. I started cleaning tasks and their dependency trees about this topic in Phabricator. For some of these I will really need your help. 2. Do we have consensus for starting with modules?
R: i think it makes sense, modules (are simpler?) replace templates [?]
DK: Don't look at the engineers, look at budget owners.
GT: this is an extremey hacky existing implementation, using a bot ( https://www.mediawiki.org/wiki/Multilingual_Templates_and_Modules ). Should we start promoting that more widely, and adding PM-esque questions? Use it as a prototyping tool.
AA: probably makes sense as a first step. See how people start talking to each other due to this.
[applause]
"Developers often care more about source code than destination code. Let's think about destination code some more."

The session is done. It was very productive. Thanks to all the participants.

I'm going over the notes here and on T234661 and creating tasks based on them. Once all of them are created, this task be closed as far as I'm concerned.

@daniel I read the meeting notes and I see a part of conversation between you (?) and Grant and I'm not sure I understand your response. See:

DK: We already have that information (list of pages where a given template is used). We have a list of all templates, but there are many many thousands of them.
Grant: is there low hanging fruit in post processing that?
DK: No

Can you expand why you responded no to Grant's question?

In T238251#5673670, @leila wrote:

@daniel I read the meeting notes and I see a part of conversation between you (?) and Grant and I'm not sure I understand your response. See:

DK: We already have that information (list of pages where a given template is used). We have a list of all templates, but there are many many thousands of them.
Grant: is there low hanging fruit in post processing that?
DK: No

Can you expand why you responded no to Grant's question?

Because knowing which templates are used on which pages does not help with re-using templates on another site.

Maybe I didn't understand what Grant was getting at. Here is my take, based on what I understood:

Discoverability is not the issue, as far as I can tell: people discover templates by seeing them used on pages, or by looking at template categories (this could be made nicer, but that seems tangential for the problem at hand). The issue is that in order to use a template on another wiki, you have to copy it, and you have to copy all the things it in turn uses. And after you copied all the things, you will have to translate them and modify them so they fit requirements of the local language. And then things get out of sync, and diverge over time. I don't see how post-processing usage data is going to help with that.

@Amire80 / @Tpt: Thank you for proposing and/or hosting this session. This open task only has the archived project tag Wikimedia-Technical-Conference-2019.
If there is nothing more to do in this very task, please change the task status to resolved via the Add Action... → Change Status dropdown.
If there is more to do, then please either add appropriate non-archived project tags to this task (via the Add Action... → Change Project Tags dropdown), or make sure that appropriate follow up tasks have been created and resolve this very task. Thank you for helping clean up!

Thanks for the poke! I'm in COVID-19 mess at home, but I made myself a reminder to go over all of it and make last clean-ups ASAP. If I don't resolve it before the end of March 2020, feel free to close it yourself.

This has been a very interesting read. I have just one thing to note: while I get that immediate roll-out of edits on global modules has few, but significant, downsides, I'm not exactly supportive of a two-step update (first in the repository, then "press the update button" locally), since it may just take a few busy days or an innocent lack of attention to make a small wiki lag behind. I'm ok to use this approach for "phase 1", that is while we're still experimenting things and we want to make sure we don't run head-first into global problems, but in the long run I think it can be just abandoned in favour of an immediate update.