Page MenuHomePhabricator

Newcomer tasks: add language question to welcome survey
Open, Needs TriagePublic

Description

Background

Future versions of newcomer tasks may include suggestions to do Content Translation. The language team (such as @Pginer-WMF ) currently use a set of heuristics to determine which users to recommend Content Translation to, based on which language Wikipedias they've used, their browser language, and their location. This may be useful to us, but many newcomers will not have sufficient information from those heuristics to determine that they are likely bilingual.

Therefore, we want to try adding a question to the welcome survey asking users to identify the languages they read and write. This will probably also yield some very interesting research results, as it is essentially a survey of which languages newcomers know.

Proposed design

The question would look something like this in the welcome survey, with a multi-select picker for different languages:

Mockup: https://wikimedia.invisionapp.com/share/FUTVMSLV24X#/screens/383472073

Design details:

  • The wording should be: Wikipedia is available in over 300 languages. Are there other languages you read and write in? as the question wording, and with the language of the current wiki set there as default (and as a mandatory value).
  • Placeholder value in the input field is Add more languages...
  • We have decided to limit users to 10 languages. Assistive text is added that says Enter up to 10 languages.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@Pginer-WMF @Amire80 @Trizek-WMF -- would you be willing to weigh in on the wording for this question? We want to calibrate it so that people are saying the languages with which they could succeed at Content Translation.

I think the proposed wording works well from my perspective. Asking for languages you "read and write", focuses on languages the user can use to contribute and communicate which meets the general assumption I'd make about such list.

For Content translation it is recommended a good command of both languages involved and the list is expected to capture that.
The language requirement is higher for the target language compared to the source. So it is possible for a user which is able to read English well enough to get the meaning of the content to translate it into their native language. However, I still think that a shorter list with more relevant languages is better than a longer list with some results that lead to irrelevant suggestions.

MMiller_WMF updated the task description. (Show Details)Sep 13 2019, 8:47 PM
MMiller_WMF removed MMiller_WMF as the assignee of this task.Sep 17 2019, 10:58 PM
MMiller_WMF edited projects, added Growth-Team; removed Growth-Team (Current Sprint).

Thanks, @Pginer-WMF. We'll use that wording for the first version (unless others have ideas for better wording).

I'm putting this task into "Upcoming Work" to be triaged later.

MMiller_WMF moved this task from Inbox to Upcoming Work on the Growth-Team board.Sep 17 2019, 10:59 PM

@MMiller_WMF @RHo I'm assuming we want to reuse the UniversalLanguageSelector widget in terms of what the user experience is like when inputting the language name (i.e. you can type any one of "el", "Ελληνικά", or "Greek" to switch to Greek language). Then we would place user selections inside a TagMultiselectWidget with a fixed item for current wiki language. Sounds about right?

MMiller_WMF updated the task description. (Show Details)Jun 30 2020, 5:18 AM

@kostajh -- that looks fine to me, but @RHo should confirm.

RHo added a comment.Jun 30 2020, 12:18 PM

@MMiller_WMF @RHo I'm assuming we want to reuse the UniversalLanguageSelector widget in terms of what the user experience is like when inputting the language name (i.e. you can type any one of "el", "Ελληνικά", or "Greek" to switch to Greek language). Then we would place user selections inside a TagMultiselectWidget with a fixed item for current wiki language. Sounds about right?

Yes, that sounds right to me too @kostajh. However, I wanted to check whether presumably the null results message that is currently triggered in the Universal languages selector current one saying "This page is not available in the language you searched for." along with suggested languages can be excluded and replaced with a "no results found" message?

@kostajh -- that looks fine to me, but @RHo should confirm.

@RHo, yes we can override that.

To implement this feature, there are kind of a few clunky things I wanted to document here and ask for feedback on one particular item.

  1. We need to add back the API module for handling welcome survey responses, shouldn't be a big deal, but will require a bit of time to rewire the form to use it
  2. For TagMultiselectWidgets, you typically connect these with an InputWidget that seamlessly handles input from the user and feeds it into the TagMultiSelectWidget for display. However there isn't an input widget for the universal language selector (ULS) and I don't think it's worth the additional work to create one given that with OOUI deprecation and Vue migration work, both TagMultiselectWidget and probably also ULS will be rewritten.
  3. Since there isn't an InputWidget we can use, I've done a hack which loads the ULS when the user clicks on the input area. The user then sees the language picker, and when a selection is made that's fed into the TagMultiselectWidget.

@RHo where would you like the ULS input to appear? Below or above the TagMultiselectWidget? Or covering it entirely?

We need to add back the API module for handling welcome survey responses, shouldn't be a big deal, but will require a bit of time to rewire the form to use it

Oops, scratch that, we can just use a hidden form field.

@MMiller_WMF @RHo what is the maximum number of languages we will allow a user to select? They are stored as 2 character codes (plus surrounding quotes and commas, so 5 characters per language), but we probably still want to avoid allowing an unlimited selection.

Change 609430 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] WelcomeSurvey: Add language question

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

@kostajh -- we can limit it to 10 languages. I will update the task description to say so.

MMiller_WMF updated the task description. (Show Details)Jul 3 2020, 6:32 PM
RHo added a comment.Jul 6 2020, 8:30 PM

@RHo, yes we can override that.

To implement this feature, there are kind of a few clunky things I wanted to document here and ask for feedback on one particular item.

  1. We need to add back the API module for handling welcome survey responses, shouldn't be a big deal, but will require a bit of time to rewire the form to use it
  2. For TagMultiselectWidgets, you typically connect these with an InputWidget that seamlessly handles input from the user and feeds it into the TagMultiSelectWidget for display. However there isn't an input widget for the universal language selector (ULS) and I don't think it's worth the additional work to create one given that with OOUI deprecation and Vue migration work, both TagMultiselectWidget and probably also ULS will be rewritten.
  3. Since there isn't an InputWidget we can use, I've done a hack which loads the ULS when the user clicks on the input area. The user then sees the language picker, and when a selection is made that's fed into the TagMultiselectWidget.

@RHo where would you like the ULS input to appear? Below or above the TagMultiselectWidget? Or covering it entirely?

hi @kostajh - is it possible for it to be triggered over the input part of the TagMultiselectWidget only on Desktop like the below image?

And for Mobile, would this presumably be a bit different since the mobile users currently use Special:Mobilelanguages instead of the ULS? How much effort would it be so that in the mobile version, tapping inside the input to add more languages triggers the ULS in a fullscreen dialog that is like the following:

hi @kostajh - is it possible for it to be triggered over the input part of the TagMultiselectWidget only on Desktop like the below image?

Yeah, that sounds good! Do you want the languages to appear in a single column or in two columns?

And for Mobile, would this presumably be a bit different since the mobile users currently use Special:Mobilelanguages instead of the ULS? How much effort would it be so that in the mobile version, tapping inside the input to add more languages triggers the ULS in a fullscreen dialog that is like the following:

Ah, good idea! I think that should be doable. I'll try it and see.

Change 610037 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/MobileFrontend@master] [WIP] Add generic LanguageSearcher / LanguageOverlay

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

Change 610037 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/MobileFrontend@master] Add languageinfo searcher and overlay

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

RHo added a comment.Jul 8 2020, 8:53 AM

hi @kostajh - is it possible for it to be triggered over the input part of the TagMultiselectWidget only on Desktop like the below image?

Yeah, that sounds good! Do you want the languages to appear in a single column or in two columns?

Cool. I think one column works better when it is in this form menu context, and likely better for i18n and consistency with mobile too. (Plus being able to filter by searching should mean not much scrolling required.)

hi @kostajh - is it possible for it to be triggered over the input part of the TagMultiselectWidget only on Desktop like the below image?

Yeah, that sounds good! Do you want the languages to appear in a single column or in two columns?

Cool. I think one column works better when it is in this form menu context, and likely better for i18n and consistency with mobile too. (Plus being able to filter by searching should mean not much scrolling required.)

Bah, unfortunately this doesn't seem straightforward to do with the jQuery ULS widget so I suggest we leave it as two columns; otherwise we will need to submit an upstream patch to jquery.uls. If it seems important we could create a task for it and put it in the queue of future improvements.

Also, it might take a little while to get my patch for MobileFrontend approved in order to use the language overlay, so for now my patch uses the jQuery ULS widget on mobile as well. If/when the MobileFrontend patch is merged, the code will start using the language searcher overlay on mobile instead of jQuery ULS. It's also possible to reimplement the language overlay in GrowthExperiments so we wouldn't have to coordinate with MobileFrontend, but it would require more effort and I'd like to see if the patch can get merged into MobileFrontend for maintainability reasons.

Change 613591 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/skins/MinervaNeue@master] Add languages/all route for LanguageInfo overlay

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

Note: we want this to be deployed on the August 4 train, and not sooner. Therefore, we would like to merge this on July 28 so that it can spend time in beta labs.

Change 610037 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Add languageinfo searcher and overlay

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

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

SBisson removed a subscriber: SBisson.Wed, Jul 29, 12:09 AM

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"


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.

(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.


(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)

(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.

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

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.

RHo added a comment.Wed, Jul 29, 7:49 PM

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.

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?
RHo added a comment.Thu, Jul 30, 4:07 PM

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

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).


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.

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.

  • 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.

RHo updated the task description. (Show Details)Fri, Jul 31, 12:04 PM
RHo added a comment.Fri, Jul 31, 3:32 PM

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.

[..]
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.

  • 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.

  • 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

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

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).

RHo added a comment.Tue, Aug 4, 9:57 AM

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?


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

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

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.)

RHo added a comment.Wed, Aug 5, 10:03 AM

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:

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:

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.

Tgr added a comment.Wed, Aug 5, 1:28 PM

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.

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 :)

MMiller_WMF added a comment.EditedWed, Aug 5, 3:45 PM

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.

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

@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.

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?

RHo added a comment.Thu, Aug 6, 10:19 AM

@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

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?

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

Etonkovidova added a comment.EditedThu, Aug 6, 8:33 PM

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 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.

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.

RHo added a comment.Fri, Aug 7, 9:07 AM

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!

Tgr added a comment.Fri, Aug 7, 1:15 PM

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

Etonkovidova added a comment.EditedFri, Aug 7, 9:49 PM

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


Still, the contrast ratio is problematic.