Page MenuHomePhabricator

Language selection should use native selector on mobile
Closed, ResolvedPublic8 Estimated Story Points


The previous language picker is a <select> element and the mobile uses the native selector which provides a nice user experience.

The new language is JS-based and uses a styled <ul> list instead of a <select> and renders the same way on desktop and mobile.
We should find a hack or change the implementation so that the new language picker uses the native mobile selector instead of displaying a small dropdown hard to manipulate.

Event Timeline

JGirault raised the priority of this task from to High.
JGirault updated the task description. (Show Details)

I don't know of any other way to show that 'scroll-wheel' interface on mobile other
than to use an actual <select> element.

However, the select element doesn't necessarily have to be ugly.
It is possible to style the <select> element itself, just not the <option> elements within it.

This is an example:

Doing something that targets mobile devices specifically is also a no-go, since
our page is responsive and serves the same experience to desktop.

If we implement a an <select> element, we'll have to use that on desktop as well :/

That would mean getting rid of the custom <ul> and the styling that goes along with it...

debt lowered the priority of this task from High to Medium.Feb 4 2016, 12:21 AM
debt set Security to None.

Do we have the ability to detect if the user is on a desktop or mobile device? If so, then let's see if we can use the custom <ul> for desktop and a stylized <select> for mobile device users.

We do on the varnish caches, at least.

I started investigating different options, but all of them look like a no-go.
There are plugins like that have an acceptable mobile detection and support native selector on mobile.
But this would require jQuery on the page, + this plugin, and I am not sure this is worth the overload.

We can make our own plugin/hack, but this will obviously take time, and the cross-browser fit-and-finish might kill us.

As of today, I think @Jdrewniak suggestion is the best.

In terms of UIUX, what I think is:

  • the native selector greatly improves the UX on mobile (compare to the custom dropdown)
  • the custom dropdown does not greatly improve the UX on desktop (compare to the native <select> element)

Based on that, I would suggest we go for the big buck, i.e.: using a decorated <select> element.

One issue that this approach has, is the fact that selected value will be displayed, instead of its language code.
e.g.: We would show "English", instead of "EN".

I started working on a quick prototype. Meanwhile I recommend nobody starts working on T126052

debt edited a custom field.

Change 274332 had a related patch set uploaded (by JGirault):
Replace the custom dropdown with a native <select> element.

Latest update:
We have two concurrent patches.

I think I'm pretty satisfied with the second patch.
Please leave comments.

great! it's worth noting that the JS-based patch builds on top of the first patch, so users without JS will still get the 'better than standard select input' experience.

Change 274681 had a related patch set uploaded (by JGirault):
Replace the custom dropdown with a native <select> element.

Change 274332 merged by jenkins-bot:
Replace the custom dropdown with a native <select> element.

Change 274681 merged by jenkins-bot:
Replace the custom dropdown with a native <select> element.


We developed a JavaScript-only version of the language picker, on top of the previous patch, so that users who have JS enabled (93% of our traffic) get a nicer version of the language picker.

  • Shorter language code is displayed, allowing more space for text within the search input.
  • Triggers the native selector on mobile devices.
  • The search box looks better overall.

Users who disable JavaScript, or are using old IE versions, only get a styled native selector.

Some screenshots:

Modern browsers:

IE browsers:

Note: the CSS for the suggestions needs some attention, currently seeing weird padding.

Mobile browsers:

Follow deployment in Epic T125472

Closing this - looking good!