T242918 Spike: Investigate WWT Expansion [4 hours] (original) (raw)
Adding new languages
According to the maintainers, adding new languages is mainly an issue of lack of manpower. We cannot be granted access to the WikiWho servers, and it seems there is no system for publicly contributing to their server configuration. I am told this is being investigated more, in hopes we can at least partially assist with adding new languages via pull requests on GitHub. This would still require a fair amount of commitment on our end, as we'd need to acquaint ourselves with their stack, and possibly do a lot of testing to ensure accuracy of the data. Overall, it seems that unless there is a Wikimedia-funded grant of sorts, it is unlikely the WikiWho team will be able to work on this independently.
The WikiWho algorithm is open-sourced, so we could instead host it and the data ourselves. I expect this to be an unrealistic amount of work for us in the short-term, however. It would be a slow process involving multiple teams and possibly acquiring new hardware.
Adding support for other namespaces
Similar to above. This is possible but requires manpower and/or funding that the WikiWho team doesn't have. I suspect this will be more time-consuming than adding new languages.
Making a WWT gadget or extension
There are two options here -- either a "global" gadget, or a MediaWiki extension. In both cases we will need to do some rudimentary browser testing. There are a few things in our code that don't work in IE 11, some of which are easily fixable. We aren't required to support IE 11 either (even as an extension), and I think it's fine if we don't so long as it's clearly explained in the documentation. It's possible there are compatibility problems with Safari too, but other modern browsers should be okay.
Global gadget
We were doing this before, and it seemed to work, so I think there's no technical barrier to restoring it.
The system could mimic MoreMenu or HotCat, where the code lives in one place on Meta and the applicable wikis will import it into their local gadget. Translations live as separate JS files, and the appropriate one is loaded based on user's interface language, falling back to English. In the Grunt build step for the gadget, we'd generate these JS files from the JSON similar to what we're doing now. We can use a simple Node script to sync the files with the wiki.
Advantages:
- Easiest and quickest way to get WWT to non-Chrome/Firefox users. We don't need security review or any work involved with getting it into production, and we had a working system of gadgetizing that we can revive.
- Easily QA-able.
Disadvantages:
- Code could in theory be forked and the "global" version maintained by us isn't what is seen on the relevant wiki. This is low-risk I think, since other long-standing gadgets use this same system without issue.
- The code that lives on-wiki will be the transpiled version of the ES6+ code, meaning it might be hard to read. I don't think this is a huge risk either, since we can write in the comments to refer to the original source code for reviewing and proposing changes.
- Requires manual deployment, but this should be much more simple than deploying the browser extension.
MediaWiki extension
Advantages:
- Allows us (and those with +2 rights) to have complete control of where the tool lives (e.g. only the applicable wikis) and the codebase itself.
- i18n system is already in place (don't need to load all languages or write code to tell it what language to load).
- We don't need to worry about the Content-Security-Policy headers (T135963) blocking users from using the tool (presumably they'll have to manually whitelist our API proxy, see T208188).
Disadvantages:
- We possibly will need a separate code repository just for the extension (?)
- Requires security review, along with time and resources to set up the extension and get it deployed to production.
- Possibly no way to QA before deploying to production, since there is no WikiWho data for wikis on the beta cluster.
- Currently, our use of ES6+ may not be acceptable for MediaWiki. I think we can just override the linting rules with our own, but this is probably discouraged.
- Introduces a dependency on an external service in MediaWiki. I don't think this is strictly disallowed, but it doesn't feel right to me, personally.