To ensure the best user experience to all our users, whatever language they speak, we need to minimise exposure to untranslated messages and maximise our ability to correct mistakes in translation. Satisfying users of all languages has highest priority in the Wikimedia mission ("people around the world", "globally").

In MediaWiki, for many years now, this has been achieved by a process known in the industry as continuous localisation, where i18n code and l10n strings iterate quickly in an immediate feedback loop between developers, translators and users. This means that developers develop good quality messages (both i18n and l10n) at the same time as they develop all their code; translators immediately receive those messages and submit their translations, proving either that they're translatable or that some i18n fix is needed; the two groups are in constact contact (here on Phabricator mostly) to surface any i18n issues, which can therefore be corrected when the cost is lowest i.e. at the same time as initial development occurs; users see the translations immediately, so that any possible improvements are spotted (given enough eyeballs, are bugs are shallow) and ideally executed on the spot (all our users are also editors and translators, or can be).

Thanks to Raymond's daily work, translatewiki.net is able to guarantee the maximum service quality to all MediaWiki repositories, which receive up to date translations every day, i.e. typically within 24 hours from the time translators provide them. Import runs every few hours, this means we're able to guarantee that a message is translated on the live wikis within 40 hours from being added, and possibly as little as 4 hours.

The most obvious solution to the problem is to run the existing l10nupdate every day. Any part of the infrastructure which happened to exhibit problems with this will need to be fixed consequently. This regression has lasted already way too long for us to continue sustaining its enormous opportunity cost. Micro-optimisations can and should be performed with lower priority. We know that this is not some unsolved problem in computer science because we already fixed it for 10 years. The need for a daily run will be considered for any refactoring or code change in the deployment systems, as a non-negotiable premise just like the daily sunrise.

The current configuration regression (T164035) also places an undue burden on individual deployers who are forced to extracurricular duties to guarantee mission-critical service (T203297#4564753, other one-time deployments etc.), negating also any short-term benefits it hoped to bring (T158360#3127368).