User talk:Cscott/Ideas/Integrating MediaWiki

Alternative proposals

For a different opinion, see Simplifying the WMF technology stack.

feel free to add links to other alternative proposals here.

Comments from Aharoni

Making services and extensions easier to install and bundle

I support this. When third-party users ask me about MediaWiki, their problems can almost always be resolved by installing VE or Flow... both of which require Parsoid. Or Content Translation, which requires cxserver. And many of them are scared of installing services, because they are different from extensions. And occasionally they are scared of extensions, too.

But this is a very general issue that has little to do with language support, so I don't think it needs a lot of input from me.

I will note, however, that when people want their wiki to work like Wikipedia does, this involves not only extensions and services, but also templates. And packaging and porting templates is way harder than packaging extensions and services. More precisely, packaging and porting templates doesn't really exist. That is an area that will need attention as well. It's hard, but it must be remembered. --Amir E. Aharoni (talk) 12:07, 17 October 2017 (UTC)

Oh yeah. I think I briefly mention the "global" extensions, but it's probably worth more explicit discussion since as I understand it the Shadow Namespaces/Global Templates/Global Modules work has been back-burnered. C. Scott Ananian (talk) 02:34, 18 October 2017 (UTC)

Added a new paragraph to address this. C. Scott Ananian (talk) 02:57, 18 October 2017 (UTC)

Third-party

"The first step to remedy the situation is to acknowledge third-party users of MediaWiki as a first-class Audience": This is a good idea in MediaWiki context, but in WMF context it will be criticized by some people as deviation from the stated goal of the WMF which is free knowledge. Similar ideas were voiced in the past; the next step was always a suggestion to split the WMF to a free knowledge foundation and a MediaWiki foundation, and then the discussion would die down.

This doesn't mean that these are bad ideas. They are possibly good ones, but let's not repeat the mistakes of past discussions. --Amir E. Aharoni (talk) 12:07, 17 October 2017 (UTC)

So could you suggest a rewrite of that paragraph that would thread the needle of previous discussions better? I'm not sure I personally think that having a separate MediaWiki foundation is a good idea, and I can see how it can be a discussion killer. From my perspective, "free knowledge" means cultivating a robust open source community around our software, and that requires properly encouraging third-party users. If no third-party users exist, there can be no third-party contributions, and we haven't fulfilled our mandate to support the community around our software. I think I take a glance at this in the footnote by insisting we not try to "prequalify" potential users based on their contributions to free knowledge---ie, we'll support NASA as a third-party user because they use their wiki to publish free knowledge content, but we'll not do anything about the use cases Microsoft is interested in, because their MediaWiki instance is for internal use only. I'm trying to make the argument that the free knowledge community is better off when MediaWiki is robustly supported by the community, so we should just the "Audience" team by "size of community" metrics. "Large community" => "better for free knowledge", we don't have to try to argue about who is in the community and whether they are people we like or not. But I'm clearly not making that argument well (even this comment is unfocused), so I could definitely use help reshaping the text here. C. Scott Ananian (talk) 02:44, 18 October 2017 (UTC)

The same MessagesDirs mechanism

"The same MessagesDirs mechanism used in extension.json should allow localization of messages used by services as well, well-integrated with translatewiki and our other language infrastructure." - Yes, please!!! And there's a pretty clear path to do it:

1. MediaWiki's PHP and JavaScript code have different implementations of similar message parsing functionality (see below for details). They also have separate testing suites. Since the functionality is so similar, the test suites should be unified as much as possible.
2. If the service is written in Node.js, then it should use the same JavaScript code as MediaWiki core does. The problem is that MediaWiki uses two versions of JavaScript internationalization code: the independent jquery.i18n library, and the code inside core itself. They are similar, but not identical in functionality. So:
   1. The features of the core code that are missing in jquery.i18n should be added to jquery.i18n.
   2. The core code should be removed, and the core should depend only on jquery.i18n.
   3. The jquery.i18n code should be rewritten in a way that does not depend on jQuery and can be used with Node.js.
      1. This will have the added bonus of giving the world a damn good reusable library for internationalizing server-side and client-side web applications. I wish the whole world used an i18n stack that is as good as ours. It's not just hubris: it will actually make internationalization better for everybody, and given that a Wikipedia project in any language is usually as successful as the general Internet culture in that language, giving better internationalization to all projects will help Wikipedia, too.
3. It the service is written in PHP, then it should use the same PHP code. The PHP code is currently tightly coupled with core. Niklas suggested splitting them into an independent PHP library. This was dismissed by some people because JavaScript appeared to be a more promising future direction than PHP, but now there is some talk about a possible PHP comeback, so maybe it's time to revive this librarization idea as well. (I'm not saying whether getting back to using more PHP is a good or a bad idea. I'm too stupid to make this judgment. I just care about good language support functionality.) --Amir E. Aharoni (talk) 12:07, 17 October 2017 (UTC)

Sounds good to me! (Although jquery.i18n might be the wrong name once it doesn't depend on jquery anymore...) C. Scott Ananian (talk) 02:45, 18 October 2017 (UTC)

Of course! I even thought of some names: i18n.js, Gili, Lin Shu, Boris, Omana. I'm flexible :) --Amir E. Aharoni (talk) 13:07, 19 October 2017 (UTC)

Wow: I emphatize with Lin Shu! Seems like a great namesake for the wiki project, which is so large no one person could ever hope to read all the languages it contains. C. Scott Ananian (talk) 21:22, 31 October 2017 (UTC)

See also

• https://www.mediawiki.org/wiki/User:Tgr_(WMF)/Make_MediaWiki_commercially_viable
• https://www.mediawiki.org/wiki/MediaWiki Stakeholders' Group