The auto-save mechanism is supposed to work transparently (just saving the content without disturbing the user) reliably (not losing data and preventing the user to leave if the saving is in progress to avoid data loss). We may need to investigate under which circumstances that is not happening and adjust the system accordingly since losing their work is guaranteed to make users unhappy.
|mediawiki/extensions/ContentTranslation||master||+82 -9||Log the save and restore failures to eventlogging system|
- Mentioned In
- T116908: Investigate CX saving/recovery failures
T108795: ContentTranslation: machine translation inserts source text instead of machine translation
- Mentioned Here
- T124399: Migrate the draft translation restore mechanism to use data from cx_corpora table
T106424: Changes in the source article may cause de-facto data loss in an unpublished translation
So, I went to the user created the Bluegrass music translation at wikimania. and he showed me the draft loading correctly!. To make sure, I myself refreshed his Special:CX multiple times and all the time draft loaded, not data was lost. Suspecting spurious network glitch that aborted the draft loading api hit in the specific case?
In this comment there are details of a partial loss of data, and information being recovered in the wrong place. This seems to suggest some issues in the way content is recovered (probably because of heavy changes in the source article).
This could be potentially avoided if we could load the same version the user started translating (either by default or as fallback when the updated version is not compatible).
From mid-sprint refinement meeting today:
RB: Do we need more tickets about restoration problems?
ST: Last week I saw one report on the talk page - did not investigate - needs investigation
ST: Best thing is to create tickets for such things on the talk page and add to current sprint
PG: I recently created a ticket which I was not sure had technical issues.
ST: Yeah the one about using older version if alignment fails. We had an issue because we did not save the original source revision, but that has been fixed now.
PG: But does that sound like a good approach we want to take?
ST: There is the tangential issue of stable section ids. There was long discussion when sections should change ids.
ST: We can avoid the requirement of stable ids by using the cxserver id system.
ST: But we also started storing the source sections now – that is the connection.
PG: But we are only storing the sections that user is translating.
ST: We need to get all these things sorted.
ST: If we make the saving and restoring granular, then the scope of losing whole translation is going away.
ST: There is tech debt when we designed and implement parallel corpora. We still save the whole translation in addition to the sections. We want to get rid of saving the whole translation.
ST going over T124399: Migrate the draft translation restore mechanism to use data from cx_corpora table
ST: We can start this (task above) immediately after AbuseFilter work
NL: Should be extra careful to not lose any data