Page MenuHomePhabricator

CX2: Register the version used to start a translation
Closed, ResolvedPublic


To keep backwards compatibility of translations we need to make sure that translations started with one version of the editor are always edited with the same version (T187985).

This ticket proposes to register the version used to start a translation. This requires to add metadata for each translation capturing such information. Currently there is no way to decide a translation was done in CX1 editor CX2. CX database does not save this information in database. Guessing based on the start of translation start date does not look like a reliable approach.


  1. Add a new column to cx_translations table to store cx_version information. The values are number indicating the version.
  2. When a new translation is started put the entry as 2 and load CX2 translation editor.
  3. Not having a value in this column for a translation record or value as 1 means it was done in CX1 translation editor.

Event Timeline

Change 418935 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/ContentTranslation@master] Add cx_version to cx_translations table.

Change 418937 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/ContentTranslation@master] Send cx version when saving a draft

TODO: First patch needs DBA to check, need to check for the proper process. Third patch needs fixing.

Note to reviewers and testers: do check that things degrade gracefully when schema change is not applied.

jcrespo added a subscriber: Marostegui.

Please don't just add individual people to reviews- workflow is well documented at (mediawiki policy) and detailed at this is for your convenience, not intended to create unneeded bureaucracy, but to avoid unnecessary delays (eg. my work mates may not see calls for help if you only add me and I could be on vacation :-P).

Please add the DBA tag first if you need help from DBAs- it will then be scheduled for the next available person to work on it (it can be me, but it can be someone else, depending on the availability).

Another tip to speed up reviews is to add Manuel and me to the reviews as "reviewers".

I see the values can only be 1 or 2, so that invalidates most of my comments. We will be waiting for merge and you can add Schema-change-in-production after that happens here or on a separate ticket, as you prefer.

Thanks for the tips. I was reading but not the other page and did not see that DBA should be used.

As for

  • Update installer
  • Not applicable to CX, tables are created manually
  • Make schema change optional
  • The new field has a default value
  • The follow-up code has a fallback for missing fields and doesn't write if the field doesn't exist
  • Search for input
  • Done based on your comments. Thanks.
  • Test on beta
  • Q: Should we deploy this schema change on beta ourselves or is that dependent on you? I did not see this mentioned in the docs.

Yes, beta is fully "yours", you just merge and it gets deployed automatically, I think- I am not much involved on it. You test it, then you come back to us for the production deployment (you can reuse the ticket if you edit the description or you can file a separate one). To mark this is ready, you add the Schema-change-in-production (which means: "hey, dbas, we can do no more without the change, please deploy ASAP").

Sorry to be so strict, but we get many request over each week, the easier you put it to us, the faster you will get things done. Thank you for the understanding.

In addition to what Jaime said, once you add the Schema-change-in-production if you want to reuse the ticket, that is totally fine but edit the original task description to add the fields commented described on:

The ALTER TABLEs to run (usually, a link to a commit diff is the best way)
Where to run those changes (specific dblist file or the complete list of wikis, in text, to apply the change to). "All wikis" or "everywhere" are not specific enough and has been the cause of outages in the past.
When to run those changes (if it depends on a particular code deployment or can be done at any time)
If the schema change is backwards compatible (is compatible with the current code deployed and can be performed at any time now)
If the schema change has been tested already on some of the test/beta wikis. Usually, as a last test, change should be applied to testwiki first.
If it involves new columns or tables, if the data should be made available on the labs replicas and/or dumps or not because they contain private or sensitive data (consult legal if you are unsure). Similar question if it involves deletion of data previously available on labs.

As Jaime said we get many requests every week and in order to avoid mistakes we prefer to use the same "format" for a schema change, as it is clearer for us and hence, faster to get it deployed as we avoid the back and forth, so it is a win-win :-)


Change 418935 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Add cx_version to cx_translations table.

Change 418936 had a related patch set uploaded (by Santhosh; owner: Nikerabbit):
[mediawiki/extensions/ContentTranslation@master] Use the stored cx_version in the dashboard

  • Test on beta
  • Q: Should we deploy this schema change on beta ourselves or is that dependent on you? I did not see this mentioned in the docs.

I updated schema in Beta (See: T190009) and Labs instances (cx-testing and cx2-testing).

Change 418936 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Use the stored cx_version in the dashboard

Change 418937 merged by Petar.petkovic:
[mediawiki/extensions/ContentTranslation@master] Send cx version when saving a draft

Etonkovidova added a subscriber: Etonkovidova.

Checked in betalabs:

  • the db schema is updated -cx_translations has translation_cx_version populated (with version=1)
  • added to my list of fixes to check after deployment on testwiki