Translation_counts field of ExplorationOpportunitySummaryModel and translations field of EntityTranslationsModel are not in sync when saving new versions of exploration.

[chris7716]

• When a content is updated/deleted after a translation is accepted, we do not remove that translation from the EntityTranslationModel. But we decrease the translation_count in the ExplorationOpportunitySummary model. This is covered by #20215
• Sometimes when there is a change in the exploration, translation_counts in the ExplorationOpportunitySummary model becomes an empty dict, even though there are translations for the contents of the exploration. The goal of this issue is to avoid this behavior and instead revert back to an earlier version of translations associated with the commit the exploration was reverted to

[StephenYu2018]

@U8NWXD Could you create a debugging doc for this issue and fill it with everything you investigated/attempted so far? This will help the CD team leads be better informed on your progress for this issue, and it will allow others in the team to make suggestions and pose questions to help you when you get stuck.

To create the debugging doc, follow the instructions at https://github.com/oppia/oppia/wiki/Debugging-Docs

[StephenYu2018]

Disregard my previous comment. The "bug" part of this issue is already being fixed by #20320 . @U8NWXD is in the process of implementing a small, new feature that reverts translations when its target exploration gets reverted. This feature is small because the translation versions are already stored.

[U8NWXD]

@chris7716 @StephenYu2018 I have a prototype solution working that's documented in https://gist.github.com/U8NWXD/628433fd22d5def7fe07f61e31c25169#implemented-solution. Here's a summary: When an exploration is reverted from e.g. version 5 to version 2, creating version 6, the translations that were associated with version 2 are copied to version 6 of the exploration. This will include all translations added up until version 3 was created.

This approach keeps the implementation simple and in line with the idea of a revert. One downside is that if a field of the exploration were unchanged from version 2 through version 5 but were only translated after version 3 was created, its translation will be lost in the revert despite remaining valid. I think that this downside is acceptable so long as we expect translations to generally be populated more quickly than explorations are updated, and I think it's more important to match users' expectations that a revert returns all aspects of the exploration to the previous state, including translations.

Does this sound good to you? If so, I'll open a PR implementing this change

[StephenYu2018]

@U8NWXD In the second paragraph, what do you mean by "a field of the exploration"?

For the mentioned downside, I'm not seeing how the translations after version 3 would be lost in the revert. Wouldn't they still remain connected from version 3-5 after version 6 is created? Does "lost" mean that the translation submitters and reviewers can no longer access it on the CD?

If so, then I think that this downside is easier to work around than downsides of the alternative approach (the approach where the revert version has the translations of the most recent version). With the alternative approach, the main downside is that the translation team would be working with prior translations that don't reflect the most up-to-date exploration content. If there was a way to notify the relevant translation team members, this wouldn't be much of an issue.

I think I'm more concerned about how we intend to inform and direct the translation team members involved in the reverted translations, so that they know which translations to prioritize. If we don't currently have any way of notifying the translation team members involved in the reverted translations, then I think it will be crucial to add UI elements and code to achieve this.

@seanlip What do you think? (Sorry, I'm not really familiar with how reverting exploration coordinates with translations and their opportunities)

[U8NWXD]

what do you mean by "a field of the exploration"?

I mean any translatable text in the exploration. For example, the text on a card or the text "Continue" on the continue button.

I'm not seeing how the translations after version 3 would be lost in the revert. Wouldn't they still remain connected from version 3-5 after version 6 is created? Does "lost" mean that the translation submitters and reviewers can no longer access it on the CD?

Correct, the translations from version 3 would still be present in the datastore. They just wouldn't be visible on the contributor dashboard, nor would they be visible to learners, because they would be associated with an old version (version 3) of the exploration (which is now on version 6). The corresponding translatable texts of the exploration would be treated as un-translated, so translation opportunities would be shown for them.

[StephenYu2018]

Ah okay. I think reverting the translations when reverting the exploration version would be the way to go, but I think having some sort of system for translators to be notified when reverting of the relevant exploration's version occurs would help greatly.

The main concern I think translators would have is if the reversion occurs, the relevant translations show their older version or they disappear from the CD. I think the team members should have some sort of way to observe what changed between the version before the revert and the version after the revert. Additionally, I think it would help even more to give the team some sort of way to choose whether to keep the translation before the revert as the current translation or to drop said translation entirely.

[U8NWXD]

I think the team members should have some sort of way to observe what changed between the version before the revert and the version after the revert. Additionally, I think it would help even more to give the team some sort of way to choose whether to keep the translation before the revert as the current translation or to drop said translation entirely.

Could you elaborate on a scenario where this would be important functionality? For example, maybe the exploration was fully translated in version 2, but one of those translations had a typo that was fixed in version 4. Then when we revert back to version 2, we want translators to be notified so that they can re-fix the typo. Is that the kind of issue you're worried about?

Also, who do you think needs to be notified? Some ideas:

• Anyone who has submitted translations for the exploration that was reverted?
  • The translation submitters could be anyone and might not have any kind of leadership/organizing role, so they seem like the wrong people to notify.
• Just the translation reviewers?
  • Since we don't assign reviewers to particular explorations/topics, this will lead to every translation reviewer being notified for every exploration revert, which could get pretty noisy.
• Just the reviewers who have approved translations for the reverted exploration?
  • This would cut down on the noise, but feels ad-hoc. What if the reviewers are no longer active?

Ideally, I think it'd be best if we notified people who were assigned to oversee translations of the reverted exploration, but do such people even exist? I'm unfamiliar with how the translation teams are structured.

[U8NWXD]

I chatted with @seanlip, and his opinion was that we implement the simple behavior for now because reverts are pretty unusual, and it's more faithful to the conventional idea of a "revert"

[seanlip]

Sorry for the late reply. Confirming that I think we don't need to worry about notifications on reverts here yet, and it looks like this coincides with a similar reply I left in https://github.com/oppia/oppia/issues/20678.