Thank you for the observation Pau. The issue you mentioned comes from a bug in cxserver that throws an unexpected 500 error for the "fetch section suggestion" request (https://cxserver.wikimedia.org/v2/suggest/sections/Maya%20Rudolph/en/el). This issue has already been resolved, but not yet deployed. If cxserver worked properly and returns at least one missing section the "+ My missing section" button would be displayed in the published translation card and the user would be redirected to the "Pick a section" step on click. The "+ New translation" button should only be displayed when no missing section exists for that article and language pair (see such an example request in screenshot 1). For these cases, the user should be redirected to the Confirmation step, which should look like Screenshot 2. In any case, I think this is out of the scope of this task, and we can create a new task, if we observe an undesired behaviour inside Confirmation step.

The fix for this issue has now long been deployed and the issue is gone. This issue occurred in cases when the frequent language ULS entrypoint was not rendered the first time the code executes, i.e. when no relevant language was missing.

The fix for this task has now been deployed in production. The task can be closed as done.

It turns out that this issue is caused because the image elements (<img>) inside galleries are expected to have the .mw-file-element class, inside the toDataElement of ve.dm.MWGalleryImageNode class. This class is part of VisualEditor extension. This expectation exists because since MW Dom Spec 2.7.1 these image elements should have this class (T314097).

@Pginer-WMF Given the above QA I believe we can close this ticket as done. Although the scenario A2 has not been yet supported I believe that this should be captured in a separate task and be prioritize accordingly, as it's not a trivial functionality to support (we will need to deploy a new backend API endpoint). The rest scenarios have been verified to work as expected in production.

The scenario D can now be verified. Here are two screencasts from greek (el) wiki. In the first one we create a draft translation on mobile. In the second we continue that draft translation and publish it on desktop.

This task doesn't include any UI change and cannot be verified with screencasts, etc. However, the fix has been deployed for about a month now, and things continue to work as expected. This task can be closed as done.

This task can be considered as done. Users are now properly redirected from the unified dashboard to the desktop editor when needed. The scenarios that were tested here were "New article translation" by selecting a page suggestion from the dashboard, and "New section translation" by selecting a section suggestion from the dashboard.

The latest pending issue (the list switcher to be placed in a sidebar as a set of selectable pills) is now deployed on production. This task can be considered as done.

The "force-quick-tutorial" URL param can now be used to forcefully display the quick tutorial when desired:

This issue is related to some image gallery node that exists inside the source article. Apparently, there are some issues with image galleries. This isn't in the Content Translation side, so we'll have to investigate if the issue lies in the cxserver or the visual editor.

Thank you for all the information you provided @MMH-fabr! I invested a lot of effort but still I wasn't able to detect the root cause of the issue. For now we'll improve our error logging system, so that we can better catch such errors and we'll appreciate any new information about it in the future. I would suggest that you wait for the machine translation for a section to be loaded before trying to translate the next one, I have found that this mitigates the issue. One last question: have you noticed that the issue is happening for all translations or it only happens when translating some articles that meet specific criteria?

Hello @MMH-fabr! Sorry for closing this ticket without all concerns being addressed. Unfortunately, we would need more information to try to reproduce this issue, as it's now a known issue. I'd like to inform you that sharing the translation URL is not helpful as the contents of the page are personalized based on the logged-in user, and thus we cannot see what you see.

@Pginer-WMF following the above confirmations I believe that we can close this issue as resolved. Moving this to "Done" column.

Scenarios 3 and 4 have not been changed, and continue to work with the previous implementation. This is because we are soon moving to the unified dashboard, and it didn't make sense to spend time on refactoring code that will soon be obsolete. Based on above QA, this task can be considered as done.

QA Scenario 5-6:

QA Scenario 2:

QA Scenario 1:

Session expiration is now handled properly both when switching tabs or windows. The login dialog is also not dismissable any more. This task can be considered done.

Currently, restoring a draft translation on desktop, only needs a single request to fetch the draft translation information and the translation corpora units, as demonstrated in the following screencast (captured from el production wiki):

Following the deployment of a fix for T349311, which was the root cause of this task, we can consider this task as done.

Following the deployment of a fix for T349311, which was the root cause of this task, we can consider this task as done. T349893 can also be resolved, as it's a duplicate of this task.

Here is an example of the error being thrown in production:

In T348797#9282251, @Tuga1143 wrote:

At pt.wiki we have the same problem, translating from any language to our portuguese language. As of now, the problem continues.

In T348797#9279818, @Ranveig wrote:

I have encountered the same problem when translating sv:Mavia to nnwiki and en:Dick Gaughan to nnwiki. When I try to load the saved versions of these translations, I get the error message "Unable to fetch draft information." The first was last saved 7 days ago, the second was saved 5 days ago. Later translations (working from nowiki) have not had this issue. However, it's continually being reported from various users trying to translate articles.

This issue occurs for translations with target categories because of this bug (T349311). A fix for this issue has already been merged and will be deployed with the next train. That means that the restoration of such translations will be available on production wikis within this week.

I expect this issue to be resolved after deploying the new CX build. I'll keep an eye on it.

Based on the logstash link that Niklas provided above, the issue doesn't occur anymore. @Pginer-WMF I believe that we can close this task as done.