Page MenuHomePhabricator

CX2: Make version 2 the only available
Closed, ResolvedPublic

Description

As part of the gradual deployment process for the new version of Content translation, we want the new version to become the only available:

  • Users of Content translation will always get version 2 when they start a new translation.
  • Options for users to enable/disable the new version will be removed from the UI. Including the "try the new version" link (T194387), the more prominent invite (T204817), and the possibility to select version 1 from the URL.
  • Translations already started with version 1 will still use version 1 editor if users continue editing them.

In this way, all new translations will be started with version 2, keeping version 1 only for backwards-compatibility (until T189091 removes all version 1 drafts, and version 1 can be completely removed).

This change will affect only a small portion of users, since more than 80% of the translations are created with the new version compared to the total published. Unlike T211325 (which message most of the already users already saw), no additional notification will be shown to the users. The tool will just get a set of improvements as it regularly does.

Event Timeline

Pginer-WMF raised the priority of this task from Medium to High.Mar 18 2019, 11:55 AM

Change 497677 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Remove version switcher

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

Change 497677 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Remove version switcher

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

@Petar.petkovic is there anything else pending in this front? I tried with an account that was using CX1 and was correctly migrated to CX2.

@Petar.petkovic is there anything else pending in this front? I tried with an account that was using CX1 and was correctly migrated to CX2.

The merged patch removed the possibility to switch versions (and thus use CX1) from the UI, but you can still do it by manipulating the URL. When user starts new translation and changes version=2 param to version=1 in the URL, CX1 will load. That should not happen and should be prevented, but not sure if we should display some friendly message when users try that.

@Petar.petkovic is there anything else pending in this front? I tried with an account that was using CX1 and was correctly migrated to CX2.

The merged patch removed the possibility to switch versions (and thus use CX1) from the UI, but you can still do it by manipulating the URL. When user starts new translation and changes version=2 param to version=1 in the URL, CX1 will load. That should not happen and should be prevented, but not sure if we should display some friendly message when users try that.

Ok. Thanks for the update. I think a message is not needed. Version just becomes an irrelevant parameter in the URL. We just need to be sure that old translations can be continued with version 1.

Change 503423 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Remove version param from URL

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

Change 503423 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Remove version param from URL

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

@Petar.petkovic should this be moved to QA?

Yes. I'm moving it to post deployment QA because it's on MediaWiki 1.34.0-wmf.1 train which should be deployed to group 2 wikis today.

To sum up what has been done in this ticket:

  • Options for users to choose between CX1 and CX2 is removed from the UI
  • All new translations can only be started by using CX2
  • Existing translations must continue with the original version used to start the translation process
  • Version parameter is no longer visible in the URL, but still exists in the codebase to support using different edit tags on articles published with CX and not to break event logging schemas and logging.
Etonkovidova added a subscriber: Etonkovidova.

Checked in wmf.3 (was actually checking in wmf.1 too) - all is good, including the following:

Version parameter is no longer visible in the URL, but still exists in the codebase to support using different edit tags on articles published with CX and not to break event logging schemas and logging.

@Petar.petkovic - a question about ContentTranslation and ContentTranslation2 tags. I see articles created in wmf.1, for example, on Apr 25 tagged with both tags - https://en.wikipedia.org/w/index.php?title=User:TimeForLunch/Montreal_Council_on_Foreign_Relations&action=history.
In testwiki (with wmf.3) I translated two articles that were marked with ContentTranslation and ContentTranslation2 tags https://test.wikipedia.org/wiki/Special:RecentChanges?tagfilter=contenttranslation%7Ccontenttranslation-v2&limit=50&days=7&urlversion=2

My understanding was that the combo of tags - ContentTranslation and ContentTranslation2 - should be retained only for old translations. Should ContentTranslation tag be dropped for all new translations?

My understanding was that the combo of tags - ContentTranslation and ContentTranslation2 - should be retained only for old translations. Should ContentTranslation tag be dropped for all new translations?

ContentTranslation identifies all translations regardless of the version of the translation editor version used.

ContentTranslation2 was added to allow showing graphs and metrics about the content created with the new version. This is the one we'll remove at some point (and update the graphs accordingly). But note that it is still possible to publish old translations that were started with v1. so it makes sense to still be able to identify those.

I encountered a case where version 1 is used when starting a new translation. Translating "Plants in space" from English to Spanish opens version 1. It only happens for that language pair.

I used such article for examples many times, so there may be some data stored somewhere that confuses the system. However, the translation was not appearing in the "published" list and it was not recovering previous content.

I suspect that it will be hard for others to reproduce, but let me know if there is any info I can share to identify the cause of this glitch.

May-01-2019 09-42-31.gif (424×640 px, 2 MB)

Change 507543 had a related patch set uploaded (by Petar.petkovic; owner: Petar.petkovic):
[mediawiki/extensions/ContentTranslation@master] Check if translation was deleted before checking the version used to start it

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

I encountered a case where version 1 is used when starting a new translation. Translating "Plants in space" from English to Spanish opens version 1. It only happens for that language pair.

I used such article for examples many times, so there may be some data stored somewhere that confuses the system. However, the translation was not appearing in the "published" list and it was not recovering previous content.

I suspect that it will be hard for others to reproduce, but let me know if there is any info I can share to identify the cause of this glitch.

This is probably rare use case and it's a good thing you caught it. When user starts a draft and deletes it, without previously publishing, that still remembers version used to start the translation. However, like you noticed, there are no sections to be recovered, that is completely new translation and should be started with CX2.

I added a check for translations previously deleted. Thank you so much for catching this!

I checked how many not-deleted translations that were started with v1 I have in production - there some examples that would be good to check after the fix is deployed.

Change 507543 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Check if translation was deleted before checking the version used to start it

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

Checking in testwiki wmf.4 - the translation drafts that were started with version=1 are loaded with version=1. The UI looks broken a little bit:

Screen Shot 2019-05-07 at 3.51.57 PM.png (450×1 px, 151 KB)

What curios though it's that translations were started with version=1 quite recently, in wmf.3 e.g.

research@dbstore1005.eqiad.wmnet [wikishared]> select max(translation_start_timestamp) from cx_translations where translation_cx_version=1 and translation_status !='deleted';
+----------------------------------+
| max(translation_start_timestamp) |
+----------------------------------+
| 20190507170514                   |
+----------------------------------+
1 row in set (0.19 sec)

I do not see how a translation can be started with I'll monitor the translation_start_timestamp after wmf.4 will be deployed to all wikis.

Checking in testwiki wmf.4 - the translation drafts that were started with version=1 are loaded with version=1. The UI looks broken a little bit:

Screen Shot 2019-05-07 at 3.51.57 PM.png (450×1 px, 151 KB)

If you are talking about the header with personal menu being broken, it should be fixed with this patch. Also, enwiki has that long message, so progress bar in CX1 and publish button are not aligned.

What's curios though it's that translations were started with version=1 quite recently, in wmf.3 e.g.

research@dbstore1005.eqiad.wmnet [wikishared]> select max(translation_start_timestamp) from cx_translations where translation_cx_version=1 and translation_status !='deleted';
+----------------------------------+
| max(translation_start_timestamp) |
+----------------------------------+
| 20190507170514                   |
+----------------------------------+
1 row in set (0.19 sec)

I do not see how a translation can be started with I'll monitor the translation_start_timestamp after wmf.4 will be deployed to all wikis.

I don't have access to query production databases, so I looked at the code trying to guess what happened.
@Pginer-WMF found a problem (T212646#5149479) that new translations can still be started with CX1. After investigation, it turned out that translations started with CX1 in the past and then deleted from In progress list on CX dashboard still have DB entry which has translation_cx_version equal to 1. When same article was started, that version value was used and translation was started again, with CX1, instead of CX2.
When that happens, translation_start_timestamp is updated, which means your observation and reason why some translations could still be started with CX1 are the same.

Now that 507543 is merged, the problem should be solved.

I confirmed that the issue described in T212646#5149479 is no longer happening. Starting a new translation, even if published before, is using th new version. So I think we can close this.

I can confirm from database perspective. There are 5 drafts where translation_cx_version = 1 and translation_start_timestamp > '20190507170514'. The last has timestamp of 20190509125912.