Page MenuHomePhabricator

Translate error - "This namespace is reserved for content page translations"
Open, HighPublic

Description

[UPDATE] This is an erratic bug. If you encounter it, there are a few potential workarounds:

  • just wait a few minutes before trying, and it should un-stick itself as the jobqueue catches up
  • or re-mark the page for translation: Make a dummy edit (i.e. add or remove an empty line) on the source page. Mark for translation. Wait a few seconds. Now resuming translations should work.
  • or play with Special:AggregateGroups,
  • or ask a person with server access to run the Translate/scripts/createMessageIndex.php script.

[Original task description. Initial example has fixed itself.]
When I try to add a translation, or change an existing translation, I get the error Saving the translation failed: This namespace is reserved for content page translations. The page you are trying to edit does not seem to correspond any page marked for translation.
at https://meta.wikimedia.org/w/index.php?title=Special:Translate&group=page-Global+Reach%2FAnnouncements%2FBahasa+Indonesia+Search+Pilot+FAQ&action=page&filter=&language=id

I've tried using "remove from translation" and re-setting it, but that didn't fix it.

There was an earlier user-error where translation-markers were manually added, but I've never seen that issue lead to this problem before.

Event Timeline

Quiddity created this task.Apr 16 2019, 5:32 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 16 2019, 5:32 PM

Nikerabbit says (despite being on sickleave!)

might be an issue with jobqueue or an issue with jobs with details on logstash

abi_ added a subscriber: abi_.Apr 17 2019, 4:34 AM
Elitre added a subscriber: Elitre.Apr 17 2019, 10:16 AM

I'm getting that too while trying to add localised versions of the infographic to the various (still empty) translations of https://meta.wikimedia.org/wiki/Affiliate-selected_Board_seats/2019/Primer_for_user_groups .

Elitre added a subscriber: Arrbee.Apr 17 2019, 1:56 PM

As an update, @Arrbee: I have now managed to do the edit I wanted on the French and Arabic pages. Before attempting I did a dummy edit on the English version. Will keep you posted and LMK if you need to know anything.

abi_ added a comment.Apr 17 2019, 9:37 PM

I've been able to reproduce the problem. Saving translations for any new text that's been added to the page fails to save with the given error. Like @Elitre mentioned, if I edit a translation unit / text on the English page, and then go back and try to translate the message, things work again. I did not face this issue while saving translations for existing translation units ( or text on the page).

Nikerabbit triaged this task as High priority.Apr 18 2019, 7:25 AM

We will continue investigating this and T213802: Investigate ways to reduce the size of translate-groups cache key and T203786: Mcrouter periodically reports soft TKOs for mc1029 (was mc1035, mc1022) leading to MW Memcached exceptions which may be related, but that will take a while due to availability issues. In my opinion this issue is high priority but not UBN!.

Summary

  • This issue is pretty similar to the previous cases where new pages (or new sections of existing pages) marked for translation are not immediately translatable.
  • There has always been a delay because it goes through a jobqueue. Usually this is just a few minutes.
  • Possibly due to recent changes, these job queue jobs seem to be failing occasionally. Maybe they also run slower now, but I don't have evidence for or against.
  • This issue is, at least for now, self-healing, that any later run will make the previously untranslatable sections translatable.

Workarounds

  • For urgent cases, to try to make new content translatable, one can (re-)mark any page for translation, or play with Special:AggregateGroups, or ask a person with server access to run Translate/scripts/createMessageIndex.php script.

Impact
New content is not immediately translatable. Delays are longer than usual and an increase of failures is seen in Logstash.

In my opinion this issue is high priority but not UBN!.

Agreed. Sorry I didn't followup on my IRC comment, where I suggested it might be! I wasn't sure how permanent this bug might be.

Talking of which, I should've mentioned that my original example in the task description has fixed-itself as of this morning, so yes, this is a temporary heisenbug (IIUC, or thereabouts) for now!

Workarounds

  • For urgent cases, to try to make new content translatable, one can (re-)mark any page for translation, or play with Special:AggregateGroups, or ask a person with server access to run Translate/scripts/createMessageIndex.php script.

Ah, cool, thanks for those tips :)

We will continue investigating this and T213802: Investigate ways to reduce the size of translate-groups cache key and T203786: Mcrouter periodically reports soft TKOs for mc1029 (was mc1035, mc1022) leading to MW Memcached exceptions which may be related, but that will take a while due to availability issues. In my opinion this issue is high priority but not UBN!.
Summary

  • This issue is pretty similar to the previous cases where new pages (or new sections of existing pages) marked for translation are not immediately translatable.
  • There has always been a delay because it goes through a jobqueue. Usually this is just a few minutes.
  • Possibly due to recent changes, these job queue jobs seem to be failing occasionally. Maybe they also run slower now, but I don't have evidence for or against.
  • This issue is, at least for now, self-healing, that any later run will make the previously untranslatable sections translatable.

Workarounds

  • For urgent cases, to try to make new content translatable, one can (re-)mark any page for translation, or play with Special:AggregateGroups, or ask a person with server access to run Translate/scripts/createMessageIndex.php script.

Impact
New content is not immediately translatable. Delays are longer than usual and an increase of failures is seen in Logstash.

ASBS translations are going to be quite urgent for the next couple of weeks. I myself may not be around all the time to check that people aren't having issues there or to help them figure out the workaround.

I understand if this can't be solved immediately, and I appreciate details (like step-by-step) around the various workarounds so that at least everyone will know what can be done until then.

Nemo_bis renamed this task from Translate error - unable to save translations on metawiki in one page to Translate error - unable to save translations on metawiki in one page just marked for translation.Apr 18 2019, 10:29 AM

This is the easy workaround I'm aware of:
Make a dummy edit (i.e., add or remove an empty line) on the source page. Mark for translation. Now resuming translations should work.

Please document others with steps if you know what they look like. TY!

Quiddity updated the task description. (Show Details)Apr 19 2019, 5:21 PM
Eihel added a subscriber: Eihel.Apr 23 2019, 6:11 PM

Hello, I submit my comments that I found on Meta [[ URL | https://meta.wikimedia.org/w/index.php?title=Meta:Requests_for_translation_adminship/Eihel&type=revision&diff=19037860&oldid=19036317&diffmode=source]]:

Hello, my observations @Aldnonymous:
First, the page I was dealing with, is not done the right way with the <translate> tags (multiplication of translation). The translation could be done even with a different text version. But Wladek92 has changed the layout (with good reason), but without adding the markers of translation. The original text is visible, but is no longer available for translation, hence the message "The page you are trying to edit does not seem to correspond any page marked for translation". In addition, any translations made previously is no longer visible (as the marker is removed, the page page/language is lost) , that's what baffled me. I think the problem was to mark the version for translation with new markers <!--T:1--> (declare on Meta talk:Babylon or talk to Elitre (WMF)), which was not. Apparently, the bug only appeared later after this change. "there's possible work around afaik": yes, but only for pages with all markers and that's where I could be useful. I am not a aficionado of Phab, so if you want to go up the info, no problem. Greetings friendly. --Eihel (talk) 11:11, 23 April 2019 (UTC)

Follows T221119#5119115 T213802 T221119#5121833 (given by Aldnonymous)

Teles added a subscriber: Teles.Apr 25 2019, 12:37 AM
abi_ added a comment.Apr 27 2019, 12:33 PM

Hello, I submit my comments that I found on Meta [[ URL | https://meta.wikimedia.org/w/index.php?title=Meta:Requests_for_translation_adminship/Eihel&type=revision&diff=19037860&oldid=19036317&diffmode=source]]:

Hello, my observations @Aldnonymous:
First, the page I was dealing with, is not done the right way with the <translate> tags (multiplication of translation). The translation could be done even with a different text version. But Wladek92 has changed the layout (with good reason), but without adding the markers of translation. The original text is visible, but is no longer available for translation, hence the message "The page you are trying to edit does not seem to correspond any page marked for translation". In addition, any translations made previously is no longer visible (as the marker is removed, the page page/language is lost) , that's what baffled me. I think the problem was to mark the version for translation with new markers <!--T:1--> (declare on Meta talk:Babylon or talk to Elitre (WMF)), which was not. Apparently, the bug only appeared later after this change. "there's possible work around afaik": yes, but only for pages with all markers and that's where I could be useful. I am not a aficionado of Phab, so if you want to go up the info, no problem. Greetings friendly. --Eihel (talk) 11:11, 23 April 2019 (UTC)

Follows T221119#5119115 T213802 T221119#5121833 (given by Aldnonymous)

Hi @Eihel

Thanks for reporting the problem that you are having. This problem does not seem like its related to this issue. You should be able to use the Special:PageMigration to retrieve the old translations. You can read more about how to use this tool here.

Please let me know if that helps and if you require further help.

Same here. I did this: https://meta.wikimedia.org/w/index.php?title=Global_sysops&diff=19079406&oldid=19001329

And tried to translate it to Dutch, but without luck. I thought I did something wrong, but I was told it is a bug... Please fix it, if you can.

Zppix added a subscriber: Zppix.May 6 2019, 1:31 PM

Is there a fix foreseen in the future?

Nikerabbit added a comment.EditedMay 6 2019, 3:42 PM

It's unclear what is the cause here. The symptoms are very clear (The page you are trying to edit does not seem to correspond any page marked for translation.), but there are many things that can break and cause this symptom. It is not easy to debug what is actually going on there, and the fact that the job queue is involved makes it a bit harder still to debug.

Further debugging is needed before a fix can even be attempted.

@Trijnstel @Zppix @Wladek92 +1 and similar comments don't help. As long as this task is opened, the bug is very likely to persist. We know about this issue and I believe the team behind MediaWiki-extensions-Translate are already working on this issue. This bug has workarounds available, see the task description. If the workarounds are unclear to you, feel free to ask!

I just encountered the same on Commons when trying to save translations to https://commons.wikimedia.org/wiki/Commons:Wikimedia_Sverige

Quiddity renamed this task from Translate error - unable to save translations on metawiki in one page just marked for translation to Translate error - "This namespace is reserved for content page translations".Jun 17 2019, 7:42 PM
Wargo added a subscriber: Wargo.Jun 18 2019, 7:06 PM
Wladek92 added a comment.EditedJul 5 2019, 7:12 PM

same again today Jul 5,2019 in Mediawiki on:

Translations:MediaWiki 1.33/Page display title/fr
MediaWiki 1.33
Échec de l’enregistrement de la traduction : This namespace is reserved for content page translations. The page you are trying to edit does not seem to correspond any page marked for translation.

@Wladek92 That's to be expected. This task was not closed yet.

It's unclear what is the cause here. The symptoms are very clear (The page you are trying to edit does not seem to correspond any page marked for translation.), but there are many things that can break and cause this symptom. It is not easy to debug what is actually going on there, and the fact that the job queue is involved makes it a bit harder still to debug.
Further debugging is needed before a fix can even be attempted.

@Nikerabbit is there specific info you could need from one of us, ...?

No I don't think so. My suggested plan of attack for this issue is:

  • Increase visibility in the job queue: Ensure that we can see if these jobs are failing, how often they are enqueue, how long until they are being processed, how long it takes to process them. If there are failures, ensure that clear and actionable error details are logged and act upon them.
  • Try harder to avoid exposing this error to users: In parallel to above, since we know that job queue is processed asynchronously, make more reliable check whether a page is marked for translation. It needs to use a mechanism that doesn't depend on the jobqueue. Either direct database queries or another mechanism that can be used until the job is run.
abi_ claimed this task.Jul 16 2019, 3:07 AM

Still occured today on mediawiki. Then I made a dummy modification in a EN message of the page (delete one 'a' and reinsert the 'a') before resending 'for translation' . It worked. And I noticed the log only register one action 'sent for translation'.

Eihel added a comment.Jul 28 2019, 9:34 PM

Hello,
Yes @Wladek92, it works. It seems to me that Nikerabbit mentioned this: "For urgent cases, to try to make new content translatable, one can (re-) mark any page for translation...". Au plaisir.

Justly, @Nikerabbit, if it's a queue problem, how to explain that in re-mark a page, it re-works immediately? Because the new marking puts the translations back in the queue. Is it possible that bufferization is the cause of the problem? (a telescoping (crash) of information, a concatenated surplus of information, the occurrence of other information denatures the first request, etc.).

The right to mark in translation has brought more demand by increasing the number of translation administrators, QED. I noticed other things. Do you want me to tell you about these experiences or does it not seem useful to you? (This is when and how I see this problem)

Change 526589 had a related patch set uploaded (by Abijeet Patro; owner: Abijeet Patro):
[mediawiki/extensions/Translate@master] WIP: Add a generic job class with helpers to log data

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

Estimation: about 50 % of the translation requests I do must be requested again.

The problem seems to reach also other wikis : similar behaviour (cannot save the translations) has been observed on KDE/userbase (see https://userbase.kde.org/Thread:User_talk:Yurchor/help:_cannot_save_the_FR_translations)

abi_ added a comment.EditedAug 11 2019, 3:49 PM

Thanks @Wladek92 and @Eihel for your inputs.

I've started working on this issue based on Niklas' previous comment and my discussions with him, and here's an update,

Adding checks during translation saving

When a page is marked for translations,

  1. The sections are inserted into the translate_sections table. This happens in SpecialPageTranslation::markForTranslation function itself.
  2. In TranslationUpdateJob, each section is created / updated as a page in the wiki by the MessageUpdateJob
  3. In TranslationUpdateJob, the MessageIndex is updated.
  4. Although not relevant in this context, In TranslationUpdateJob, TranslateRenderJobs are also added to update the translation pages.

Problems

Imagine a page - T221119, with 2 translation units currently. An editor adds a third translation unit ie T221119/3. The existing translation units will be T221119/1 and T221119/2.

MessageHandle::isValid() is called when saving a translation to check if an invalid message that does not belong to a translatable page is being saved..

It checks if the MessageIndex has that key (T221119/3), which will not be present if MessageIndex::singleton()->rebuild(); is not called on the TranslationUpdateJob when the new section is added.

Solution

Updating the MessageIndex should fix this issue but since that is a fairly large intensive process it will have to be done with care. It might be possible to add a method that rebuilds a specific MessageGroup into the cache.

I'll discuss with Niklas and see if some changes can be made.

Adding further logs to increase visibility with failures

I've update the code and submitted a patch to add further logs. Currently waiting for that patch to be merged, and to get access to LogStash.

abi_ added a comment.Aug 11 2019, 6:03 PM

(Updated my previous comment with latest findings)

abi_ added a comment.Aug 17 2019, 3:22 PM

I've now received LogStash access, and reviewing the logs from there for this particular job (TranslationsUpdateJob) reveals that we've been having issues with rebuilding the MessageIndex. The following exception message is present 381 times in the last 30 days - MessageIndex: unable to acquire lock.

Building the page markup, I observe from a practical point of view that it fails each time. But if you have modified tanslation units already existing at step n-1, the translated text you will enter will be accepted. Failure appears with new created translations unit in the EN text.
When you redo what people call a dummy update of the EN text, or if you go further creating new units, you will then validate the pending new previous one (of step n-1) and push the problem one step forward.

I observe also that if you wait long enough (coming back tomorrow) you do not see the problem.

Change 534571 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/Translate@master] Defer message group stats update in message index rebuild

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

Change 526589 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Add logs to the jobs involved with marking a page for translation

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

Change 534571 merged by jenkins-bot:
[mediawiki/extensions/Translate@master] Defer message group stats update in message index rebuild

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

Change 537363 had a related patch set uploaded (by Abijeet Patro; owner: Abijeet Patro):
[operations/mediawiki-config@master] Add channels for the Translate and TranslationsNotification extension

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

Change 537363 merged by jenkins-bot:
[operations/mediawiki-config@master] Add channels for the Translate and TranslationsNotification extension

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

Mentioned in SAL (#wikimedia-operations) [2019-09-17T11:31:17Z] <urbanecm@deploy1001> Synchronized wmf-config/VariantSettings.php: SWAT: 290e207: Add channels for the Translate and TranslationsNotification extension (T221119, T144780, T143073) (duration: 00m 56s)