Page MenuHomePhabricator

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

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

Related Gerrit Patches:
mediawiki/extensions/MobileFrontend : masterRestore legacy language overlay sort order
mediawiki/extensions/MobileFrontend : masterDo not bundle languages into subgroups
mediawiki/extensions/MobileFrontend : masterLanguageOverlay: send the correct position tapped value for EventLogging

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 20 2016, 3:15 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.

bmansurov added subscribers: phuedx, jhobs.EditedMar 22 2016, 8:30 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.

bmansurov added a comment.EditedMar 23 2016, 6:21 PM

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

@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.
dr0ptp4kt added a comment.EditedMar 23 2016, 7:35 PM

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

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.

Change 279262 had a related patch set uploaded (by Bmansurov):
LanguageOverlay: send the correct position tapped value for EventLogging

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

I'm blocking this task on fixing T130798

Change 279262 merged by jenkins-bot:
LanguageOverlay: send the correct position tapped value for EventLogging

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

dr0ptp4kt updated the task description. (Show Details)Mar 25 2016, 7:28 PM

Change 279166 merged by jenkins-bot:
Do not bundle languages into subgroups

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

Change 279259 merged by jenkins-bot:
Restore legacy language overlay sort order

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

bmansurov removed bmansurov as the assignee of this task.Mar 25 2016, 8:37 PM
bmansurov added a subscriber: bmansurov.

@bmansurov which URL(s) can I use to confirm?

@bmansurov I should clarify - curious for both the UX and the event logging confirmation.

dr0ptp4kt closed this task as Resolved.Mar 28 2016, 7:57 PM
dr0ptp4kt claimed this task.

Signing off.

Moving to done column to truly sign this off.