Page MenuHomePhabricator

Language variant handling - migration of stored languages
Closed, ResolvedPublic

Description

Once a user updates to 6.8.0 from previous versions, we want to be sure any past persisted objects in the app are properly migrated over to a language variant for 6.8.0. The language variant is chosen automatically by the app. It prioritizes based on the user's preferred languages in device settings, and defaults to a variant if the user hasn't specified a preference in device settings. For example:

  1. In 6.7.4 user has "Chinese Wikipedia" chosen as a preferred app language in app settings.
  2. Device has "Chinese Traditional" chosen as a preferred device language in their OS settings.
  3. User upgrades to 6.8.
  4. App should automatically have "Chinese Traditional" chosen as a language variant.

And

  1. In 6.7.4 user has "Chinese Wikipedia" chosen as a preferred app language in app settings.
  2. Device does not specify any Chinese language in their OS settings.
  3. User upgrades to 6.8.
  4. App should automatically have "Chinese Simplified" chosen as a language variant (this is the default).

Migration areas include:

Preferred Wikipedia languages chosen in app language settings
Preferred language settings chosen in app explore feed settings
Search language highlight on search screen

Just a general regression here around stored objects would be good (history, past search terms, etc), we should make sure they still show up after upgrading.

Note that because server-side doesn't distinguish between saved articles of a different variant, there's an app-side restriction to only allow users to save one variant per Wiki language.

So this is expected:

  1. User saves an article in Chinese Simplified.
  2. User visits same article in Chinese Traditional.
  3. Selection state of Chinese Traditional is selected already, because they already saved it under Chinese Simplified.

Event Timeline

JMinor triaged this task as Medium priority.Feb 2 2021, 8:30 PM

HI all! I'm thinking that it'd be cleanest to go with the second option of forcing a selection via the migration modal. I'm guessing that this will mean that we'll need copy for all of our supported languages that is similar to the notification sent to Chinese language readers?

Dmantena subscribed.

Minor correction that I updated in table above and forthcoming string update PR - Gan Body text originally ended with "Traditional(gan-hant)" but I believe the intent was probably to have a space in there "Traditional (gan-hant)".

Un-assigning myself from this one now as the PR for the string updates is about to go up and not sure if this ticket is meant to encapsulate different related work on it.

Every language with variants has a default variant that is used if no other variant can be guessed for the user. This has already been in place for Chinese and Serbian in the shipping app for some time.

This ticket is a bit repurposed to represent all of the non-UI language variant migration tasks. This includes handling the default variant when needed, but also migrating preferences, settings, and existing database items.

The ticket https://phabricator.wikimedia.org/T270210 will represent displaying the language-specific alerts for Chinese and the languages listed above in this ticket.

Tsevener renamed this task from Language variant handling for users with stored articles with no variant to Language variant handling - migration of stored languages.Mar 23 2021, 9:01 PM
Tsevener updated the task description. (Show Details)

Note: updated this ticket to represent app data migration. Previous description has been copied into https://phabricator.wikimedia.org/T270210, which represents the variant modal presentations.

JMinor claimed this task.