Thanks for doing this @HNordeenWMF,

The following wikis should be excluded from the list since they are independent wikis.

Wu Chinese (Simplified) wuu-hant
Wu Chinese (Traditional) wuu-hans
Hakka Chinese zh-hak

We should prompt the user with the six regional language variants for the user to pick, and contain information such as:

1. The app will continue supporting the zh-hant and zh-hans, but the user can no longer select them in the app's language setting.
2. The dialog should keep showing until the user makes the decision.

Some other related tickets:
T195894: detect keyboard languages and prompt if added multiple ZH variants
T190922: language detection in onboarding page

A side note, the onboarding page should not auto select zh-hans and zh-hant either.

Also (this may be a bit off topic), Pinyin IME is mostly used in Simplified Chinese regions. For Traditional Chinese regions, Zhuyin and Cangjie is more frequently used. If this is distinguishable the functionality could be further improved.

In T360585#9667973, @Diskdance wrote:

A side note, the onboarding page should not auto select zh-hans and zh-hant either.

Also (this may be a bit off topic), Pinyin IME is mostly used in Simplified Chinese regions. For Traditional Chinese regions, Zhuyin and Cangjie is more frequently used. If this is distinguishable the functionality could be further improved.

Thanks for the note, it makes sense to me. I have created a ticket to update the logic, which will be worked on after completing this ticket.
https://phabricator.wikimedia.org/T362810

I've updated the task description to include two possible designs. The first assumes that the selection of a new primary language is mandatory, the second allows for the user to cancel or close out of selection @HNordeenWMF do you have a preference for forced selection or ability to cancel out?

Additionally, I'm not sure if the language here is correct for the title and description, any input would be greatly appreciated. Thank you!

Thanks @cmadeo! Looks great.
My thought is that if we only show the dialog once, we should force the selection. If we show it many times until complete, it could be optional. What do you think the best user experience is here?

hi, @cmadeo @cooltey recommended we force the selection & show it until selection is made (in case users closes app before selecting), I have updated the ticket to reflect that.

Generally looks good, but I think we need to handle all possible cases.

For instance, what would happen when a user who wants to read in zh-cn and zh-tw previously chose zh-hans and zh-hant? In this case, should we make it a multiple selection? What about the case that zh-cn, zh-hans and zh-hant were previously selected? (although this is rare, it can technically happen)

@Diskdance thank you for the review, I believe this dialog is intended to set only the Primary Wikipedia language, of which a reader can only have 1. They would still be able to select additional secondary languages in Settings though.

In T360585#9737615, @HNordeenWMF wrote:

hi, @cmadeo @cooltey recommended we force the selection & show it until selection is made (in case users closes app before selecting), I have updated the ticket to reflect that.

Sounds good, I'll remove the second version.

In T360585#9744381, @cmadeo wrote:

@Diskdance thank you for the review, I believe this dialog is intended to set only the Primary Wikipedia language, of which a reader can only have 1. They would still be able to select additional secondary languages in Settings though.

Thank you for the reply, but I think setting the primary language won't solve the whole problem -- as the example given above, if the user previously selected zh-hans (primary), zh-cn and zh-hans, I'm afraid the current design cannot handle this situation.

Thank you @Diskdance for contextualizing. @HNordeenWMF I think it might be hard to both have primary language selection along with secondary language selections in a single prompt.

A few potential avenues to explore:

• The prompt could lead readers to their language settings instead of prompting them to select a variant replacement in the prompt itself
• For users who only have one generic variant as their primary language in their language list use the solution above, for users who have multiple generic languages in their language list show a prompt that sends them to their language settings screen
• For users who have one or more generic variants in their language list but not as primary languages, prompt them to change upon their selecting the variant in their language selector on the article page / in their language settings.

We have decided to work on @cmadeo's second option above, + a solution for users that have both one variant as primary, the other as secondary.

For users who only have one generic variant as their primary language in their language list use the solution above, for users who have multiple generic languages in their language list show a prompt that sends them to their language settings screen

Updated to reflect @HNordeenWMF 's comment above. Please let me know if there are any changes or updates to be made. Thanks!

Thanks for the update! As the designer of the "Chinese variant dialog on web", I think the prompt can have some minor improvements:

1. There is no need to display zh-** codes to end users -- they are technical details, and we cannot assume that all users are tech savvy.
2. I was once told that using "variant" alone may sound confusing to English speakers. Using "language variant" instead may avoid this.
3. Since this is a model dialog that disturb users, we need to emphasize why this is required (what bad will happen if this is not done). A sentence like "your current language variants show unlocalized terms from other regions, reducing reading experience" looks good to me.

Thanks @Diskdance, this feedback is really helpful.

As as a question for @cooltey + @HNordeenWMF re:

3. Since this is a model dialog that disturb users, we need to emphasize why this is required (what bad will happen if this is not done). A sentence like "your current language variants show unlocalized terms from other regions, reducing reading experience" looks good to me.

I understand that this is the case, but also is it true that these language variants will be deprecated on the app? Would it be helpful to say they are being deprecated?

In T360585#9764163, @cmadeo wrote:

I understand that this is the case, but also is it true that these language variants will be deprecated on the app? Would it be helpful to say they are being deprecated?

Yes and yes, saying they are being deprecated is also helpful. The message I provided is just for demonstration, to further explain why they're being deprecated. It's totally OK to say about their deprecation in the message.

@Diskdance, great to know that you designed the web experience, thank you for all the help here!

There is no need to display zh-** codes to end users -- they are technical details, and we cannot assume that all users are tech savvy.

Agree, @cmadeo has already worked on removing the codes!

I was once told that using "variant" alone may sound confusing to English speakers. Using "language variant" instead may avoid this.

Thanks for this advice, it will also be incorporated!

Since this is a model dialog that disturb users, we need to emphasize why this is required (what bad will happen if this is not done). A sentence like "your current language variants show unlocalized terms from other regions, reducing reading experience" looks good to me.

We don't have a firm deprecation date for the Apps. The plan is to hide the generic variants from our selection menus, but users who don't make a selection somehow through this required dialog will still fall back to the generic variant.
I think our current language is sufficient, calling the generic variants "unsupported" and prompting the user to choose a new regional language variant for an "improved reading experience".

Hi! The mock-ups have been updated to reflect the feedback above. @HNordeenWMF let me know if there are any other updates that would be helpful. Thanks!

thanks @cmadeo, that looks good to me!

cooltey opened https://github.com/wikimedia/apps-android-wikipedia/pull/4674

dbrant closed https://github.com/wikimedia/apps-android-wikipedia/pull/4674

cooltey opened https://github.com/wikimedia/apps-android-wikipedia/pull/4677