Change 613591 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Add languages/all route for LanguageInfo overlay

https://gerrit.wikimedia.org/r/613591

Change 609430 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Add languages question

https://gerrit.wikimedia.org/r/609430

No issues have been found - for Design Review - below are my notes on what's been tested and the screenshots for Desktop/Mobile. Also, please review my notes.

Checked in cswiki betalabs

• desktop/mobile
• cross browser testing
• slow network connection
• user input for languages as words in English, as words in other languages, and as language codes
• checking db for correct storage of language selections
• checked for accessibility

Some screenshots - just for illustration:

"No results found"

Notes
(1) The language field is pre-populated upon a user's first login. If it's cswiki original new account - the Czech language selection will be displayed in the field; if it's an auto created account, the language of the origin wiki will be pre-selected.

(2) After selecting 10 languages (the current limit) - a user is still able to click and see the drop-down language selection menu, see the animated gif below - the additional selection (>10 lang) is not possible, but users doesn't get any information that they've reached the limit.

Thanks @Etonkovidova, moving back to Needs More Work for a few minor corrections based on your notes and review. Please see notes inline from reviewing https://cs.wikipedia.beta.wmflabs.org/wiki/Special:WelcomeSurvey

In T232410#6343135, @Etonkovidova wrote:

No issues have been found - for Design Review - below are my notes on what's been tested and the screenshots for Desktop/Mobile. Also, please review my notes.

Checked in cswiki betalabs

• desktop/mobile
• cross browser testing
• slow network connection
• user input for languages as words in English, as words in other languages, and as language codes
• checking db for correct storage of language selections
• checked for accessibility

Some screenshots - just for illustration:

Apologies this was not made explicit, but per the image in the task description, the initial tag for the language wiki that the user is taking the survey should be mandatory and not have the "x" to remove it.

"No results found"

This is fine. The copy is a bit terse, but I assume it is using the same copy as the ULS when there are no matching results, so better to leave it than create a new field.

Mobile

Notes
(1) The language field is pre-populated upon a user's first login. If it's cswiki original new account - the Czech language selection will be displayed in the field; if it's an auto created account, the language of the origin wiki will be pre-selected.

Hmm I didn't get that behaviour when testing. I created an account in enwiki (beta), then when going to the survey in CSwiki, the pre-selected language is only Czech. This is actually the behaviour I'd expect for simplicity's sake, especially given we want the language wiki to not be removable and as we are not prioritising auto-created accounts.

(2) After selecting 10 languages (the current limit) - a user is still able to click and see the drop-down language selection menu, see the animated gif below - the additional selection (>10 lang) is not possible, but users doesn't get any information that they've reached the limit.

@Catrope - can we add an error message when the respondent tries to add an 11th language that says You've added the maximum number of languages.?
Also, we should include info about this maximum number in the question, so can we add assistive text saying Enter up to $max-value languages. to the question, like so:

(3) When the welcome page loads - the language field will be the last one to be displayed. With the slow network connection it's especially noticeable (see the animated gif below)

I am seeing this delay of a 1-1.5sec even on my fairly fast WiFi connection. Is this something that is potentially improved moving from beta to prod? Other ideas:

• Could we try to separate the TagMultiSelectWidget loading from the ULS loading?
• Adding a placeholder space/skeleton before the widget appears?

(4) Interesting that the selected language will be always displayed translated. On Special:ContentTranslation page the selected language will be displayed in the original script, e.g.

Think this is OK. It seems to be how ULS displays the languages.

Hi @Pginer-WMF - @MMiller_WMF and I were wondering if might have any additional comments/suggestions now that this new language question is available to test in beta?
It is available in https://test.wikipedia.beta.wmflabs.org/wiki/Special:WelcomeSurvey (or cswiki beta) if you want to take it for a spin.
Otherwise screenshots and context are in above comment T232410#6346470.

In T232410#6346594, @RHo wrote:

Hi @Pginer-WMF - @MMiller_WMF and I were wondering if might have any additional comments/suggestions now that this new language question is available to test in beta?
It is available in https://test.wikipedia.beta.wmflabs.org/wiki/Special:WelcomeSurvey (or cswiki beta) if you want to take it for a spin.
Otherwise screenshots and context are in above comment T232410#6346470.

Thanks for pinging, Rita. I think it looks and works well. The question seems clear. I only observed a couple of minor aspects to consider:

• The need to clear the search field. When adding a language by searching (e.g., typing 'Cat' to find Catalan") the language selector is closed and the language is added. So far so good. However, clicking to add another one, the language selector is opened with the "Cat" search string filled. In this case, having it cleared would reduce friction.

• (The unlikely event of) Removing all languages. This is more of an edge case, but when all languages are removed from the selection there is no indication on the UI about what that means to the system. Is it mandatory to indicate at least one language? Is there a default that will be applied when this happens?

In T232410#6348088, @Pginer-WMF wrote:

Thanks for pinging, Rita. I think it looks and works well. The question seems clear. I only observed a couple of minor aspects to consider:

• The need to clear the search field. When adding a language by searching (e.g., typing 'Cat' to find Catalan") the language selector is closed and the language is added. So far so good. However, clicking to add another one, the language selector is opened with the "Cat" search string filled. In this case, having it cleared would reduce friction.

Thanks @Pginer-WMF, good catch. @Catrope can we add this as another part that "Needs more work" on this task? I.e., to clear the search field inside the ULS after a language is selected.

• (The unlikely event of) Removing all languages. This is more of an edge case, but when all languages are removed from the selection there is no indication on the UI about what that means to the system. Is it mandatory to indicate at least one language? Is there a default that will be applied when this happens?

Yes, the intention is that there will always be at least one language (the one that the user is currently on) that is mandatorily shown. So the issue that you are seeing where the user is able to remove all tags should not be possible after fixes pending on the task.

Change 617648 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Tweaks for language question

https://gerrit.wikimedia.org/r/617648

In T232410#6346470, @RHo wrote:

Apologies this was not made explicit, but per the image in the task description, the initial tag for the language wiki that the user is taking the survey should be mandatory and not have the "x" to remove it.

Done in the patch above.

This is fine. The copy is a bit terse, but I assume it is using the same copy as the ULS when there are no matching results, so better to leave it than create a new field.

Yes, we're just embedding ULS here, and this is what it came with. I'm not sure ULS even allows us to customize the "no matching results" look/copy.

Hmm I didn't get that behaviour when testing. I created an account in enwiki (beta), then when going to the survey in CSwiki, the pre-selected language is only Czech. This is actually the behaviour I'd expect for simplicity's sake, especially given we want the language wiki to not be removable and as we are not prioritising auto-created accounts.

The pre-selected language was the interface language (the language that the survey and the rest of the interface is being displayed in). This is typically the same as the content language (the language that the wiki's content is written in), since the account was freshly created and the user hasn't had the opportunity to change their language preference. However, it could be different in certain edge cases: the ones I can think of are if the user changed their language then went back to the WelcomeSurvey, or their account is attached to a global account that was created on another wiki and has a global language preference (this is not the default, but you can configure your global language preference to e.g. use English on all wikis). It shouldn't matter in most practical cases, but it was easy to just use the content language instead of the interface language, so I did that.

@Catrope - can we add an error message when the respondent tries to add an 11th language that says You've added the maximum number of languages.?

I've implemented this by changing the placeholder when the maximum is reached. I've also fixed the issue where the language picker would still open if you clicked on the tag widget even when it was full (now, clicking on a full tag widget does nothing, you can't open the language picker again unless you remove a language first).

Also, we should include info about this maximum number in the question, so can we add assistive text saying Enter up to $max-value languages. to the question, like so:

This ended up looking very slightly different, because I'm using the existing OOUI styling for inline help text in a FieldLayout. I'm also using digits (10 languages) instead of spelling out the number (ten languages) for translatability reasons.

(3) When the welcome page loads - the language field will be the last one to be displayed. With the slow network connection it's especially noticeable (see the animated gif below)

I am seeing this delay of a 1-1.5sec even on my fairly fast WiFi connection. Is this something that is potentially improved moving from beta to prod? Other ideas:

• Could we try to separate the TagMultiSelectWidget loading from the ULS loading?
• Adding a placeholder space/skeleton before the widget appears?

I'll work on this tomorrow. The widget makes an API request that I think is unnecessary, and removing that should speed things up quite a bit. But we should also add a placeholder, and we shouldn't initially hide the entire question the way we do now. (Note to self: the mobile version of the language picker is loaded from scratch every time, I need to fix that too.)

(4) Interesting that the selected language will be always displayed translated. On Special:ContentTranslation page the selected language will be displayed in the original script, e.g.

Think this is OK. It seems to be how ULS displays the languages.

ULS displays autonyms (the name of the language in that language itself, e.g. "Deutsch", "Français", "中文"), and I don't think we can control that. In the tag widget, we display the name of the language in the current language (e.g. "German", "French", "Chinese" if the language is English). That's something we control and could change (to autonyms) if desired.

In T232410#6348994, @RHo wrote:

In T232410#6348088, @Pginer-WMF wrote:

• The need to clear the search field. When adding a language by searching (e.g., typing 'Cat' to find Catalan") the language selector is closed and the language is added. So far so good. However, clicking to add another one, the language selector is opened with the "Cat" search string filled. In this case, having it cleared would reduce friction.

Thanks @Pginer-WMF, good catch. @Catrope can we add this as another part that "Needs more work" on this task? I.e., to clear the search field inside the ULS after a language is selected.

I flagged this too when this was still in code review, and Kosta pointed out that ULS also behaves this way. ULS doesn't have a great built-in way to clear the search field after choosing a language, but I was able to get this working with a small amount of hackery.

Thanks @Catrope - for clarity, I've added details for some of this into the description, and asked questions/comments on some other items inline below.

In T232410#6350885, @Catrope wrote:

[..]
The pre-selected language was the interface language (the language that the survey and the rest of the interface is being displayed in). This is typically the same as the content language (the language that the wiki's content is written in), since the account was freshly created and the user hasn't had the opportunity to change their language preference. However, it could be different in certain edge cases: the ones I can think of are if the user changed their language then went back to the WelcomeSurvey, or their account is attached to a global account that was created on another wiki and has a global language preference (this is not the default, but you can configure your global language preference to e.g. use English on all wikis). It shouldn't matter in most practical cases, but it was easy to just use the content language instead of the interface language, so I did that.

• This sounds fine based on our current target wikis. However, I'm curious whether content or interface language would work better for wikis that have different variants, such as srwiki (cyrillic/latin) or zhwiki (trad, simp, and related geo-variants)?

@Catrope - can we add an error message when the respondent tries to add an 11th language that says You've added the maximum number of languages.?

I've implemented this by changing the placeholder when the maximum is reached. I've also fixed the issue where the language picker would still open if you clicked on the tag widget even when it was full (now, clicking on a full tag widget does nothing, you can't open the language picker again unless you remove a language first).

I would prefer to keep the widget enabled but showing an error message on inputting the 11th language is so that there is more explicit feedback provided, in case the user does not understand why all of a sudden the widget is no longer functioning.

I'm not sure if the contrast is sufficient here, but this is what the default OOUI behavior for a disabled input with a placeholder looks like, so if it's wrong we should fix that upstream.

Yes, this does appear to be an oversight. However, we may wish to avoid adapting placeholder text for this purpose anyway, since the purpose of placeholder text is as additional instructions or examples of the data inside fields that *have not yet been edited* by the user, rather than as a message inside a disabled field.

[..]
This ended up looking very slightly different, because I'm using the existing OOUI styling for inline help text in a FieldLayout. I'm also using digits (10 languages) instead of spelling out the number (ten languages) for translatability reasons.

LGTM. I've added to the task description.

(3) When the welcome page loads - the language field will be the last one to be displayed. With the slow network connection it's especially noticeable (see the animated gif below) g

I am seeing this delay of a 1-1.5sec even on my fairly fast WiFi connection. Is this something that is potentially improved moving from beta to prod? Other ideas:

• Could we try to separate the TagMultiSelectWidget loading from the ULS loading?
• Adding a placeholder space/skeleton before the widget appears?

I'll work on this tomorrow. The widget makes an API request that I think is unnecessary, and removing that should speed things up quite a bit. But we should also add a placeholder, and we shouldn't initially hide the entire question the way we do now. (Note to self: the mobile version of the language picker is loaded from scratch every time, I need to fix that too.)

Great thanks. Ideally a placeholder that shows the mandatory language in the widget would be ideal, but if we are talking about some kind of skeleton, it would be great if it was the same same size and style as the widget will load, with a Base90 background color:

Preferred placeholder:	Skeleton:

[...]
ULS displays autonyms (the name of the language in that language itself, e.g. "Deutsch", "Français", "中文"), and I don't think we can control that. In the tag widget, we display the name of the language in the current language (e.g. "German", "French", "Chinese" if the language is English). That's something we control and could change (to autonyms) if desired.

I propose we change to using autonyms on the tags, because it is a bit odd that my selection of a specific autonym converts back to the interface language in the tag. Another minor reason is it may also remove an extra step to collate language usage data collected across pilot wikis.

In T232410#6348088, @Pginer-WMF wrote:

• The need to clear the search field. When adding a language by searching (e.g., typing 'Cat' to find Catalan") the language selector is closed and the language is added. So far so good. However, clicking to add another one, the language selector is opened with the "Cat" search string filled. In this case, having it cleared would reduce friction.

I flagged this too when this was still in code review, and Kosta pointed out that ULS also behaves this way. ULS doesn't have a great built-in way to clear the search field after choosing a language, but I was able to get this working with a small amount of hackery.

OK cool, will check it out once it's available.

In T232410#6351988, @RHo wrote:

• This sounds fine based on our current target wikis. However, I'm curious whether content or interface language would work better for wikis that have different variants, such as srwiki (cyrillic/latin) or zhwiki (trad, simp, and related geo-variants)?

Maybe. I don't know enough about that to have a good answer.

@Catrope - can we add an error message when the respondent tries to add an 11th language that says You've added the maximum number of languages.?

I've implemented this by changing the placeholder when the maximum is reached. I've also fixed the issue where the language picker would still open if you clicked on the tag widget even when it was full (now, clicking on a full tag widget does nothing, you can't open the language picker again unless you remove a language first).

I would prefer to keep the widget enabled but showing an error message on inputting the 11th language is so that there is more explicit feedback provided, in case the user does not understand why all of a sudden the widget is no longer functioning.

The widget disabling itself when it's full is upstream behavior in OOUI. I can override that, but I'm hesitant to do so. Can you clarify what you would like to happen? The user can select an 11th language, but then an error message is shown, and the language is not added? I think that our UIs shouldn't pretend that something is possible only to throw an error message when the user attempts it.

The current behavior (in beta labs, without my patch) is that the widget disables itself, but clicks on it still open the language picker, even though selecting additional language does nothing (the picker closes, but the 11th language isn't added). My patch 1) prevents the language picker from opening on click and 2) displays a message in the disabled widget. If you want, an easy change to make would be to do #2 but not #1, meaning that the message about the maximum would be shown, but the language picker would still open on click. Selecting a language would not cause it to be added, but no explicit error message would be shown, other than the message in the input saying you can't add more languages (and the general change in the widget's appearance due to its disabled-ness). Still though, I think that violates the principle of not letting users do things that we know in advance will not be allowed.

I'm not sure if the contrast is sufficient here, but this is what the default OOUI behavior for a disabled input with a placeholder looks like, so if it's wrong we should fix that upstream.

Yes, this does appear to be an oversight. However, we may wish to avoid adapting placeholder text for this purpose anyway, since the purpose of placeholder text is as additional instructions or examples of the data inside fields that *have not yet been edited* by the user, rather than as a message inside a disabled field.

Right, on further reflection a placeholder in a disabled field doesn't make much sense, and I'm abusing the placeholder feature here. So if we do stick with abusing the placeholder, it would also be OK to restyle it to make the contrast better, and maybe make it yellow or red or something to make it look more like a warning/error.

I am seeing this delay of a 1-1.5sec even on my fairly fast WiFi connection. Is this something that is potentially improved moving from beta to prod? Other ideas:

• Could we try to separate the TagMultiSelectWidget loading from the ULS loading?
• Adding a placeholder space/skeleton before the widget appears?

I'll work on this tomorrow. The widget makes an API request that I think is unnecessary, and removing that should speed things up quite a bit. But we should also add a placeholder, and we shouldn't initially hide the entire question the way we do now. (Note to self: the mobile version of the language picker is loaded from scratch every time, I need to fix that too.)

Great thanks. Ideally a placeholder that shows the mandatory language in the widget would be ideal, but if we are talking about some kind of skeleton, it would be great if it was the same same size and style as the widget will load, with a Base90 background color:

Preferred placeholder:	Skeleton:

Thanks for these, they'll be helpful as I work on this today.

[...]
ULS displays autonyms (the name of the language in that language itself, e.g. "Deutsch", "Français", "中文"), and I don't think we can control that. In the tag widget, we display the name of the language in the current language (e.g. "German", "French", "Chinese" if the language is English). That's something we control and could change (to autonyms) if desired.

I propose we change to using autonyms on the tags, because it is a bit odd that my selection of a specific autonym converts back to the interface language in the tag. Another minor reason is it may also remove an extra step to collate language usage data collected across pilot wikis.

I agree that it's confusing. Changing to autonyms will also help with the slowness issue, because the API request I was referring to was used to get the translated names of all languages. I was going to use a different mechanism that doesn't require an API request, but with now we don't need them at all anymore.

As for data collection, that won't be affected, because the answer is stored as a list of language codes. For example, if I created an account on nlwiki and said I speak English, German, Frisian and French in addition to Dutch, my answer to this question would be recorded as ["nl","en","de","fy","fr"].

Change 617781 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Use autonyms for language question

https://gerrit.wikimedia.org/r/617781

Change 617648 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Tweaks for language question

https://gerrit.wikimedia.org/r/617648

@Pginer-WMF @RHo @Catrope -- thanks for working on this over the last couple weeks. I went through the discussion and have comments, quotes, suggestions, and changes below (separated by horizontal rules).

Question for @Pginer-WMF: when I start typing "Eng" to pick English, the first languages that come up are British English and Canadian English. Do you think users get confused by that and pick the wrong thing?

We should change the text from "over 300 languages" to "nearly 300 languages", to bring it in line with what wikimediafoundation.org says.

On mobile, when I go to select multiple languages, it lists the languages that I've already selected up at the top as "Suggested languages". This could be annoying because they are the exact languages that I don't want to see on my screen at this point, given that I've already selected them. What actions cause them to be listed up there? Is there an easy way to remove already-selected languages from the picker list?

This ended up looking very slightly different, because I'm using the existing OOUI styling for inline help text in a FieldLayout. I'm also using digits (10 languages) instead of spelling out the number (ten languages) for translatability reasons.

LGTM. I've added to the task description.

@RHo -- how about instead of the assistive text that says, "Enter up to 10 languages", we have the prompt in the dropdown say "Add up to 10 languages..." instead of just "Add more languages..." Then it would kill two birds with one stone, with less ink on the page.

@Catrope - can we add an error message when the respondent tries to add an 11th language that says You've added the maximum number of languages.?

I've implemented this by changing the placeholder when the maximum is reached. I've also fixed the issue where the language picker would still open if you clicked on the tag widget even when it was full (now, clicking on a full tag widget does nothing, you can't open the language picker again unless you remove a language first).

I would prefer to keep the widget enabled but showing an error message on inputting the 11th language is so that there is more explicit feedback provided, in case the user does not understand why all of a sudden the widget is no longer functioning.

The widget disabling itself when it's full is upstream behavior in OOUI. I can override that, but I'm hesitant to do so. Can you clarify what you would like to happen? The user can select an 11th language, but then an error message is shown, and the language is not added? I think that our UIs shouldn't pretend that something is possible only to throw an error message when the user attempts it.

The current behavior (in beta labs, without my patch) is that the widget disables itself, but clicks on it still open the language picker, even though selecting additional language does nothing (the picker closes, but the 11th language isn't added). My patch 1) prevents the language picker from opening on click and 2) displays a message in the disabled widget. If you want, an easy change to make would be to do #2 but not #1, meaning that the message about the maximum would be shown, but the language picker would still open on click. Selecting a language would not cause it to be added, but no explicit error message would be shown, other than the message in the input saying you can't add more languages (and the general change in the widget's appearance due to its disabled-ness). Still though, I think that violates the principle of not letting users do things that we know in advance will not be allowed.

@Catrope @RHo -- I don't think we should change this from the "with patch behavior" (disabled widget with message). It sounds like more work, and I think it functions well the way it is. I do notice, though, on mobile that the message is too long (see screenshot below). Can it be made to wrap? If not, then the text can just be, "Maximum of 10 languages".

(3) When the welcome page loads - the language field will be the last one to be displayed. With the slow network connection it's especially noticeable (see the animated gif below)

I am seeing this delay of a 1-1.5sec even on my fairly fast WiFi connection. Is this something that is potentially improved moving from beta to prod? Other ideas:

• Could we try to separate the TagMultiSelectWidget loading from the ULS loading?
• Adding a placeholder space/skeleton before the widget appears?

I'll work on this tomorrow. The widget makes an API request that I think is unnecessary, and removing that should speed things up quite a bit. But we should also add a placeholder, and we shouldn't initially hide the entire question the way we do now. (Note to self: the mobile version of the language picker is loaded from scratch every time, I need to fix that too.)

I agree that it's important to address the loading speed issue. It is quite noticeable.

Change 618165 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Reuse server-rendered language question field

https://gerrit.wikimedia.org/r/618165

In T232410#6358294, @gerritbot wrote:

Change 618165 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Reuse server-rendered language question field

https://gerrit.wikimedia.org/r/618165

This is a relatively quick and dirty approach to displaying a loading placeholder for the language question. It displays an empty box with the same dimensions and color as the widget.

While loading:

Once loaded:

Change 618170 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Change wording of language question

https://gerrit.wikimedia.org/r/618170

In T232410#6358117, @MMiller_WMF wrote:

Question for @Pginer-WMF: when I start typing "Eng" to pick English, the first languages that come up are British English and Canadian English. Do you think users get confused by that and pick the wrong thing?

Side note: as you probably realize (because you directed the question to @Pginer-WMF) this behavior comes from ULS, and would have to be fixed there.

We should change the text from "over 300 languages" to "nearly 300 languages", to bring it in line with what wikimediafoundation.org says.

Patch submitted.

On mobile, when I go to select multiple languages, it lists the languages that I've already selected up at the top as "Suggested languages". This could be annoying because they are the exact languages that I don't want to see on my screen at this point, given that I've already selected them. What actions cause them to be listed up there? Is there an easy way to remove already-selected languages from the picker list?

We're reusing something from MobileFrontend here, so you'd have to ask the Reading Web team (cc @Jdlrobson who helped us use this, and reviewed Kosta's code).

@RHo -- how about instead of the assistive text that says, "Enter up to 10 languages", we have the prompt in the dropdown say "Add up to 10 languages..." instead of just "Add more languages..." Then it would kill two birds with one stone, with less ink on the page.

I like that idea. If Rita agrees I'll implement it.

The current behavior (in beta labs, without my patch) is that the widget disables itself, but clicks on it still open the language picker, even though selecting additional language does nothing (the picker closes, but the 11th language isn't added). My patch 1) prevents the language picker from opening on click and 2) displays a message in the disabled widget. If you want, an easy change to make would be to do #2 but not #1, meaning that the message about the maximum would be shown, but the language picker would still open on click. Selecting a language would not cause it to be added, but no explicit error message would be shown, other than the message in the input saying you can't add more languages (and the general change in the widget's appearance due to its disabled-ness). Still though, I think that violates the principle of not letting users do things that we know in advance will not be allowed.

@Catrope @RHo -- I don't think we should change this from the "with patch behavior" (disabled widget with message). It sounds like more work, and I think it functions well the way it is.

OK, great, that means I don't have to change anything.

I do notice, though, on mobile that the message is too long (see screenshot below). Can it be made to wrap? If not, then the text can just be, "Maximum of 10 languages".

No, it can't wrap, and as Rita points out it's also an abuse of the placeholder feature. So maybe we can make this an error message that's displayed somewhere else (e.g. below the input, possibly replacing the "Enter up to 10 languages" help text), or we can do what you suggested above and use an unchanging placeholder (but one that stays when the widget is full, the default upstream behavior is for it to disappear).

I agree that it's important to address the loading speed issue. It is quite noticeable.

My pending patch to use autonyms instead of translated language names should make it load faster, because it eliminates an API request to fetch the translated language names. Per my previous comment, I've also uploaded a patch to display a placeholder while the widget loads, to make the transition less jarring. It's pretty basic, but we could add an animation or something if desired (and if @RHo provides one).

In T232410#6358548, @Catrope wrote:

In T232410#6358117, @MMiller_WMF wrote:

Question for @Pginer-WMF: when I start typing "Eng" to pick English, the first languages that come up are British English and Canadian English. Do you think users get confused by that and pick the wrong thing?

Side note: as you probably realize (because you directed the question to @Pginer-WMF) this behavior comes from ULS, and would have to be fixed there.

I think this is related to the variant question I raised earlier, since the ULS implemented allows users to choose a language as well as all its variants (e.g., one may not only add Chinese, but also Chinese (Hong Kong), Chinese (Simplified), etc). @Pginer-WMF can correct/confirm, but my suggestion is that we should only show the root language and hide the variants.
However, if this is not an easy thing to do quickly, perhaps in the short term (and since we are only collecting information at this stage and not asking users to translate anything yet), maybe we can let users enter multiple variants if they so choose and just de-dupe variants in the data analysis (e.g., if someone enters English, Canadian English, and British English, we count this as 1 language not 3).

On mobile, when I go to select multiple languages, it lists the languages that I've already selected up at the top as "Suggested languages". This could be annoying because they are the exact languages that I don't want to see on my screen at this point, given that I've already selected them. What actions cause them to be listed up there? Is there an easy way to remove already-selected languages from the picker list?

We're reusing something from MobileFrontend here, so you'd have to ask the Reading Web team (cc @Jdlrobson who helped us use this, and reviewed Kosta's code).

I agree with @MMiller_WMF this does seem a bit confusing, esp. as it's an overlay so users may be confused that the language they previously selected didn't get added. Can we remove any selected language from appearing in the list? This includes the mandatory UI language.

@RHo -- how about instead of the assistive text that says, "Enter up to 10 languages", we have the prompt in the dropdown say "Add up to 10 languages..." instead of just "Add more languages..." Then it would kill two birds with one stone, with less ink on the page.

I like that idea. If Rita agrees I'll implement it.

Sure, SGTM.

The current behavior (in beta labs, without my patch) is that the widget disables itself, but clicks on it still open the language picker, even though selecting additional language does nothing (the picker closes, but the 11th language isn't added). My patch 1) prevents the language picker from opening on click and 2) displays a message in the disabled widget. If you want, an easy change to make would be to do #2 but not #1, meaning that the message about the maximum would be shown, but the language picker would still open on click. Selecting a language would not cause it to be added, but no explicit error message would be shown, other than the message in the input saying you can't add more languages (and the general change in the widget's appearance due to its disabled-ness). Still though, I think that violates the principle of not letting users do things that we know in advance will not be allowed.

@Catrope @RHo -- I don't think we should change this from the "with patch behavior" (disabled widget with message). It sounds like more work, and I think it functions well the way it is.

OK, great, that means I don't have to change anything.

I agree that it'd be confusing for the user to be able to open the ULS, so yes about keeping the patch disabling the widget. However I still don't think we should use the placeholder message in this way, and would prefer @Catrope's suggestion below about adding an error message below the input instead.

I do notice, though, on mobile that the message is too long (see screenshot below). Can it be made to wrap? If not, then the text can just be, "Maximum of 10 languages".

No, it can't wrap, and as Rita points out it's also an abuse of the placeholder feature. So maybe we can make this an error message that's displayed somewhere else (e.g. below the input, possibly replacing the "Enter up to 10 languages" help text), or we can do what you suggested above and use an unchanging placeholder (but one that stays when the widget is full, the default upstream behavior is for it to disappear).

I like making this an error message under the field instead that only appears after 10 languages have been added.
Per my above comment, not a fan of the placeholder text use here as it is misusing the function of placeholder text, not able to wrap, and is non-colour contrast compliant. Three strikes!

I agree that it's important to address the loading speed issue. It is quite noticeable.

My pending patch to use autonyms instead of translated language names should make it load faster, because it eliminates an API request to fetch the translated language names. Per my previous comment, I've also uploaded a patch to display a placeholder while the widget loads, to make the transition less jarring. It's pretty basic, but we could add an animation or something if desired (and if @RHo provides one).

Sure, maybe we could we use the same animation as CX?

Change 617781 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Use autonyms for language question

https://gerrit.wikimedia.org/r/617781

Change 618165 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Reuse server-rendered language question field

https://gerrit.wikimedia.org/r/618165

Change 618170 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Change wording of language question

https://gerrit.wikimedia.org/r/618170

In T232410#6358117, @MMiller_WMF wrote:

We should change the text from "over 300 languages" to "nearly 300 languages", to bring it in line with what wikimediafoundation.org says.

Where exactly does it say it?

I'm pretty sure that by mid-2020, "over 300" is the correct thing, but I'm willing to be corrected.

(It's true that Wikipedias in dozens of these languages are not active, and I'm fine with omitting them from the count, but only if precise and consistent criteria for this are given.)

In T232410#6362131, @Amire80 wrote:

In T232410#6358117, @MMiller_WMF wrote:

We should change the text from "over 300 languages" to "nearly 300 languages", to bring it in line with what wikimediafoundation.org says.

Where exactly does it say it?

I'm pretty sure that by mid-2020, "over 300" is the correct thing, but I'm willing to be corrected.

(It's true that Wikipedias in dozens of these languages are not active, and I'm fine with omitting them from the count, but only if precise and consistent criteria for this are given.)

Hi @Amire80 - we figured this was safe wording to go with since "nearly 300 languages" appears in a few places on the foundation site, and other 'official' comms like the iOS App store description and the WIkimania 2020 about page:

• https://wikimediafoundation.org/our-work/wikipedia/
• https://wikimediafoundation.org/our-work/education/
• https://wikimediafoundation.org/news/tag/global-preferences/
• https://apps.apple.com/dk/app/wikipedia/id324715238
• https://wikimania.wikimedia.org/wiki/About

In T232410#6362248, @RHo wrote:

In T232410#6362131, @Amire80 wrote:

In T232410#6358117, @MMiller_WMF wrote:

We should change the text from "over 300 languages" to "nearly 300 languages", to bring it in line with what wikimediafoundation.org says.

Where exactly does it say it?

I'm pretty sure that by mid-2020, "over 300" is the correct thing, but I'm willing to be corrected.

(It's true that Wikipedias in dozens of these languages are not active, and I'm fine with omitting them from the count, but only if precise and consistent criteria for this are given.)

Hi @Amire80 - we figured this was safe wording to go with since "nearly 300 languages" appears in a few places on the foundation site, and other 'official' comms like the iOS App store description and the WIkimania 2020 about page:

• https://wikimediafoundation.org/our-work/wikipedia/
• https://wikimediafoundation.org/our-work/education/
• https://wikimediafoundation.org/news/tag/global-preferences/
• https://apps.apple.com/dk/app/wikipedia/id324715238
• https://wikimania.wikimedia.org/wiki/About

Thanks for the links. The word "nearly" may have been borderline true in 2019, but I'm quite sure that as of August 2020 it is outdated.

I'll check with the site administrators of the WMF website, and when it's updated, I'll ping GrowthExperiments, too.

There are 265 Wikipedias with over 1000 articles, 302 Wikipedias with over 10 articles. For fundraising messaging it has been a recurring community complaint that some see it as disingenious to say "You can read Wikipedia in over 300 languages" when many of those have basically no content.

In T232410#6362725, @Tgr wrote:

There are 265 Wikipedias with over 1000 articles, 302 Wikipedias with over 10 articles. For fundraising messaging it has been a recurring community complaint that some see it as disingenious to say "You can read Wikipedia in over 300 languages" when many of those have basically no content.

Yeah, so this sounds like reasonable criteria, I'd just like the criteria defined somewhere in official and written form :)

Thanks, @Amire80, for looking over this task and weighing in. We're going to stick with "nearly 300" for now, and please let us know if that changes more broadly.

@RHo and I just finished talking about the remaining work for @Catrope, and so we have some decisions, plus some questions for @Pginer-WMF:

Question for @Pginer-WMF: when I start typing "Eng" to pick English, the first languages that come up are British English and Canadian English. Do you think users will get confused by that and pick the wrong thing? I know we're repurposing a component made for choosing a language to read in, but interested in any suggestions you have. @Catrope -- is it possible to tell which languages are "variants", and keep them out of the list, keeping just the root language (e.g. "English")? If not, in the near term, it could be fine to change nothing, because we're only going to be counting up responses to this question, not using it for workflows yet.

@Pginer-WMF @Jdlrobson -- on mobile, when I go to select multiple languages, it lists the languages that I've already selected up at the top as "Suggested languages". This could be annoying because they are the exact languages that I don't want to see on my screen at this point, given that I've already selected them. What actions cause them to be listed up there? Is there an easy way to remove already-selected languages from the picker list?

This ended up looking very slightly different, because I'm using the existing OOUI styling for inline help text in a FieldLayout. I'm also using digits (10 languages) instead of spelling out the number (ten languages) for translatability reasons.

LGTM. I've added to the task description.

@RHo -- how about instead of the assistive text that says, "Enter up to 10 languages", we have the prompt in the dropdown say "Add up to 10 languages..." instead of just "Add more languages..." Then it would kill two birds with one stone, with less ink on the page.

@Catrope -- we decided that we do in fact want to implement it this way.

@Catrope @RHo -- I don't think we should change this from the "with patch behavior" (disabled widget with message). It sounds like more work, and I think it functions well the way it is. I do notice, though, on mobile that the message is too long (see screenshot below). Can it be made to wrap? If not, then the text can just be, "Maximum of 10 languages".

OK, great, that means I don't have to change anything.

I agree that it'd be confusing for the user to be able to open the ULS, so yes about keeping the patch disabling the widget. However I still don't think we should use the placeholder message in this way, and would prefer @Catrope's suggestion below about adding an error message below the input instead.

@RHo and I talked about this. We decided that if the user has chosen 10 languages, the behavior we want is:

• Disable the widget
• Placeholder text disappears (per upstream behavior)
• Error message below the selector: "You have added the maximum number of languages."

I agree that it's important to address the loading speed issue. It is quite noticeable.

My pending patch to use autonyms instead of translated language names should make it load faster, because it eliminates an API request to fetch the translated language names. Per my previous comment, I've also uploaded a patch to display a placeholder while the widget loads, to make the transition less jarring. It's pretty basic, but we could add an animation or something if desired (and if @RHo provides one).

Sure, maybe we could we use the same animation as CX?

Here's the css copied to codepen: https://codepen.io/reets/pen/poyzGZd

@Catrope -- just bringing this thread back so it's not forgotten.

In T232410#6363107, @MMiller_WMF wrote:

Question for @Pginer-WMF: when I start typing "Eng" to pick English, the first languages that come up are British English and Canadian English. Do you think users will get confused by that and pick the wrong thing?

I think the expectation for this context would be to select main languages (English) instead of variants.

The language selector allows to be customized to show a list of languages of your choice. For example, it is used to navigate to Wikipedias in other languages (example). In that case, the list of languages is only about main ones (there is no British English Wikipedia) and are limited to the specific languages the article is available in.

Engineers in the language team can help with the technical details if needed.

---

@Pginer-WMF @Jdlrobson -- on mobile, when I go to select multiple languages, it lists the languages that I've already selected up at the top as "Suggested languages". This could be annoying because they are the exact languages that I don't want to see on my screen at this point, given that I've already selected them. What actions cause them to be listed up there? Is there an easy way to remove already-selected languages from the picker list?

On the mobile web, the language selection component is a different one, that was not created by the Language team. So I'm not sure how customizable that part is. On desktop it can be configured and uses a combination of different criteria to anticipate the languages the user may be looking for.

Surfacing recently selected languages makes a lot of sense in a context of repetition over time. For example, when reading Wikipedia articles always in the same 2-4 languages it is very useful not to go through the full search process every day.

For this particular case, it does not make sense to show already selected languages. It may be useful to surface previous choices from other contexts. For example, if they navigate between Korean and Japanese Wikipedias, surfacing those could be useful. That information should be available in the ULS-based selector but I don't know about the mobile web one.

Change 618644 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Add error message for languages question

https://gerrit.wikimedia.org/r/618644

Change 618645 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Animate loading placeholder for languages question

https://gerrit.wikimedia.org/r/618645

In T232410#6363107, @MMiller_WMF wrote:

@RHo -- how about instead of the assistive text that says, "Enter up to 10 languages", we have the prompt in the dropdown say "Add up to 10 languages..." instead of just "Add more languages..." Then it would kill two birds with one stone, with less ink on the page.

@Catrope -- we decided that we do in fact want to implement it this way.
[...]
@RHo and I talked about this. We decided that if the user has chosen 10 languages, the behavior we want is:

• Disable the widget
• Placeholder text disappears (per upstream behavior)
• Error message below the selector: "You have added the maximum number of languages."

Implemented in the attached patch.

9 languages selected:

10 languages selected:

Sure, maybe we could we use the same animation as CX?

Here's the css copied to codepen: https://codepen.io/reets/pen/poyzGZd

@Catrope -- just bringing this thread back so it's not forgotten.

It took a bit of adaptation, but I managed to implement this in the attached patch.

In T232410#6363303, @Pginer-WMF wrote:

In T232410#6363107, @MMiller_WMF wrote:

Question for @Pginer-WMF: when I start typing "Eng" to pick English, the first languages that come up are British English and Canadian English. Do you think users will get confused by that and pick the wrong thing?

I think the expectation for this context would be to select main languages (English) instead of variants.

The language selector allows to be customized to show a list of languages of your choice. For example, it is used to navigate to Wikipedias in other languages (example). In that case, the list of languages is only about main ones (there is no British English Wikipedia) and are limited to the specific languages the article is available in.

Engineers in the language team can help with the technical details if needed.

Unfortunately I'm not familiar with a clean list of which languages are "variants" and which ones are "main languages". I guess we could filter out language codes with dashes? Or if we're using this to drive users to CX, limit it to languages in which Wikipedias exist?

In T232410#6364839, @Catrope wrote:

In T232410#6363107, @MMiller_WMF wrote:

@RHo and I talked about this. We decided that if the user has chosen 10 languages, the behavior we want is:

• Disable the widget
• Placeholder text disappears (per upstream behavior)
• Error message below the selector: "You have added the maximum number of languages."

Implemented in the attached patch.
9 languages selected:

LGTM

10 languages selected:

Can we use the inline message style instead without the bordered background? And actually, instead of error message in red, the warning message seems more apt if it is coming up on the 10th language since the user can still proceed.

Sure, maybe we could we use the same animation as CX?

Here's the css copied to codepen: https://codepen.io/reets/pen/poyzGZd

@Catrope -- just bringing this thread back so it's not forgotten.

It took a bit of adaptation, but I managed to implement this in the attached patch.

Looks fine from what i can tell in the screenshot

In T232410#6363303, @Pginer-WMF wrote:

In T232410#6363107, @MMiller_WMF wrote:

Question for @Pginer-WMF: when I start typing "Eng" to pick English, the first languages that come up are British English and Canadian English. Do you think users will get confused by that and pick the wrong thing?

I think the expectation for this context would be to select main languages (English) instead of variants.
The language selector allows to be customized to show a list of languages of your choice. For example, it is used to navigate to Wikipedias in other languages (example). In that case, the list of languages is only about main ones (there is no British English Wikipedia) and are limited to the specific languages the article is available in.

Engineers in the language team can help with the technical details if needed.

Unfortunately I'm not familiar with a clean list of which languages are "variants" and which ones are "main languages". I guess we could filter out language codes with dashes? Or if we're using this to drive users to CX, limit it to languages in which Wikipedias exist?

My understanding was that us using ULS was already limiting to the languages in which Wikipedia exists. Filtering out codes with a dash sounds right to me, but perhaps this is where @Pginer-WMF and language team engineers could help?

In T232410#6365238, @RHo wrote:

My understanding was that us using ULS was already limiting to the languages in which Wikipedia exists. Filtering out codes with a dash sounds right to me, but perhaps this is where @Pginer-WMF and language team engineers could help?

The ULS language selector is used in different contexts showing the options that are available in each case. For UI language selection it shows all variants, but other contexts such as Wikipedia language selection or input method selection, the list is more limited.

In this case, I think that filtering by the languages in which Wikipedia exists seem a good approach. If you want to use this information to suggest articles, work to do, mentors, etc., having a Wikipedia is likely to become a requirement anyways.

@Amire80 or @santhosh may have more thoughts on this.

Change 618806 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@wmf/1.36.0-wmf.3] WelcomeSurvey: Use autonyms for language question

https://gerrit.wikimedia.org/r/618806

Change 618807 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@wmf/1.36.0-wmf.3] WelcomeSurvey: Reuse server-rendered language question field

https://gerrit.wikimedia.org/r/618807

Checking in cswiki wmf.3
Issues:

• the autosuggestion briefly flashes when the focus (on-click) is in row uls-search

(click on the animated gif below)

• contrast ratio 3.81 for "You've added the maximum number..." (background-color: #eaecf0; color: #72777d; ) (which is Fail for Accessibility). "Enter up to 10 languages" is fine (7.09 ratio).

.oo-ui-textInputWidget.oo-ui-widget-disabled .oo-ui-inputWidget-input {
    background-color: #eaecf0;
    -webkit-text-fill-color: #72777d;
    color: #72777d;
    text-shadow: 0 1px 1px #fff;
    border-color: #c8ccd1;

The following looks fine

• the load of the page -smooth; the dot image will be deployed next
• all the labels for 10 languages are in place

Notes:

• ULS seems to have non-translated languages into local languages wikis, e.g.
  

betalabs behaves differently:

• technically speaking, a user adds only 9 languages, not 10

@Etonkovidova -- all the things you listed are fine with me. The things about contrast will be solved because @Catrope's latest patches are going to get rid of those words entirely. Let's leave this in QA so that you can check the patches that are going to be on next week's train.

Change 618806 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.36.0-wmf.3] WelcomeSurvey: Use autonyms for language question

https://gerrit.wikimedia.org/r/618806

Change 618807 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.36.0-wmf.3] WelcomeSurvey: Reuse server-rendered language question field

https://gerrit.wikimedia.org/r/618807

Mentioned in SAL (#wikimedia-operations) [2020-08-06T23:21:26Z] <catrope@deploy1001> Synchronized php-1.36.0-wmf.3/extensions/GrowthExperiments/: Fixes for WelcomeSurvey language question (T232410) (duration: 00m 59s)

In T232410#6365338, @Pginer-WMF wrote:

In this case, I think that filtering by the languages in which Wikipedia exists seem a good approach. If you want to use this information to suggest articles, work to do, mentors, etc., having a Wikipedia is likely to become a requirement anyways.

@Amire80 or @santhosh may have more thoughts on this.

If any of you are aware of an existing UI or existing code that does this (obtain a list of languages in which Wikipedia exists, and filter ULS by it) and can point me to it, I would be very grateful. I suspect CX has to do something like this, so that's the first place where I'll start looking myself once I have time.

In T232410#6365238, @RHo wrote:

Can we use the inline message style instead without the bordered background? And actually, instead of error message in red, the warning message seems more apt if it is coming up on the 10th language since the user can still proceed.

Not sure exactly what you mean here, but I'm guessing it's class="warning"? (See table below)

errorbox (current)
warningbox
error
warning (proposed)

I've updated my patch to use warning since that seems like a reasonable interpretation of what you described.

In T232410#6367533, @Catrope wrote:

In T232410#6365238, @RHo wrote:

Can we use the inline message style instead without the bordered background? And actually, instead of error message in red, the warning message seems more apt if it is coming up on the 10th language since the user can still proceed.

Not sure exactly what you mean here, but I'm guessing it's class="warning"? (See table below)

errorbox (current)
warningbox
error
warning (proposed)

I've updated my patch to use warning since that seems like a reasonable interpretation of what you described.

Yes, the warning you've applied is what I meant. Thanks!

In T232410#6363107, @MMiller_WMF wrote:

on mobile, when I go to select multiple languages, it lists the languages that I've already selected up at the top as "Suggested languages". This could be annoying because they are the exact languages that I don't want to see on my screen at this point, given that I've already selected them. What actions cause them to be listed up there? Is there an easy way to remove already-selected languages from the picker list?

Yeah that feels a bit annoying. The ULS widget has a language list parameter, but it can't be modified on the fly. Could we recreate the ULS widget after every selection? It disappears anyway so it doesn't seem like a big deal.

Change 618644 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Add error message for languages question

https://gerrit.wikimedia.org/r/618644

Change 618645 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Animate loading placeholder for languages question

https://gerrit.wikimedia.org/r/618645

For Design review:
There is a small issue T259936: [betalabs] FF only - vertical scrollbar displayed minimized for ULS which I added to the Current sprint.

Checked

WelcomeSurvey: Animate loading placeholder for languages question

(click on the animated gif)

WelcomeSurvey: Add error message for languages question

After discussion with @Catrope and @RHo, these are the things left to do, in priority order. If they collectively take more than a couple hours, we'll break them off into "leftovers" tasks.

1. On mobile, when you select a language, and then go to select another, the already-selected-language is up at the top of list as a "suggested language". We should suppress that -- those are languages the user does not need to see anymore.
2. More broadly, we should generally exclude already-selected languages from the list for subsequent selections, both on desktop and mobile.
3. Error message styling:
   • Make background color #FFF instead of base90
   • Make font-size smaller (14px)
   • Adding padding-top:4px
4. Suppress language variants from the list, such as "en-gb" and "ku-arab"

On mobile, when you select a language, and then go to select another, the already-selected-language is up at the top of list as a "suggested language". We should suppress that -- those are languages the user does not need to see anymore.

Yeah this is a consequence of reusing a component that was designed for language article selection, where having the suggested list makes sense, but it doesn't here.

We can work around this by modifying getStructuredLanguages() in MobileFrontend's src/mobile.languages.structured/util.js to accept a parameter that skips building the suggested languages section. Then we'd pass that parameter when using the LanguageSearcher via the languages/all route.

Change 620354 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/MobileFrontend@master] LanguageInfoOverlay: Add route that excludes suggestions

https://gerrit.wikimedia.org/r/620354

More broadly, we should generally exclude already-selected languages from the list for subsequent selections, both on desktop and mobile.

Working on this as well.

Change 620363 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/MobileFrontend@master] LanguageSearcher: Support excluding languages from info overlay

https://gerrit.wikimedia.org/r/620363

Change 620364 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Hide suggestions from info overlay

https://gerrit.wikimedia.org/r/620364

Change 620365 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Exclude already selected languages from overlay

https://gerrit.wikimedia.org/r/620365

Note that because 97b7efa2f21 changed the language data used in the desktop language picker to use the UniversalLanguageSelector languages instead of the languageinfo API, so there are not consistent results shown between desktop and mobile. It won't be as much of an issue if we do T232410#6367526, and filter down the list to language wikipedias which exist.

In T232410#6367526, @Catrope wrote:

In T232410#6365338, @Pginer-WMF wrote:

In this case, I think that filtering by the languages in which Wikipedia exists seem a good approach. If you want to use this information to suggest articles, work to do, mentors, etc., having a Wikipedia is likely to become a requirement anyways.

@Amire80 or @santhosh may have more thoughts on this.

If any of you are aware of an existing UI or existing code that does this (obtain a list of languages in which Wikipedia exists, and filter ULS by it) and can point me to it, I would be very grateful. I suspect CX has to do something like this, so that's the first place where I'll start looking myself once I have time.

CX has an API endpoint that defines pairings for each language, maybe we could make use of that? I'm not totally sure.

@kostajh -- we don't think you have to write any more patches for this.  We want to forego both (a) suppressing language variants, and (b) removing already-selected languages from desktop.  And @Catrope has a patch for the styling issue.  So this all should be basically in Code Review, with no more pending work.

Change 620354 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] LanguageInfoOverlay: Add route that excludes suggestions

https://gerrit.wikimedia.org/r/620354

Change 621269 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/skins/MinervaNeue@master] Add route for excluding language suggestions

https://gerrit.wikimedia.org/r/621269

Change 621269 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Add route for excluding language suggestions

https://gerrit.wikimedia.org/r/621269

Change 620364 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Hide suggestions from info overlay

https://gerrit.wikimedia.org/r/620364

Change 623431 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Style fixes for languages warning message

https://gerrit.wikimedia.org/r/623431

My patch addresses these styling tweaks:

In T232410#6377157, @MMiller_WMF wrote:

1. Error message styling:
   • Make background color #FFF instead of base90
   • Make font-size smaller (14px)
   • Adding padding-top:4px

Change 620363 abandoned by Kosta Harlan:
[mediawiki/extensions/MobileFrontend@master] LanguageSearcher: Support excluding languages from info overlay

Reason:
Paused for now

https://gerrit.wikimedia.org/r/620363

Change 620365 abandoned by Kosta Harlan:
[mediawiki/extensions/GrowthExperiments@master] Exclude already selected languages from overlay

Reason:
Paused for now

https://gerrit.wikimedia.org/r/620365

Change 623431 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] WelcomeSurvey: Style fixes for languages warning message

https://gerrit.wikimedia.org/r/623431

In T232410#6424488, @Catrope wrote:

My patch addresses these styling tweaks:

In T232410#6377157, @MMiller_WMF wrote:

1. Error message styling:
   • Make background color #FFF instead of base90
   • Make font-size smaller (14px)
   • Adding padding-top:4px

All seems to be in place:

Hi @MMiller_WMF - the styling item (no. 3) below is done for Desktop (see @Etonkovidova's message T232410#6425650).
Item 1 is also competed, though it is a bit strange to see a label for "Other languages" now that the "Suggested languages" list is removed:

Per your comments I've created Growth-Team-Leftovers tasks T261730 and T261737 for items 2 and 4 respectively.

In T232410#6377157, @MMiller_WMF wrote:

After discussion with @Catrope and @RHo, these are the things left to do, in priority order. If they collectively take more than a couple hours, we'll break them off into "leftovers" tasks.

1. On mobile, when you select a language, and then go to select another, the already-selected-language is up at the top of list as a "suggested language". We should suppress that -- those are languages the user does not need to see anymore.
2. More broadly, we should generally exclude already-selected languages from the list for subsequent selections, both on desktop and mobile.
3. Error message styling:
   • Make background color #FFF instead of base90
   • Make font-size smaller (14px)
   • Adding padding-top:4px
4. Suppress language variants from the list, such as "en-gb" and "ku-arab"