Repurposed for an iOS specific card.

Related to: T87154

Do not start until after hackathon - waiting for the initial Android implementation

Here are two options for switching language while searching.
(ignore the cancel button, that was something i was experimenting with)

but there will be horizontal scroll of languages to choose from.

Both have horizontal scroll of list of languages to choose from. obviously there shouldn't be a zero results case for this. if the article doesn't exist in language x then language x shouldn't be part of this horizontal list.

The order of this list based on the user preferences for languages and also the existence of this feature is for multi lingual users. that's another question for us. how to determine if the user is multi lingual

@JMinor

@Nirzar @JMinor
The horizontal scrolling list should be limited to around 6-7ish and then a "More" button that will open a modal list - sometimes there can be over 100 languages!

First design is easier to see but I prefer 2nd design. Location is out of the way but still easily accessible.

@JMinor let's go with Variation 1 because the keyboard conflict might come up in the usability test.
should I move it to needs acceptance?

Will move. I like 2 better visually, but think 1 makes more "sense" in terms of how those elements are used in the OS.

@JMinor cool

@Nirzar @JMinor i recommend re-evaluating this picker design before moving forward.

Looking at the proposed design, the following issues stand out:

1. Scrolling to the language you want is pretty difficult. You can only see a few at a time and since you are limited by the width of the phone you may need to scroll very far to get to the language @KHammerstein mentioned.
2. On version one, the language picker is cramped between 2 common actions - tapping the search bar and tapping the first result - this will result in accidental taps.
3. On version two, the language picker is cramped between 2 other common actions - tapping a result and the keyboard. Additionally not depicted is the suggestion bar that is above the keyboard since iOS 7 which cramps area even more.
4. (A more minor point) In both versions it takes up vertical space that would otherwise be used to display an additional result.

Compare this to the existing language picker:

1. There are no issues with efficiently finding a language, either by scrolling or by searching.
2. There are no issues with tap area - if a user wants to change the language, we use the entire screen and provide the appropriate amount of room to perform the action.
3. It is already built. (In fact we just built it a few months ago - it was the last feature we added to the legacy app)
4. We could incorporate it in about an hour by simply adding the language button to the search bar.
5. This language picker uses the newly developed design language of Wikipedia for selecting languages.

If we want to test out new language picker UX, then seems like something we should do with prototypes.

Since we have a working, modern styled implementation with all the advantages listed above, and we are on a tight schedule, it seems more pragmatic to make the minor tweaks to get it working, and invest the time we would spend on developing a new solution on higher priority work.

Thanks @Fjalapeno for the thoughtful feedback.

I'll let @Nirzar address specific tradeoffs, but just want to be clear this is just a couple proposed solutions. I'd be glad to use the existing language picker if we can find a good affordance and indicator within the current search bar. We're trying to move design alternatives/discussions earlier in the process so we can consider multiple alternatives as a group rather than water-falling from spec->mock->build, but doing that over phab ain't easy...

@Fjalapeno hey...

i think there is a misunderstanding with this. this picker is not supposed to replace the current language picker. this interface is just supposed to expose the current language picker modal window.

Here's the model that i am trying to propose.

you have a result set when you search something. you want to give a way for the user to browse multiple result sets.
in our case multiple result sets are "different languages"

In case of instagram here > the multiple result sets are "people, hashtags,photos"

In iTunes app here > the multiple result sets are "different kinds of content" books, songs ,video

one more example of browsing result sets

this is very similar to the android implementation we have where you get a "EN" button next search which let's you go to the traditional language picker. the only difference is i am exposing some languages upfront. this improves visibility and encourages people to use this feature. (same hamburger menu vs. tabbar case)

There can be a more button in that stack which will show you the traditional language picker.

Does this explanation help?

@JMinor @Fjalapeno after last discussion of being sticky or not. i updated the treatment to make sure the language bar looks sticky and doesn't scroll with the results

Sorry about this change. I should have taken care of that detail earlier.

@Nirzar

In addition to having to deal with long lang names better (so the buttons don't appear to bleed together) we'll need to figure out how to handle mixed script language names, because it is trickier to just truncate these without potentially losing too much meaning, and these have the additional problem of looking like 2 separate languages if the button has no defined border...

Checked with 5.0.0.519 on iPad mini iOS 8.2

• three languages that are displayed - they were the languages between which I switched during reading articles or changing wiki search lang
• the language toolbar is sticky -does not scroll down
• after viewing what was found in a different language and performing some search later - the preferred language returns to the wiki app search lang