Translated paragraphs disappear in the Content Translation Tool
Closed, ResolvedPublic8 Estimated Story PointsBUG REPORT

Description

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

  • I don't have a way to directly replicate the issue, but here's a screenshot to my translation attempt of the English Wikipedia article on "Moroccan Jews", to the German language. The empty paragraph was translated and (presumably) automatically saved yesterday.
    marokkanische juden.png (836×1 px, 239 KB)

What happens?:
I finish translating a paragraph in a Wikipedia article in the Content Translation Tool. Next time I check (somtimes the next day) my translation is gone and I have to redo the work all over again. This has happened 3 times to me already (two times en => ary and one time en => de)

What should have happened instead?:
My translations should remain available unless I delete them.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Highlight the fact that translation is not saved more prominently. Check with Pau.

It can be quite easy to miss the draft save error. I've tried to make it a little more prominent. In addition the error that appears after multiple save attempts are made is only visible if you scroll up the page.

Attempt 1:

image.png (638×2 px, 204 KB)

Attempt 2:

image.png (1×2 px, 248 KB)

Highlight the fact that translation is not saved more prominently. Check with Pau.

It can be quite easy to miss the draft save error. I've tried to make it a little more prominent. In addition the error that appears after multiple save attempts are made is only visible if you scroll up the page.

Attempt 1:

image.png (638×2 px, 204 KB)

Attempt 2:

image.png (1×2 px, 248 KB)

Latest attempt:

image.png (777×2 px, 144 KB)

Changes in patch: 1136762: CX: Make draft save errors more prominent | https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/1136762

Thinking out loud: as an user, it is unclear to me what to do if I see this error. I guess a further improvement would be to log it in Logstash and maybe display some id for user they can include in reports.

Also, shouldn't it say "draft" instead of page?

At this point I think it's important that the user understands that their work is not saved and that leaving would result in them losing it.

Do you have a beforeunload confirmation to prevent them from losing their work?

At this point I think it's important that the user understands that their work is not saved and that leaving would result in them losing it.

Do you have a beforeunload confirmation to prevent them from losing their work?

Yes, that's already happening. Please see my comment here

image.png (1×1 px, 90 KB)

Change #1137748 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] Change CX save error mention to say draft instead of page

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

Change #1138851 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] CX: Improve logging related to translation progress mismatch

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

There is some code that tracks mismatch between saved progress, and the actual restored translation progress. It adds a log to the console: https://github.com/wikimedia/mediawiki-extensions-ContentTranslation/blob/master/modules/mw.cx.TranslationTracker.js#L301 but maybe we want to log this in Logstash to see how often this happens.

Regarding the communication of saving issues, there is a related ticket from a decade ago: T106690: CX2: Communicate that auto-save is retrying automatically after an error
My understanding is that saving is automatically re-tried after some time. If that is the case, it would be good to communicate that too.

For the message, I'd propose the more succinct text from the original ticket: "Unable to save. Retrying in a moment..."

Some considerations about the visual style:

  • It makes sense to show the error in-place where the saving message appears, as proposed. Most of the errors/warnings about saving use a separate message box (F16927187, F12218670, F14822354) but that may not work well in this context because in case of saving finally working the error message may remain visible, creating confusion.
  • I'd prefer the version where the text turns red, but the background remains white as usual. Having the whole header being part of the error may make it look more broad (e.g. affecting the publish button also over the reddish background).
  • If we want to increase prominence, we can precede the message with the error icon from Codex (cdxIconError) also in red. In this way, the prominence is increased without relying just on color (good for accessibility).

Change #1139164 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] CX: Retry saving on failure after every 30 seconds

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

Change #1139165 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] CX: Add icon on save failure to make error more prominent

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

Regarding the communication of saving issues, there is a related ticket from a decade ago: T106690: CX2: Communicate that auto-save is retrying automatically after an error
My understanding is that saving is automatically re-tried after some time. If that is the case, it would be good to communicate that too.

For the message, I'd propose the more succinct text from the original ticket: "Unable to save. Retrying in a moment..."

Done

In T376531#10767545, @Pginer-WMF wrote:> Some considerations about the visual style:
  • It makes sense to show the error in-place where the saving message appears, as proposed. Most of the errors/warnings about saving use a separate message box (F16927187, F12218670, F14822354) but that may not work well in this context because in case of saving finally working the error message may remain visible, creating confusion.
  • I'd prefer the version where the text turns red, but the background remains white as usual. Having the whole header being part of the error may make it look more broad (e.g. affecting the publish button also over the reddish background).

OK, done.

  • If we want to increase prominence, we can precede the message with the error icon from Codex (cdxIconError) also in red. In this way, the prominence is increased without relying just on color (good for accessibility).

OK, done.

In addition, I also made the retry a little more frequent. Retry will now occur at 30 second increment:

1st retry --> 30 seconds
2nd retry --> 60 seconds after 1st retry
3rd retry --> 90 seconds after 2nd retry
...and so on.

Screenshot of redesign:

image.png (1×2 px, 339 KB)

Change #1138851 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] CX: Improve logging related to translation progress mismatch

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

Change #1136762 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] CX: Make draft save errors more prominent

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

Saving the draft is retried up to 5 times automatically on failure. If the saving still fails after 5 attempts the following error message is displayed: An error occurred while saving the draft.. After this the manual saving will be enabled again...and the process repeats.

We might want to give user some information on what to do if a scenario like this occurs. Do we let them save the content locally? Do we nudge them to report the error?

Change #1137748 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] Change CX save error message to say draft instead of page

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

Change #1139164 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] CX: Retry saving on failure after every 30 seconds

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

Change #1139165 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] CX: Add icon on save failure to make error more prominent

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

We discussed this during a daily meeting. Here are the next steps:

  1. Ensure that the tooling works: https://grafana-rw.wikimedia.org/d/000000598/content-translation. No failures are being logged. Does that reflect the current situation? T392979
  2. Improve logging on Logstash: T392982
    • Setup a process to review logs pro-actively rather than having users reporting errors.
    • Decide if we want to allow users to report errors by prefilling fields in Phabricator.
    • See if alerts can be setup
  3. Detect if the user is offline and show them a different error message if that is the case: T392978
  4. Check if it's possible to use VisualEditor to store the user translation locally and use that to restore missing content. See: T57370: [Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing (Task: TBC)

To be continued as part of this task:

Nikerabbit changed the task status from Open to In Progress.May 12 2025, 7:16 AM

Change #1144570 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] Ensure mismatch in restored translation progress is logged

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

To be continued as part of this task:

To log mismatch in restored translation progress, I submitted:

Change #1144570 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] Ensure mismatch in restored translation progress is logged

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

It should help log this message into Logstash.

Change #1144570 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] Ensure mismatch in restored translation progress is logged

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

I'm noticing many instances of [CX] Mismatch in restored translation progress. Saved progress was: xx. Restored translation progress is:yyy` in Logstash. We have set a variance % of 8.

PWaigi-WMF raised the priority of this task from Medium to High.Jun 9 2025, 8:12 AM

Some observations from initial attempt to debug:

For a case I was able to reproduce, I had 34 source sections. I translated two sections. Manually modified these two sections. Saved. Restored. Got the error:

mw.cx.TranslationTracker.js:355 [CX] Mismatch in restored translation progress. Saved progress was: {"any":0.029411764705882353,"mt":1,"human":0}. Restored translation progress is: {"any":0.058823529411764705,"mt":0.8571428571428571,"human":0.1428571428571429}.

Looking at the numbers, we see CX restored more than what it saved. any value is 0.029 while saving, but restored 0.058. So my assumption is that CX saved the second section correctly. However, the progress calculated and then persisted missed that section. Proof: 1/34 = 0.029 and 2/34=0.058

I checked logstash for similar messages and I found many cases where we restored more than saved. Example:

[CX] Mismatch in restored translation progress. Saved progress was: {"any":0.7692307692307693,"mt":0.9244372990353698,"human":0.07556270096463025}. Restored translation progress is: {"any":0.8461538461538461,"mt":1,"human":0}.

All of these cases can be considered non-issue(atleast not serious) for users. However, we surely need to figure out how the wrong progress value was calculated and persisted.
There are ofcourse log example that shows the other pattern - Restored less than saved.

  1. [CX] Mismatch in restored translation progress. Saved progress was: {"any":null,"mt":null,"human":null}. Restored translation progress is: {"any":0.045454545454545456,"mt":1,"human":0}.
  2. [CX] Mismatch in restored translation progress. Saved progress was: {"any":0.8076923076923077,"mt":1,"human":0}. Restored translation progress is: {"any":0.7307692307692307,"mt":1,"human":0}.
  3. [CX] Mismatch in restored translation progress. Saved progress was: {"any":0.08333333333333333,"mt":1,"human":0}. Restored translation progress is: {"any":0.08333333333333333,"mt":0,"human":1}.
  4. [CX] Mismatch in restored translation progress. Saved progress was: {"any":1,"mt":0.13049645390070921,"human":0.8695035460992908}. Restored translation progress is: {"any":0.967741935483871,"mt":0.08206686930091185,"human":0.9179331306990881}.

Another pattern I noticed is there is this error Attempting to set unmodified MT saved without an MT provider along with all the mismatch errors. There are 337 such errors in past 3 days. That is an error thrown when mw.cx.dm.SectionState.prototype.markUnmodifiedMTSaved is called( source ).

It is called from two places. From translation tracker and TranslationController. This error will disrupt translation state recording and surely result in miscalculated translation progress at client side(that eventually get persisted at DB)

So, we need to figure out the reason for Attempting to set unmodified MT saved without an MT provider as first step and need an example to reproduce the issue.

I found one genuine reason why the progress value can be different. Suppose there are 10 source sections and you translate 5. The any value would be 0.5, If you modified all the sections, the mt value would be 0(just assume so) and human value would 1. When you come back a few days later, the source article can have 11 sections. Then any calculated at the time of restoration would be 0.45(5/11) . Have a look at the case #2 in the above comment. It is an example of this scenario.

Nikerabbit lowered the priority of this task from High to Medium.Jul 7 2025, 8:18 AM

When performing section translation the progress in the cx_translations table is always {"any":null,"mt":null,"human":null} and never updated when the section is translated further and saved. That progress information for a section is always saved in the cx_section_translations table.

The error:

`[CX] Mismatch in restored translation progress. Saved progress was: {"any":null,"mt":null,"human":null}. Restored translation progress is: {"any":0.045454545454545456,"mt":1,"human":0}.`

Is a result of that. The comparison is done between the translation progress saved in cx_translations table and the progress that is saved in the cx_section_translations table.

Change #1172198 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] APIQueryCX: Use section translation progress when fetching a section

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

Change #1172198 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] APIQueryCX: Use section translation progress when fetching a section

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

Nikerabbit changed the point value for this task from 4 to 8.Jul 28 2025, 8:22 AM

Above patch fixes on condition, but others still need to be investigated.

I was investigating the error, Attempting to set unmodified MT saved without an MT provider. This error is raised from mw.cx.dm.SectionState.prototype.markUnmodifiedMTSaved. The method is called from two places:

  1. mw.cx.TranslationController.prototype.onSaveComplete
  2. mw.cx.TranslationTracker.prototype.init

And noticed that all the occurrences are from mw.cx.TranslationController.prototype.onSaveComplete which is called by mw.cx.TranslationController.prototype.saveSuccessHandler which is triggered after a successful save operation.

Change #1173417 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] Only align section nodes with type cxSection

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

Change #1173417 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] Only align section nodes with type cxSection

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

Another scenario where I'm noticing this consistently is when trying to save outdated translations. If I make a modification to a draft that is now outdated, the desktop editor shows that the translation is saved (including the progress), but reloading the translation does not load the modified translation.

Change #1176440 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] TranslationTracker: Add more information when mismatch occurs

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

Change #1176440 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] TranslationTracker: Add more information when mismatch occurs

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

Another scenario where I'm noticing this consistently is when trying to save outdated translations. If I make a modification to a draft that is now outdated, the desktop editor shows that the translation is saved (including the progress), but reloading the translation does not load the modified translation.

I'm actually not able to reproduce this issue anymore.

Another case where the mismatch would occur would be if the translation was started on the mobile editor, and then continued on desktop editor:

[CX] Mismatch in restored translation progress. Saved progress was: {"any":null,"mt":null,"human":null}. Restored translation progress is: {"any":0.0975609756097561,"mt":1,"human":0}.

Change #1178003 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] CX Editor: Add info when saving unmodified MT without MT provider

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

I've been unable to reproduce the error: 'Attempting to set unmodified MT saved without an MT provider.

I tried the following:

  1. Started a translation on mobile editor and continued on desktop editor.
  2. Tried with undo and redo of translations on the desktop editor.
  3. Various options of MT: copy content, and start with empty.

I've added more logs to try and identify the problem.

Change #1178003 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] CX Editor: Add info when saving unmodified MT without MT provider

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

Change #1188353 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] shouldUnmodifiedMTBeSavedForSection: Add stricter checks

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

Change #1188353 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/ContentTranslation@master] shouldUnmodifiedMTBeSavedForSection: Add stricter checks

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

I'm still unable to reproduce the steps that cause the error 'Attempting to set unmodified MT saved without an MT provider.` but I figured out a condition where this might happen. The above patch should stop this error from happening (hopefully).

Patch has been deployed. Need to monitor it a little longer to see if it has fixed the issue.

Patch has been deployed. Need to monitor it a little longer to see if it has fixed the issue.

Apologies the patch hasn't been merged yet. Patch in question: 1188353: shouldUnmodifiedMTBeSavedForSection: Add stricter checks | https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/1188353

Change #1188353 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] shouldUnmodifiedMTBeSavedForSection: Add stricter checks

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

No occurrences of the error: Attempting to set unmodified MT saved without an MT provider since the last train rollout

image.png (940×2 px, 88 KB)

abi_ closed this task as Resolved.EditedMon, Oct 6, 5:47 AM
abi_ moved this task from Pending Deployment to Done on the LPL Essential (2025 Jul-Sep) board.

As part of this task, we made the following improvements:

  1. Make errors related to draft saving more prominent so editors do not lose work due to unsaved changes.
  2. Retry saving on failure more frequenlyt.
  3. Investigate and improve progress tracking mismatch in certain cases. There are other cases that need to be handled.
  4. Fixed the warning "Attempting to set unmodified MT saved without an MT provider"

I'll create a separate ticket for 3)