Change Details

Translation workflow was the biggest pain point of fixcopyrightwiki. The workflow was something like * add / tweak English version in git * translate in translatewiki.net * translatewiki.net maintainers manually export to gerrit once a day via script * merge patch after legal review (of certain languages) * [[https://wikitech.wikimedia.org/wiki/LocalisationUpdate|LocalisationUpdate]] runs once a day and copies from git to target wiki For a campaign that's rapidly changing in the last days before the vote, this is excruciatingly slow (about a day to go live if the gerrit export and L10nUpdate are well coordinated, about two days if they aren't). Especially so for English so people edit it in the wiki DB directly, which causes all translations of that message to revert to English - oops. (I'm not entirely sure if that's due to fallback order, as in T3495, or due to LocalisationUpdate skipping messages where a local override exists and is different.) Also the whole thing is somewhat fragile (as shown in {T204040}). We need to come up with a better workflow that allows near-realtime update of translations while stills makes it possible to hold back changes in select languages for review.

Translation workflow was the biggest pain point of fixcopyrightwiki. The workflow was something like * add / tweak English version in git * translate in translatewiki.net * translatewiki.net maintainers manually export to gerrit once a day via script * merge patch after legal review (of certain languages) * [[https://wikitech.wikimedia.org/wiki/LocalisationUpdate|LocalisationUpdate]] runs once a day (except on weekends - T203737) and copies from git to target wiki For a campaign that's rapidly changing in the last days before the vote, this is excruciatingly slow (about a day to go live if the gerrit export and L10nUpdate are well coordinated, about two days if they aren't). Especially so for English so people edit it in the wiki DB directly, which causes all translations of that message to revert to English - oops. (I'm not entirely sure if that's due to fallback order, as in T3495, or due to LocalisationUpdate skipping messages where a local override exists and is different.) Also the whole thing is somewhat fragile (as shown in {T204040}). We need to come up with a better workflow that allows near-realtime update of translations while stills makes it possible to hold back changes in select languages for review.

Translation workflow was the biggest pain point of fixcopyrightwiki. The workflow was something like * add / tweak English version in git * translate in translatewiki.net * translatewiki.net maintainers manually export to gerrit once a day via script * merge patch after legal review (of certain languages) * [[https://wikitech.wikimedia.org/wiki/LocalisationUpdate|LocalisationUpdate]] runs once a day (except on weekends - T203737) and copies from git to target wiki For a campaign that's rapidly changing in the last days before the vote, this is excruciatingly slow (about a day to go live if the gerrit export and L10nUpdate are well coordinated, about two days if they aren't). Especially so for English so people edit it in the wiki DB directly, which causes all translations of that message to revert to English - oops. (I'm not entirely sure if that's due to fallback order, as in T3495, or due to LocalisationUpdate skipping messages where a local override exists and is different.) Also the whole thing is somewhat fragile (as shown in {T204040}). We need to come up with a better workflow that allows near-realtime update of translations while stills makes it possible to hold back changes in select languages for review.