Structured language overlay language ordering has too many intermingled character sets
Closed, ResolvedPublic
Actions

Description

The sorting algorithm for the new language overlay intermingles too many vastly different looking character sets in too close of proximity. This hampers ease of use and familiarity despite the enhanced visual hierarchy, and additionally appears to be related to the incorrect tappos value being sent to Event Logging (it is almost always equal to the full length of the list, which is nonsensical).

Acceptance criteria

Restore legacy sort order, maintaining new aesthetic
Ensure correct tappos value is conveyed based on the actual position of the language at the time it is tapped. (e.g., if it is is second in the prioritized list, it should be 2; if there are no prioritized languages and it's the ninth in the all language list it should be 9; if there are two languages in the prioritized list but the third list in all languages is tapped it should be 5; if a search filter reduces the set of languages to three and the second element is tapped it should be 2; and so on).

Legacy version, applying ASCIIbetical sort to language names

New version, applying ASCIIbetical sort to ISO codes

UX wise the point is to largely reinstate the ordering from the legacy version, but have the aesthetic (including preferred versus all hierarchy) and keyboard heuristic of the new version.

Details

Project	Branch	Lines +/-	Subject
mediawiki/extensions/MobileFrontend	master	+30 -30	Restore legacy language overlay sort order
mediawiki/extensions/MobileFrontend	master	+74 -186	Do not bundle languages into subgroups
mediawiki/extensions/MobileFrontend	master	+4 -4	LanguageOverlay: send the correct position tapped value for EventLogging

Customize query in gerrit

Related Objects
Search...

Status	Assigned	Task
Resolved	JKatzWMF	T121919 [GOAL] Improve in-article language switching on mobile web I
Resolved	dr0ptp4kt	T129274 Ship mobile web structured language modal overlay
Resolved	dr0ptp4kt	T130476 Structured language overlay language ordering has too many intermingled character sets
Resolved	bmansurov	T130798 Variants have disappeared from language switcher

Event Timeline

dr0ptp4kt created this task.Mar 20 2016, 3:15 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 20 2016, 3:15 AM

dr0ptp4kt added a parent task: T121919: [GOAL] Improve in-article language switching on mobile web I.Mar 20 2016, 3:17 AM

dr0ptp4kt updated the task description. (Show Details)Mar 20 2016, 3:27 AM

dr0ptp4kt updated the task description. (Show Details)Mar 20 2016, 3:33 AM

dr0ptp4kt updated the task description. (Show Details)

dr0ptp4kt renamed this task from New language overlay language ordering too different to Structured language overlay language ordering has too many intermingled character sets.Mar 20 2016, 3:35 AM

dr0ptp4kt updated the task description. (Show Details)

@Nirzar, should we ignore casing for Latinized language names? For example, should "italiano" actually come before "Tagalog"? Uppercase is trumping lowercase in the legacy overlay.

Also, when there are language groupings in the all-languages area, I'm assuming we'd want the high level grouping to the be the thing which gets ASCIIbetically sorted against all languages (as usual, any specific variant that is part of preferred langs is solely added to preferred langs).

dr0ptp4kt updated the task description. (Show Details)Mar 22 2016, 11:47 AM

dr0ptp4kt updated the task description. (Show Details)

Myself and @Nirzar had lots of questions around the data we are seeing, we'd like to understand how this impacts usability.

@dr0ptp4kt says that search usage is low but it's not clear what that is relative to. Is that due to people using preferred languages more? Is this a bad thing? If people are not using search should we remove the feature/improve the feature and optimise the list we give.

• jhobs triaged this task as High priority.Mar 22 2016, 5:10 PM

• jhobs added a project: Reading-Web-Sprint-68-"Java and JavaScript are basically the same".

dr0ptp4kt assigned this task to bmansurov.Mar 22 2016, 6:26 PM

dr0ptp4kt updated the task description. (Show Details)

dr0ptp4kt removed a project: Reading-Web-Sprint-69-K-Phab-and-the-Kurious-Koders-mmKay.

dr0ptp4kt added a parent task: T129274: Ship mobile web structured language modal overlay.Mar 22 2016, 6:28 PM

bmansurov moved this task from Needs Analysis to Doing on the Reading-Web-Sprint-68-"Java and JavaScript are basically the same" board.Mar 22 2016, 7:04 PM

So I have two variants of ZH on a page: "zh-min-nan" and "zh-yue". Their names are "Bân-lâm-gú" and "粵語" respectively. They are grouped under the same parent (see the screenshot). The parent language (general language) is not displayed because the page doesn't exist in that language). If we wanted to get the parent language name we'd have to make another request (or maybe multiple requests) to the API, which doesn't seem like a good way to move forward.

@dr0ptp4kt @Jdlrobson @jhobs @phuedx how do you think we should handle this problem? Should we sort by the language code of the parent language? Should we use the first variant name for sorting? Anything else?

Never mind, I think I've found that the API returns the data we need.

I agree, don't make another API call.

I suggest sorting on langname and doing away with the parent language notion.

I suggest sorting on langname and doing away with the parent language notion.

How can I do so when variants are grouped together?

Change 279166 had a related patch set uploaded (by Bmansurov):
Restore legacy langauge overlay sort order

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

gerritbot added a project: Patch-For-Review.Mar 23 2016, 6:56 PM

bmansurov moved this task from Doing to Code Review on the Reading-Web-Sprint-68-"Java and JavaScript are basically the same" board.Mar 23 2016, 6:57 PM

bmansurov moved this task from Code Review to Doing on the Reading-Web-Sprint-68-"Java and JavaScript are basically the same" board.Mar 23 2016, 7:16 PM

@Nirzar, should we keep the language grouping for the (relatively small) set of languages where there's a parent language, or should we split them up lexicographically? Using the screenshot from @bmansurov:

The former would mean that all of the Chinese languages are at the end of the list.
The latter would would mean Ban-Lam-Gu would be early in the list without a parent, and the Chinese glyphs would be toward the end of the list, also without parents.

@Nirzar, @bmansurov, and I chatted and we'll return to the legacy sort order, not bundling variants together under one subheading.

bmansurov updated the task description. (Show Details)Mar 23 2016, 8:34 PM

@Jdlrobson I'd appreciate a code review so that we can fix any remaining issues and SWAT deploy the patch tomorrow morning.

bmansurov moved this task from Doing to Code Review on the Reading-Web-Sprint-68-"Java and JavaScript are basically the same" board.Mar 23 2016, 9:14 PM

Change 279259 had a related patch set uploaded (by Bmansurov):
Restore legacy language overlay sort order

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

Following up with a little more context:

Removal of the parent-child variant, in addition to the more general restoration of the sort order, restores the legacy sort order for all-langs, slightly more conservative than restoring the general sort order but keeping the parent-child nesting.
The parent-child determination was being derived synthetically client side, rather than from a validated server source.