I must admit - whoever wrote these lines is a great poet:

The classic funnel example of better experience then more people vs more people then better experience.

For e.g. I would invite my friends over for a house-warming party once I have the necessary things in the house for them to have a good experience.

^ Great allegory that I don't quite understand.

@bmansurov I wrote those

It means you need to make the experience better before making the entry to that experience prominent. we are planning to make the language switcher prominent ( sticky footer or otherwise) so effect of that will be more people seeing language overlay. we need to fix language overlay first before making language switcher prominent.

(this is one of the reasons, not the only primary reason for doing this task)

does that answer your question?

@Nirzar, thanks, it does. Don't get me wrong - it wasn't that unclear. I just liked the way it was described and wanted to point it out. ;)

@bmansurov no no.. I was very skeptical while writing that example too :)

@Nirzar, do you think we should right align the right-to-left languages?

@bmansurov technical we should because we use the script of the other language to represent it so writing language should also be used. but that will break the layout. Specially when you are scanning the list.

Maybe the same reason we dont do that right now?

I don't know why we don't do that right now. If I was looking for arabic, I think it would be easier if arabic was aligned to the right.

@bmansurov @Nirzar see T66617

Specifically https://phabricator.wikimedia.org/T66617#696468 and blocking task T74153

@Jdlrobson that is really helpful

@bmansurov let's not add that as a blocking task for this but track that somehow?

@Nirzar, it's already tracked in the above task.

Questions:

1. How should I display a variant of a language when it's in the preferred languages section? Should I display its parent too? Or just the variant?

2. Should filtering filter both the preferred list and the 'all' list?

3. Could you upload some mock-ups for tablet size devices?

4. Do all languages also include the preferred languages? Or should those be excluded from the all list?

5. In the above screenshot, all languages except the one with variants show the language and the article title. In the ZH language and its variants there's only one line (and I suppose that's the title of the article?). If so, don't we have to also show the language name?

@bmansurov Your questions made me question the nested design I was proposing. after thinking thoroughly, I realized the nested structure, which explains the parent-child relationship nicely, isn't the best way to represent this because it creates problems you mentioned.

Apologies, but I have to change how the nested languages look and make them look exactly like the other languages. this solves all the problems you have mentioned.

How should I display a variant of a language when it's in the preferred languages section? Should I display its parent too? Or just the variant?

The code will have the parent code. the name will be the variant, refer this for more information

Should filtering filter both the preferred list and the 'all' list?

Yes

Could you upload some mock-ups for tablet size devices?

Here >

Do all languages also include the preferred languages? Or should those be excluded from the all list?

Excluded, one instance of the language in the whole list

In the above screenshot, all languages except the one with variants show the language and the article title. In the ZH language and its variants there's only one line (and I suppose that's the title of the article?). If so, don't we have to also show the language name?

The reference name explains this too.

Again, sorry for not catching this earlier but i am hoping this will reduce some work on making the tree structure in CSS.

@Nirzar, I'm trying to extract the colors from the mock-ups, but they don't conform to one of the shades of grey that we use. Should I keep using your colors, or should we pick from the following?

@colorGray1: #111; // darkest
@colorGray2: #222;
@colorGray3: #333;
@colorGray4: #444;
@colorGray5: #555;
@colorGray6: #666;
@colorGray7: #777;
@colorGray8: #888;
@colorGray9: #999;
@colorGray10: #aaa;
@colorGray11: #bbb;
@colorGray12: #ccc;
@colorGray13: #ddd;
@colorGray14: #eee;
@colorGray15: #f9f9f9; // lightest

Also:

• All other overlays have white background. Wouldn't a grey background look inconsistent?
• Displaying "4 variants of XYZ" may not be feasible because we'll have to fetch a translation for each set of variants in a native language and it may delay the loading of the overlay. Besides, assume there are 2 variants and one of them is in the preferred list of languages, now we'll have a heading and only one variant in the all list. For these reasons, I think it maybe best to omit that heading and just separate variants from the rest of all languages with a think border like in your initial mock-ups. What do you say?
• Do we just show a blank space if no results are found? Should there be a text instead?

Change 268036 had a related patch set uploaded (by Bmansurov):
New language overlay

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

Use the following grays

@colorGray14 for background
@colorGray9 for language code box background
@colorGray9 for the article name in different languages. "cat" in above examples

All other overlays have white background. Wouldn't a grey background look inconsistent?

We use grays for base and white for cells to pop out. it wont strike out as very different. this is a subtle difference we want to have in all places we use lists.

Displaying "4 variants of XYZ" may not be feasible because we'll have to fetch a translation for each set of variants in a native language and it may delay the loading of the overlay. Besides, assume there are 2 variants and one of them is in the preferred list of languages, now we'll have a heading and only one variant in the all list. For these reasons, I think it maybe best to omit that heading and just separate variants from the rest of all languages with a think border like in your initial mock-ups. What do you say?

I used google translate on what it actually says in production and it says 4 variants in XYZ. maybe they have already taken care of it?

Do we just show a blank space if no results are found? Should there be a text instead?

isn't the button "read in other language" not present if the article is available in only one language? how will the user arrive at a blank state?

@Nirzar,

I used google translate on what it actually says in production and it says 4 variants in XYZ. maybe they have already taken care of it?

Where in production can I see this?

isn't the button "read in other language" not present if the article is available in only one language? how will the user arrive at a blank state?

Yes, but I mean when searching for a language. When a user starts filtering out languages and no results are found, do we show a blank overlay or some text?

@Nirzar, could you answer the questions above? Also, You can see the current implementation here: http://reading-web-staging.wmflabs.org/wiki/Lang#/languages

Unfortunately, there is only one language in there. I'll need some time to add more. If you want we can do a quick session where I could share my screen with more languages.

Where in production can I see this?

https://zh.m.wikipedia.org/w/index.php?title=%E5%85%AD%E5%9B%9B%E4%BA%8B%E4%BB%B6&mobileaction=toggle_view_mobile#/languages

i used google translate to translate the headers

Yes, but I mean when searching for a language. When a user starts filtering out languages and no results are found, do we show a blank overlay or some text?

Yes, we can show a text in the middle of the blank screen while searching.

Also, You can see the current implementation here: http://reading-web-staging.wmflabs.org/wiki/Lang#/languages

CSS fixes

.language-overlay .site-link-list a {
       padding: 0.75em 1em;
}

.language-overlay .site-link-list a div span {
   font-size:0.9em;
}
.language-overlay .site-link-list a div span:first-child {
   font-weight:bold;
}

.language-overlay .site-link-list a div span {
   letter-spacing:1px;
   padding:0.5em;
   min-width:3.2em;
   margin-right:0.75em;
}
.language-overlay .list-header {
   font-family:sans-serif;
   letter-spacing:1px;
}
.language-overlay input.search {
  background-size:24px 24px;
  background-position:0px 0px;
}

https://zh.m.wikipedia.org/w/index.php?title=%E5%85%AD%E5%9B%9B%E4%BA%8B%E4%BB%B6&mobileaction=toggle_view_mobile#/languages

This is a different situation because it's only used to group all languages. Imagine a scenario where we have 5 languages with 2 variants each. We would have to pull translations for those languages that reads "2 variants". So I think it's best to omit the heading for variants. Just visually separating them from the rest of the languages should be enough for now.

@bmansurov can we have just the title for the parent language as the header?

@Nirzar, sure, and make it clickable right? Also what happens when the parent is in the list of preferred languages? Should the variants still show the parent in the header but this time the header is not clickable?

@bmansurov headers are not clickable. what would the click do? also if the language was selected, it would just appear in the preferred exactly as any other language. without any headers since it already has a preferred header

While I was testing 268036, I tested that the "Preferred languages" feature was still functioning. I tapped on of the variants of the language so that they'd be, effectively, disconnected from the "parent" language.

@Nirzar: First and foremost, this is an edge case. I think that the behaviour is correct (see the screenshot above) is correct but I wanted to make sure that you were aware that it might happen.

268036 has been -1'd by @siebrand. I'll still be re-reviewing/testing though.

I've added more tests per Sam's suggestion, but I'm waiting for @siebrand's reply. If anyone else feels like reviewing the patch, please go ahead and do so.

@Jhernandez, what's a good date to have this in mobile web beta (prod cluster) for your field research?

Not trying to rush anything here, but do want to factor that in.

I'm not really sure, but we'll be in the field from the 14th to the 25th of feb.

I'll send an email to see when we would have slots to test it and report back.

I've changed the heading case to sentence case per @Jdlrobson's suggestion. The patch is good for review.

The patch is merged but will not show up on beta labs as it is disabled by default. Not sure why we didn't ask to put this into beta but I guess we're doing this next sprint. Thus not sure how best you want to sign off.

Over to you @dr0ptp4kt and @Nirzar

@Jdlrobson @bmansurov yay! let's wait and figure out how PO and design and see the changes? or if there is work needed to see them. i would like to see this on beta because of the number of languages available on wikipedia vs. staging.

Enabling it in beta mode won't take too much effort. We could aim to do so and you'll be able to see the change next Thursday. Alternatively, we could spend some time adding more languages to the staging environment.

@bmansurov i believe you just need to update the interwiki table on the staging environment

The question is in which one of the databases? I'll do so tomorrow.

I've enabled the interwiki role on the staging server. You can now add interlanguage prefixes via Special:Interwiki.

I've added the following interlanguage prefixes: zh, zh-classical, and zh-hans; and added interlanguage links to Selenium_language_test_page.

@Nirzar, @dr0ptp4kt: You can see the new language overlay in action here: http://reading-web-staging.wmflabs.org/wiki/Selenium_language_test_page?useformat=mobile

Change 268036 merged by jenkins-bot:
New language overlay

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

@dr0ptp4kt I've talked with the research team and it seems like the best candidates for testing it are the expert interviews on Monday 15th, which we're not going to make it.

If it is deployed to beta labs we can try and test it there, otherwise after it is deployed to en wiki we can try and do some guerrilla testing in some cafes the next week (22nd to 25th).

Send me an email when it is available somewhere and I'll inform the team.

If the user types "classical" or "hans" into the search field, those variants aren't shown in the list. Is that desired?

If "zh" is typed, one sees options as follows:

zh
zh-classical
zh-hans

But if "zh-c" is typed the list becomes empty. Is that desired?

Also, is it desired to have the prefix of "zh-" when in typeahead mode but not have it shown by default when not in typeahead mode? Understood, the section label indicates "N variants for <lang>", was wondering if there's any harm in just having the prefixes for those variants for their rectangular labels anyway.

It seems the parenthetical to the right of the language name, for example in the case of "ES Español" there isn't a "(Spanish)" following it. Is that desired? (I do see a parenthetical for the HANS entry but I think that parenthetical is actually part of the legitimate language name, not the additional affordance, which might say "(Chinese Simplified)").

I think one motivation of the language code labels ("EN", "ES", "ZH", etc.) was for better typeahead. It's unclear to me yet whether by having those labels the obviousness of the search box at the top of the modal will improve. As I just noted in T125127#2018650 the search interaction for the existing "legacy" modal seems pretty paltry at the moment. The users who tap on the modal are those we assume are genuinely interested in tapping through, which is bore out by a nontrivial amount of tap through, so we have supposed that they would be interested in the search capability. Do we want to try to improve the obviousness of the search box being a search box somehow? Or do we want to try this modal as is with the current search box graphical design and see if there's an upswing in search usage anyway? If we go with the latter of sticking with the current graphical design of the search box tappable area, and yet search engagement doesn't improve, I wonder if we'd then want to consider removing the search box altogether, and then also possibly the language code labels (unless they confer some other sort of intangible benefit).

Change 270047 had a related patch set uploaded (by Bmansurov):
Structured language overlay filtering fix

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

I've fixed the search in the above patch. I don't know how to get translations for each language from the API. Does anyone know if that's possible? cc @Jdlrobson, @phuedx?

@Nirzar can you answer the design related questions?

In T123384#2018661, @dr0ptp4kt wrote:

If the user types "classical" or "hans" into the search field, those variants aren't shown in the list. Is that desired?

If "zh" is typed, one sees options as follows:

zh
zh-classical
zh-hans

But if "zh-c" is typed the list becomes empty. Is that desired?

I'm not sure which use case this will solve. These codes are mostly meaningless outside developer circles/people that understand ISO 639-3 codes. We'd need data to know if there was a problem.

Also, is it desired to have the prefix of "zh-" when in typeahead mode but not have it shown by default when not in typeahead mode? Understood, the section label indicates "N variants for <lang>", was wondering if there's any harm in just having the prefixes for those variants for their rectangular labels anyway.

It seems the parenthetical to the right of the language name, for example in the case of "ES Español" there isn't a "(Spanish)" following it. Is that desired? (I do see a parenthetical for the HANS entry but I think that parenthetical is actually part of the legitimate language name, not the additional affordance, which might say "(Chinese Simplified)").

We don't know as we don't have data. I would not block this work until we have that data.
Technically this is also difficult/impossible.

I think one motivation of the language code labels ("EN", "ES", "ZH", etc.) was for better typeahead. It's unclear to me yet whether by having those labels the obviousness of the search box at the top of the modal will improve.

Then we should wait till we have strong data to tell us one way or another.

As I just noted in T125127#2018650 the search interaction for the existing "legacy" modal seems pretty paltry at the moment. The users who tap on the modal are those we assume are genuinely interested in tapping through, which is bore out by a nontrivial amount of tap through, so we have supposed that they would be interested in the search capability. Do we want to try to improve the obviousness of the search box being a search box somehow? Or do we want to try this modal as is with the current search box graphical design and see if there's an upswing in search usage anyway? If we go with the latter of sticking with the current graphical design of the search box tappable area, and yet search engagement doesn't improve, I wonder if we'd then want to consider removing the search box altogether, and then also possibly the language code labels (unless they confer some other sort of intangible benefit).

I've merged @bmansurov's patch and I can see no reason not to sign this off. The original requests in the description have been met.

@bmansurov which one exactly, this seems to have evolved into a complex conversation.

May I suggest filing any new bugs as subtasks. As @Nirzar suggests this conversation is now impossible to follow.

https://gerrit.wikimedia.org/r/#/c/270047/ needs a review. It fixes the bug Adam reported.

Change 270047 merged by jenkins-bot:
Structured language overlay filtering fix

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

Over to you @Nirzar and @dr0ptp4kt.

The search type ahead looks good. I apologize I didn't see this earlier, but when my language is es-xl I expect that ES will be on preferred langs. @Nirzar can you confirm that's what you'd expect, and @bmansurov if so can you make the root language before the hyphen become a preferred language when the more specific variant isn't present yet the more general one is available?

As per email discussion, I've created T126868: In mobile language switcher prioritize available general language if user's specific client side variant isn't available and tagged it for sprint 66.

Consider this my signoff on this task. @Nirzar, do you sign off on this task?

Signed off from design