What happens to LocalisationUpdate in the short term, will it continue working as usual? LU was mentioned in Thread:Talk:Requests for comment/Localisation format/Motivations but is not addressed in the proposal's text.
Topic on Talk:Requests for comment/Localisation format
FYI: LU2 was mentioned, not the current LU.
In fact I said LU and not LU1.
I believe that until LU is updated, extensions that have been converted to JSON won't get the daily updates of translations (but they will when anyone scaps, which happens at least weekly).
Thanks James for the answer. That's unfortunate, I expect lots of confused translators (for each translation you need to know if it's using json or not). I hope it's not too hard to update LU (be it 1.1 or 2).
I would argue that translators expecting out-of-process localisation updates are the ones who are confusing others. "This software doesn't changed at all except on Thursdays. Oh, except for messages. And things that look like interface components but are actually strings of advanced formatting." We may wish to re-visit whether we use this in future, or move to a more frequent deployment process that has only very rare exceptions.
What are "out-of-process localisation updates"? The current process (since a few years ago) is the daily sync via LocalisationUpdate. Out of process updates would be syncs to master/cherry-picks, manual changes to l10n or manual runs of LocalisationUpdate. Is this what you mean?
No, you have it the wrong way around. LocalisationUpdate runs daily because we used to do regular updates only every few weeks or even months, and so localisation updates were significantly delayed in being released.
However, I don't think that it's even been a satisfactory outcome to have random localisation cache issues created by a bot in an unattended, out-of-process production deployment. Nowadays given that we do production deployments almost every day, it's an unnecessary complication and weakness in the integrity of the service we offer our readers.
Most deployments don't update messages though. Given the rapid changes in the software, it is not okay that translators have to wait up to two weeks until the untranslated strings in the interface are replaced with translations.
Where on Earth is "two weeks" from? Reedy's deployments every Tuesday and Thursday do full scap runs even if no other deployments happen. Unless you mean at Christmas/etc.?
New strings added on Wednesday. Translation is added on Thursday. Reedy makes a new branch. Raymond exports translations later that day. Next Thursday new branch is created which contains the translation. Next Thursday after that Wikipedia finally starts using that branch.
With LU the translation will be there late Thursday on the same day it was made.
Perhaps you are imagining a solution in the middle, where LU runs every day, but only on deployment server and only scap would push it out to production?
Yes.
That however would "only" be a change in the l10n-update script at WMF; the extension would need to be fixed first anyway.
James, it's not clear to me if you oppose proposals such as Mentorship_programs/Possible_projects#Generic, efficient Localisation Update service too. We'd need to figure it out before GSoC application period begins.
We do not need James' approval for LUv2. The service will be useful to 3rd parties (of MediaWiki, maybe also other products) and it is then up to WMF to consider if they want to use it.