Requests for comment/Reevaluate LocalisationUpdate extension

LocalisationUpdate has had its time?

Background
LocalisationUpdate comes from a time when MW deploys were far and few between, meaning l10n updates made into master of MediaWiki core, and various WMF extensions were deployed at most a few times a year. For the last few years (mostly since post SCAP rewrites), this hasn't been the case. Deploys of master of MediaWiki core and extensions happen on a weekly basis (bar when the deployment train is delayed due to special events and holidays).

Use case
Translations must reach the live wikis quickly (definitely less than a week), so that translators see the effect of their work and users always have the best translation on all wikis.

When translations take multiple days to be applied to the wikis, what typically happens is that local administrators start applying the translations locally and eventually the translations diverge and have to be cleaned up with costly processes (cf. T45917). If the delay becomes systematic, translators give up on translating important strings and instead take care only about the wikis where they're administrators, hence making MediaWiki worse.

Such issues emerge very quickly: a list of new cases easily finds examples such as.

Problems of the current deployment systems

 * LocalisationUpdate and Scap fight - LocalisationUpdate deploys updates, any subsequent scaps then override these changes until LocalisationUpdate runs again the following evening.
 * Deploys of code and Localisation Update happen at a time when not many people are around. There is the potential of staged but not-yet-deployed changes on WMF deployment servers being deployed unknowingly.
 * This is somewhat mitigated by the fact l10nupdate uses its own directory structure to work, not /srv/mediawiki-staging (but still, it's theoretically possible someone populates these directories)
 * Routinely breaks without anyone realizing or knowing how to fix
 * No one is responsible for the code, those who support it do not understand it
 * Legacy shell scripts, independent of Scap
 * Weird mix of www-data and l10nupdate owned files on various hosts. Makes cleanup of older branches more difficult

Proposals

 * 1) Make sure LocalisationUpdate works consistently and translations are deployed within 24 hours from being committed.
 * 2) Give up on a general solution for the use case and accept a permanently decreased service with periodical cleanups needed:
 * 3) * disable and completely remove LocalisationUpdate from all WMF wikis;
 * 4) * allow SWAT windows to do scap deploys of new/updated messages where these updates are required for events, or specific launch of a feature ahead of the general train deploy;
 * 5) * set up a system to identify diverging/redundant translations and fix them manually.