Gentle ping... any ETA for this being worked on? Thanks a lot, Alex

@bearND is proposing to work on this task at the Wikimedia-Hackathon-2015. Just checking, is this task proposed as the main activity for Mobile Apps - Android in Lyon or are there other tasks?

If we look for local Android developers willing to participate at the hackathon, we might find them. See T88274: Promote GSoC, FOSS OPW, and Wikimedia Hackathon in France and related tasks.

@Qgil This task is mainly blocked because of UX reasons and, with the Language Engineering Team being at the Hackathon, we could spend some time unblocking it. I doubt it makes sense to call it the "main activity" for the team.

For what is worth, it seems that the Language Engineering Team at large is focusing in Wikimania instead. Unless you are thinking of a specific UX designer planning to be in Lyon.

Well, we can still brainstorm and sprint on it ourselves with any of the
Language Engineering Team that are there and interested, then solicit
feedback from the larger Language Engineering Team later. Given our other
commitments, finding the time to do the UX brainstorming has been the major
blocker, and the Hackathon is ideal for that.

This was not meant to be the main task for the whole team, just for myself and whoever would like to be my Hackathon buddy (volunteers, anyone?). I just picked this task as part of the registration process to the Hackathon since this is a requirement to have a link to a task and it addresses one of the pain points I'd like to see solved. This doesn't preclude anyone else picking this one as well. And if we happen to solve it earlier then I'll happily pick another task. I was also eying T62743, which is another I18n task. I probably won't be at Wikimania this year, and frankly I don't want to wait that long to get those fixed.

As @Qgil wrote, most of the Language team people probably won't be at Lyon, although some might be. But why wait for Lyon when we are available on IRC and Hangout every day? :)

I CCed Pau, who may have a chance to find some time to think of a good design for this.

I have taken a look at the information from the description (I don't have an OTRS account) and I'm not sure what this is about.

I'm happy to provide some design feedback here, but I need more context. Some ideas of context information that would be really helpful here:

• Description of the problem to be solved.
• Screenshots of the current state.
• Aspects that are desirable for the solution in the form of generic scenarios (e.g., for bilingual users is common to first search in their local language and then use English if they don't find what they are looking for) or specific behaviours expected to be supported (e.g., we want to make it really fast to switch between the few languages each user knows).

FWIW ...

Problem description:
The problem we want to solve is to make the use of the Wikipedia app (Android) more convenient for multi-lingual people.

Current state:
Today, if you switch the Wikipedia language often, when you open the Wikipedia app, you usually don't even know what's the currently selected Wikipedia language. To check it or to change it you have to do many clicks on the phone. (Sandwich menu -> More > Wikipedia language > Click on new language > Back)

Desirable solution:
I think making language switching very fast would be the easiest to implement. AFAIR, one of the idea was to bring up the standard Wikipedia language selector with a long press in the search bar, which would save 3 clicks for showing or changing the language. (Provided that the recently selected languages are at the top of the list, as it is already today.)

Searching in more than one preselected languages is something Wikipanion on iOS offers, where you can define a "default language" and multiple "retry languages". If the default search ist not successful you can tap on any of the retry languages.
I think this is much harder to implement, as you need the UI in place for selecting the various languages, etc.

Thanks!

Thanks for the details, @AlexLippert.

The long press on search could work as a shortcut but it is not very discoverable as a regular mechanism to use.
Below I provide some ideas based on the following scenarios:

1. *Switching the article language.* The user is reading the "leg" article in English and wants to quickly switch to Catalan because there are some anatomy terms he is not familiar reading in English.
2. *Changing the language of search results.* The user tries to search for "cama" (Catalan for "leg", but also Spanish for "bed") without realising that he is searching in English, he does not get the expected results and wants to get the results for Catalan.

Switching the article language

We could represent the current page in the initial state of the search view with quick options to switch to your usual languages (and an additional "more" option to get to the rest). In the mockup below, the user just taped search from the "leg" article and can easily switch to the Spanish version since is his frequent used language.

Changing the language of search results.

To facilitate searching in another language without abandoning the search results, an option to expand the search bar into an advanced search panel can be helpful. There we can provide a quick option to switch to the user most frequent languages. the advanced search panel can include more search-related options in the future. For extra speed, a long tap in the search field could lead to the search view with the advanced search panel.

I created a prototype to illustrate the idea (you can check the video illustrating its use).

The above solution relies on the user identifying that the search results are in the wrong language by looking at those. To make the current search language more prominent, it can become par of the search placeholder once the user taps on the search bar ("Search Wikipedia in English"). Another option is to make the current language for the results more explicit and use that as an entry point for the language selection:

I hope some of these ideas are helpful.

As a broader approach, instead of allowing to switch the search results languages, we can consider integrating results from different languages in the same list.

In the example below, English is the default language but the user looks for "cama" which has some matches in other languages the user peaks (Spanish and Catalan).

With this approach we need to consider:

• Showing result only in the languages that the user may be interested. We can figure that out based on several factors such as the languages in which the user read articles in. For those search results I included the article name in the given language (to communicate why they are being matched) and the language name.
• Don't repeat results. If I look for "Paris", I want just one result about the city despite the name being the same in different languages.
• In which language to open the article. If the user made the search in Spanish, it make sense that the intention was to read the article in that language, so opening it in the indicated language would make sense. We may decide to open the results always in the default language for consistency (but it would be great to measure how many people switches the language after reaching the article through one of those links).

Additionally, we may want to include some access to settings as part of the search results:

There users can decide which languages they want to get search results in. This can be the general language setting but extended to allow one main language and several additional ones ( the list can make use of smart defaults based on previous languages used to read articles, system configuration, location, etc.)