Page MenuHomePhabricator

Months-long delays in deployment of CentralNotice translations
Open, Needs TriagePublic

Description

On January 28th l10n commits to master branch had been ignored in wmf_deploy branch over 10 weeks. As of March 9th they have been ignored over 5 weeks.


Original report

Steps to reproduce:

  1. Search for ntralnotice-campaign-view-logs

Expected: results from uk.json
Obesrved: no results from uk.json

Search for https://codesearch.wmcloud.org/search/?q=.&i=nope&files=uk.json&excludeFiles=&repos=Extension:CentralNotice

Click i18n/uk.json -> click view logs to end up in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralNotice/+log/ddb8c60bc113b40b88b618cafe2f84184667eeab/i18n/uk.json to see that it is using a file from 7 months ago.

Event Timeline

For context, I'm debugging a report why a translation is not showing up on meta.

I also noticed https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralNotice/+log/refs/heads/wmf/1.36.0-wmf.27/i18n/uk.json is not a recent version and that there is a separate wmf_deploy branch. But I don't know why that would affect code search.

Does someone know what is going on?

CentralNotice is really special, the wmf branches don't work and won't be deployed to production at all. wmf_deploy is the branch that gets deployed to production. Fundraising tech knows better. I investigate on codesearch side to see how this can be improved.

hmm, the main branch of this extension is wmf_deploy, which was updated last in the commit you mentioned (which is two months old not seven, the file wasn't touched from two months ago until seven months ago). That seems like it's not an issue with codesearch TBH.

thcipriani added subscribers: AndyRussG, thcipriani.

Indeed the mainline branch is wmf_deploy for that repo. The master branch of that repo is not meant to be deployable at any given time and is used for development is my understanding. Previously, the wmf_deploy branch was deployed on wmf branches directly. Now we cut a new branch from wmf_deploy each week as part of train to simplify branch cutting and back-porting (i.e., it was the only extension we deployed but didn't branch, backporting to a single branch required a fetch/deploy on two production branches, all that is solved by branching from wmf_deploy each week).

@AndyRussG would be the person to ask about when translations will get backported.

Pikne subscribed.

Currently last translations in wmf_deploy are from January 28th, while master branch has 16 l10n commits since then. That's not normal, right? Should L10n-bot commit directly (or backport immediately) to wmf_deploy, or...?

These (lacking) translations are much more prominent now that there's "Banners" section in user preferences in all wikis.

Pikne renamed this task from Code search index for CentralNotice is 7 months old to Months-long delays in deployment of CentralNotice translations.Mar 9 2021, 9:53 AM
Pikne added a project: I18n.
Pikne updated the task description. (Show Details)

Hi! Thanks so much @Pikne, @thcipriani, @Ladsgroup and @Nikerabbit, for digging in here! Also many apologies for the delay in replying.

So far I guess I don't see an issue with translation deploys, so I think the new task name is incorrect. The age of deployed translations looks to be the same as the time since the last general merge from the master branch to wmf_deploy, which was 2021-02-01.

See:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralNotice/+log/refs/heads/wmf_deploy
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralNotice/+log/refs/heads/wmf_deploy/i18n/uk.json

The version branches are automatically generated from the wmf_deploy branch, and that's what goes out on the deploy train each week.

Here is the log for uk.json file for the currently deployed branch:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CentralNotice/+log/refs/heads/wmf/1.36.0-wmf.33/i18n/uk.json

Furthermore, I can see on Meta new translations for the recently deployed banner filter feature (make sure you're logged in to view this link):
https://meta.wikimedia.org/wiki/Special:Preferences?uselang=fr#mw-prefsection-centralnotice-banners

I'm not familiar with the codesearch tool... I guess there might be a problem there? Also, it's possible that there was a mistake made sometime in merging CentralNotice changes from master to wmf_deploy that caused some translations to be left behind, so if you still see an issue, that's also a possible place to dig in.

Thanks again and apologies again for the delay!!

The age of deployed translations looks to be the same as the time since the last general merge from the master branch to wmf_deploy, which was 2021-02-01.

That's considerably older than translations of other components that normally go out on next week's train. Before last merge translations were over two months old, as indicated above.

Yes, messages that were translated in January are deployed, including French ones. E.g. new tab text prefs-centralnotice-banners has 17 translations in wmf_deploy. While in master to date it has 35 translations of which over half aren't deployed.

Maybe for non-l10n commits it matter less when they get deployed, but it's quite confusing for translators if it takes that long to deploy certain translations. As a translator/user I'd expect that there's some smoother workflow and translations would get out at least weekly (though also a poor solution compared to daily localisation updates that are now disabled).

The age of deployed translations looks to be the same as the time since the last general merge from the master branch to wmf_deploy, which was 2021-02-01.

That's considerably older than translations of other components that normally go out on next week's train. Before last merge translations were over two months old, as indicated above.

That's the way it's been for years. Updates to CentralNotice are not automatically deployed because of possible impacts on Fundraising campaigns.

Maybe for non-l10n commits it matter less when they get deployed, but it's quite confusing for translators if it takes that long to deploy certain translations. As a translator/user I'd expect that there's some smoother workflow and translations would get out at least weekly (though also a poor solution compared to daily localisation updates that are now disabled).

So, just to clear:

  • This is not a software bug; systems are working as expected.
  • If anyone would like to request that this be changed, they're quite welcome to file a ticket, in those terms, and it can be considered as such.

Thanks so much!!

These (lacking) translations are much more prominent now that there's "Banners" section in user preferences in all wikis.

If there are currently undeployed translations for the Banners tab in User Preferences, then, yes, I think they should be rolled out as quickly as possible. Most translations in CentralNotice are only seen on Meta by CN Admins, so this is a bit of a new situation. However, a general change in the CN deploy strategy from manual to automatic doesn't feel right, tbh (though again, if that's the ask, pls do file a ticket for it). Thanks again!!

... a general change in the CN deploy strategy from manual to automatic doesn't feel right, tbh (though again, if that's the ask, pls do file a ticket for it).

I suppose we can also further edit the description of this task so that it was more explicitly about more frequent deployment of CN translations. Though, I don't know what'd be suitable options to achieve this. Above I wondered if L10n-bot could perhaps backport its commits immediately (automatically) to wmf_deploy. Maybe you and @Nikerabbit can work this out.

We don't currently have tooling support for doing backports. This is tracked in T272830: Support doing translation update backports to stable branches.

Above I wondered if L10n-bot could perhaps backport its commits immediately (automatically) to wmf_deploy.

This does sound like a reasonable solution, though I guess I know of too many more urgent issues for CentralNotice... Here's a task for the immediate problem of message on the Preference pages: T278055. I think we can get these on the train this week, and then push another batch out soon, too, as more of those translations come in. Thanks again!!! :)