Page MenuHomePhabricator

Translate: Marking a page for translation removes priority languages
Closed, ResolvedPublic2 Estimated Story PointsBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Have a translatable page with priority languages set.
  • Edit the translatable page.
  • On the special page used to mark a page for translation, click Mark this version for translation without making any changes to the priority languages settings.
  • Check the Page translation log.

What happens?:

In the Page translation log, an entry saying
UserName removed priority languages from translatable page PageName
is recorded immediately before
UserName marked PageName for translation.

This happens even though the priority languages were not modified.

Example logs on MediaWiki.org:

What should have happened instead?:

Only the log entry
UserName marked PageName for translation
should be recorded.

No log entry about removing priority languages should appear if the priority languages were not changed.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

MediaWiki.org (WMF-hosted)

Other information (browser name/version, screenshots, etc.):

This issue was observed on MediaWiki.org using the standard page translation workflow.

Event Timeline

Change #1225083 had a related patch set uploaded (by SarthakSingh2904; author: SarthakSingh2904):

[mediawiki/extensions/Translate@master] PageTranslation: Fix incorrect "removed priority languages" log

https://gerrit.wikimedia.org/r/1225083

Thanks! No need to add a manual comment here; see the previous automated comment by gerritbot here.

The previous code only treated the input as a string (comma or newline separated), causing array inputs to be interpreted as empty/null.
This resulted in a false positive log entry claiming that priority languages were removed when they were simply being re-submitted as-is.

From the commit message, it sounds like only an incorrect log entry was recorded.
However, is it possible that the priority languages were actually being set to empty at that point, rather than this being purely a logging issue?

If they were incorrectly cleared, I wonder whether there is a need to identify the affected cases and restore the priority languages that were unintentionally removed.
Could you clarify whether the underlying data was modified, or if this was strictly limited to the log output?

However, is it possible that the priority languages were actually being set to empty at that point, rather than this being purely a logging issue?

I also fear this is what happened. Looking at https://www.mediawiki.org/w/index.php?title=Special:Log&page=Growth%2FPersonalized+first+day%2FNewcomer+homepage%2FMeasurement+and+experiment+plan, I see only priority language change entry – probably because the second time you marked the page for translation, there wasn’t anything to remove anymore.

If they were incorrectly cleared, I wonder whether there is a need to identify the affected cases and restore the priority languages that were unintentionally removed.

Translate’s database tables are not versioned (though maybe they should be), so the removed rows are gone; the only way I can think of to restore the data is looking at the preceding priority language change log entry, and approximate based on that. This may fall short when the page has been renamed in the meantime.

Tacsipacsi added subscribers: Minorax, abi_.

I’ve dug into this a bit more. Unfortunately, the analysis of @SarthakSingh2904 wasn’t correct. The real bug is that the submitted value is empty unless the language selector field has been touched. That is,

  • If there are no priority languages, an empty string is submitted, as expected.
  • If the translation admin changes the list after the form was loaded, they are saved as expected (see example log: I could easily add back the priority languages that @Minorax accidentally removed). This change can be anything: addition, removal, even adding and subsequently removing a language (which is a usable workaround until the bug is fixed, by the way).
  • The bug manifests if the page already has priority languages, and the translation admin doesn’t change them. In this case, the <input> doesn’t get populated with the list of existing languages, and so an empty list gets submitted.

As I have already expected, this is a Regression from https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/1211663 / T410267: Build a language selector component into MediaWiki core by @abi_.

Change #1225160 had a related patch set uploaded (by SarthakSingh2904; author: SarthakSingh2904):

[mediawiki/extensions/Translate@master] Translate: Initialize priority languages input on page load

https://gerrit.wikimedia.org/r/1225160

Change #1225083 abandoned by SarthakSingh2904:

[mediawiki/extensions/Translate@master] PageTranslation: Fix incorrect "removed priority languages" log

Reason:

I have created a fresh submission as per the recommendation of the Reviewer

https://gerrit.wikimedia.org/r/1225083

Change #1225160 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Translate: Initialize priority languages input on page load

https://gerrit.wikimedia.org/r/1225160

abi_ triaged this task as High priority.Jan 13 2026, 7:19 AM
abi_ set the point value for this task to 2.
abi_ moved this task from Backlog to page translation on the MediaWiki-extensions-Translate board.
abi_ moved this task from Backlog to Pending Deployment on the LPL Essential (FY2025-26 Q2) board.
abi_ moved this task from Pending Deployment to Done on the LPL Essential (FY2025-26 Q3&4) board.

No longer able to reproduce this issue on MetaWiki. Thanks for reporting and fixing this issue.

However, is it possible that the priority languages were actually being set to empty at that point, rather than this being purely a logging issue?

I also fear this is what happened. Looking at https://www.mediawiki.org/w/index.php?title=Special:Log&page=Growth%2FPersonalized+first+day%2FNewcomer+homepage%2FMeasurement+and+experiment+plan, I see only priority language change entry – probably because the second time you marked the page for translation, there wasn’t anything to remove anymore.

If they were incorrectly cleared, I wonder whether there is a need to identify the affected cases and restore the priority languages that were unintentionally removed.

Translate’s database tables are not versioned (though maybe they should be), so the removed rows are gone; the only way I can think of to restore the data is looking at the preceding priority language change log entry, and approximate based on that. This may fall short when the page has been renamed in the meantime.

I think this should be in the scope of the current task. It’s been broken only for a week (fortunately, the regressing patch didn’t catch the last deployment train of 2025), but a week is more than enough time to do much harm. (When I wrote the above comment, I was thinking it did get deployed in December. With the one-week window, hopefully renaming is not that big of an issue.)

Nikerabbit claimed this task.

I think this should be in the scope of the current task.

I disagree. I'll file a separate task, but I am not sure if we have time to do it.