Page MenuHomePhabricator

While restoring the CX draft, it is possible that wrong version will be used
Closed, DeclinedPublic

Description

While developing T194387, I found one obscure way to restore the draft with the wrong version of Content Translation.

  1. Start fresh translation in production. I used srwiki to translate en:Last_Glacial_Maximum to Serbian.
  2. Once the translation is started, Content Translation will start with version=1 in the URL. Change to version=2 to translate using CX2.
  3. Translate one paragraph, save and return to the dashboard.
  4. If you returned using "All translations" button, you will get URL in the format of https://sr.wikipedia.org/wiki/Special:ContentTranslation. Append ?page=$page_name&from=$source_lang&to=$target_lang to the URL and follow the new URL. Content Translation will start with the default version, which is CX1 and the loading will break

In the case of my example ?page=$page_name&from=$source_lang&to=$target_lang is "?page=Last_Glacial_Maximum&from=en&to=sr".

Event Timeline

This is not much different from changing the version parameter in the URL. The frontend doesn't know which version of the UI to load (and it cannot, without major refactorings that load the translation metadata first). If there is no explicit version parameter, it defaults to $wgContentTranslationVersion (I believe, I didn't check, with your patch likely depends on the user preference).

I would decline this. No user is going to do this on purpose (at most using bookmarks, but even that is unlikely because we have the dashboard to access these).

Pginer-WMF closed this task as Declined.Sep 13 2018, 3:55 PM

Even if the transition takes several months, the support for switching versions will be a temporary element. We want it to work well in regular use, but it does not need to be bullet-proof for URL hacking. Based on the original report by @Petar.petkovic, and the details by @Nikerabbit, I'm marking it as declined.