Universal Language Selector

'''This document is a work in progress. Comments are appreciated but this is not a final draft.'''

This document describes the design of a language selector widget. This document is intended to be a starting point for conversations about how to best handle language selection on Wikimedia sites.

IMPORTANT: This feature does not differentiate between selection of language at specific scales or contexts. That is, a user may choose to have Spanish as their "chrome" language, and then use the selector to view an article written in German, or maybe change their keyboard mapping to Russian, etc.

Rationale

 * Wikimedia properties exist in hundreds of languages. Simple selectors do not scale beyond ten or twenty items. Wikipedia is offered in 284 languages, and there are 424 available translations for MediaWiki.

Identified language selection contexts include but are not limited to:
 * Site-wide language selection (e.g., user preferences) for the site "chrome"
 * Editing language selection, especially for input modification (e.g., Narayam)
 * Interwiki link selection
 * Portal page language selection (such as on the Wikipedia home page).

Hypothesis

 * Making language selection easier and more intuitive will allow for greater penetration into all languages
 * Making language selection easier will enable the sites to be more culturally neutral
 * Making language selection easier will promote cross-wiki collaboration

Feature Requirements

 * The language selector should be built as a "widget" that can be called from multiple contexts (e.g., can be repurposed)
 * The language selector should attempt to aid the user as much as possible
 * The language selector should be language agnostic

User Scenarios


To better illustrate the intended purpose of the Universal Language Selector, several scenarios have been defined. The complete definition is. Here a summary has been included in this section.

To create representative scenarios, the behavioral variables that affect interaction have been analyzed and structured on four user profiles.

Behavioral variables
A set of factors that affect the way in which a user select a language have been defined. These variables have been identified by analyzing different sources of information (bug reports, talk pages for existing documentation) and gathering feedback from members of the Wikipedia community and members of the Localisation team.

The variables identified are the following:


 * Number of languages spoken by the user (one, two, several)
 * Skill level for each language (no, bad, basic, good/native)
 * Kind of language spoken by the user:
 * Writing direction for the language (LTR, RTL)
 * Number of speakers (many, few, none/historical)
 * Geographic distribution (shared with other languages, spoken in multiple geographic areas, spoken in a single area)
 * User main activity (consuming content, searching, contributing content)
 * User location (native country, non-native country where the user can communicate, foreign country)
 * Familiarity with language features (not familiar, basic use, advanced, expert)
 * Device used for access (tablet, desktop/laptop)
 * User account (anonymous, registered)

This is not intended to be a complete scientific taxonomy. The purpose is to facilitate the evaluation of design solutions.

User Profiles and scenarios
Each combination of values of the former behavioral variables defines a specific kind of user for which the ideal interaction may be different. A small subset of user archetypes has been defined to cover the behavioral variables to the widest possible degree. A summary of the profiles defined and the scenarios is profiles below, the attached PDF includes a more detailed description.

George
George is an architect from Georgia that speaks only Georgian and consumes content from his tablet. He is not a registered user and he is not aware of language tools such as the inter-wiki links.

His goal is to learn about new topics in his own language:
 * Properly displayed content. George access the Georgian version of an article and everything is properly displayed.
 * Features: non-intrusive UI, proper font display for non-latin scripts.
 * Recover from a foreign language. George access the English Wikipedia through a friend's link, and figures out how to access the Georgian version.
 * Features: intuitive location for language selection.

Nambi
Nambi is a nurse from Paraguay that speaks Guaraní and Spanish. She contributes content in Guaraní and consumes content in both languages. She is a registered user and makes basic use of the existing language tools.

Her goal is to contribute to the Guaraní community:
 * Contribute local content. Nambi realizes that there is not a Guaraní version of an article She is reading in the Spanish Wikipedia. She creates a new article based on a translation of the Spanish one. She keeps jumping from one version to the other during the translation process.
 * Features: Support recurrent language change among a small set, access to local-spoken languages, and indication of lack of language support.
 * Setting the UI. Nambi prefers the user interface menus to be in Guaraní. She becomes aware that registered users can customize their UI language and changes this.
 * Features: Discoverability of UI language settings, and distinction between UI and Content language settings.

Rakha
Rakha is a musician from India, currently in Belgium. He speaks Tamil (native) and English (very basic). He searches and consumes content from the public PC at the hotel. He is not a registered user and he is not familiar with language tools.

His goal is to feel like at home (despite being abroad):
 * Search in his language. Rakha accesses the Wikipedia in Tamil but the public PC at the hotel has a French keyboard. Rakha finds guidance on how to introduce a few Tamil characters for the search. When he finds little information on the subject, he switches to the English version for a moment.
 * Features: Discoverability of input method configuration, aids for accessing input method configuration during text input, terminology used to communicate input method configuration, and discoverability of relevant content in other languages.
 * Cross-language information. Rakha has accessed the Tamil version of Wikipedia, but he is looking for information on a Belgium dish he only saw written in French. He searches for the dish name in French, but he is interested to access the information in Tamil.
 * Features: Disable/re-enable input methods, and cross-language access of search results.

Lev
Lev is a professor from Israel. He speaks Russian, Hebrew, and studies Old Aramaic. He is a registered user with deep knowledge of language tools and contributes content in these three languages from a PC.

His goal is to share knowledge about his topics of interest:
 * Extensive contributions. Lev makes large contributions in Cyrillic to the Russian Wikipedia. He uses different keyboards at work (lacking Cyrillic mapping) and at home (a Latin-Hebrew-Russian keyboard).
 * Features: Input method configuration UI support for long texts, integration of system configured input methods.
 * Mixed content. Lev studies Old Aramaic and includes content in Aramaic for Hebrew and Russian articles.
 * Features: Indication of current language for each piece of content.
 * Translation across languages. Lev helps to translate content between Russian and Hebrew and registers as a translator for both languages.
 * Features: Multiple language selection.

Design goals
The following goals have been defined:


 * Discoverability. The selector and their features are easy to find.
 * Fluency. The solution should interfer minimally with the main flow of tasks for the user. Changing settings related to language should be fast and not distracting.
 * Learnability. The way in which the selector is operated and the effects of each action should be easy to anticipate.

An initial plan for validation of the design solutions has been defined, and it is summarized below.

How to measure that the goals are achieved


Prototypes will be build to test the different design solutions. For the 2-3 most promising design concepts, two rounds of testing will be carried out with 3-5 users per prototype.

Each validation stage will consist in the following steps:
 * 1) Classify the participants. A short survey based on the behavioral variables identified will be completed by each participant. This will determine how the user fits in the types of users defined.
 * 2) Perform the usability tests. Users will use prototypes to carry out some test scenarios.
 * 3) Analyze the results. Design solutions will be modified/discarded according to the feedback obtained.

What to observe
Criteria to evaluate different design solutions and determine whether they are improving the current solution have been defined. This includes gathering quantitative data (we can measure them) and qualitative data (we can infer them by watching the use of the product and confirm them by asking). The observations of interest are the following for each design goal:


 * Discoverability. Language selector is easy to find.
 * Measure the success ratio: how many users found the way to change the language.
 * Measure the time to find the selector: time spent since the user starts looking for the language selector until they click on it
 * Ask: Do you think this information is provided in other languages?
 * Fluency. Language selector is quick to operate and non-distracting.
 * Measure the time to select languages.
 * Ask: Do you think changing between languages is fast?
 * Ask: Does the language selector distracted you from your main goal of looking for information?
 * Learnability. Language selector is easy to learn.
 * Measure the number of aids used when changing language.
 * Ask: Which elements do you see in the selector and which do you think its purpose is?
 * Ask: Which effect do you think it will have to select a language from this list?

Limitations for the testing
Several issues specific to the project limit the testing process:
 * Prototype-user language alignment. The prototype language must be aligned with the language of the user testing it. This require to either limit the scope of the participants to recruit, or elaborate the prototypes in such a way that texts can be easily replaced by appropriate translations (increasing their complexity of the prototype elaboration).
 * Configuration for text input. Advanced features related to input such as as transliteration are difficult to integrate in prototypes. Tests will be defined in such a way that these features could be simulated as much as possible.

Interaction Design Framework
In order to explore different design solutions in a systematic way, we have defined: the pieces that compose the Universal language Selector, the steps performed by the user and a collection of ideas to support the design goals.

Concept Model: the anatomy of the selector


The design solutions should consider the following concepts:


 * The trigger. The selector is activated by an element that provides access to the language selection. In the simplest case it may be a a "select language" label and a button that opens a dialog to allow the language selection. The mechanism for activating the selector is something that requires much thought and care. Users who do not speak English, for example, may not understand that the glyphs "Select Language" mean exactly that. It must be assumed that the user is not familiar with the language used by the site chrome.


 * Language list. The set of languages that are provided as an option. To make it easy to manipulate, the list can include aids for navigation and aids for presenting the different languages. Some of these aidss can be based on contextual information such as the languages spoken in the location the user is accessing from.


 * Input and display settings. Allow the adjustment of input methods and font settings and provide guidance on how to adjust these settings.


 * Current language indicator. Indicates the current selected language (or languages if the context requires multiple selection).


 * Context where it is used. The language selection can be performed with different purposes: change UI/content language, create a list of languages, or set global user preferences.

These concepts have been illustrated in a Concept Model. This concept model will be useful for breaking down the design solutions in pieces for which we can generate ideas and we can combine solutions. The interaction framework section uses these concepts to define directions to generate solutions.

Workflows: steps for language selection
Depending on the activity the users are involved in, the language selection is performed in a different manner. The proposed solutions should consider the steps the user makes in each case to make their workflow as fluent as possible.

Workflows have been analyzed for the following situations:




 * Single-language selection. The language selection flow defines the steps the user performs when selecting a language. Critical points are the location of the trigger for the activation and the mechanisms the language list provides for reducing the complexity of finding the desired option among hundreds of alternatives.




 * Multiple language selection. For multiple language selection, two alternatives can be used in terms of user workflow: action-based or status-based. The action-based approach consists in repeating the process of selecting one language for each language the user wants to select. The status-based approach allows the user to indicate whether each language is selected or not and modify his selection in a single step.




 * Input method selection. For input method selection we have identified two key points: when the user becomes aware that he cannot introduce text in their desired script, and when the user requires help for using the tools.

Mental model: aligning features with needs


From the defined scenarios several user needs were identified. We have defined a mental model diagram to align these needs with the design goals and the possible features of the language selector. User needs are represented at the top of the diagram. For each need a set of potential features are presented at the bottom of the diagram.

Fluency of use

 * Display content properly:
 * Automate font download. Make the font download enabled by default.
 * Font customization settings. Provide capabilities to chose among different fonts.
 * Use sensible defaults to hide advanced settings. Some adjustments can be moved to a separate section to simplify the main settings interface.
 * Warn when fonts are disabled to allow users to recover. Show a warning to the user when he relies on the system fonts and a non-latin script is displayed.
 * Use from a tablet device:
 * Use big tap targets. clickable elements should be big enough for both mouse and fingers.
 * Allow gestures for scrolling. Support the scrolling gesture on a surface to scroll its content apart from scrollbars.
 * Adapt some widgets to fit screen real state. For elements that require too much space, responsive design techniques can be applied to adapt to the tablet version.


 * Find the language quickly in a list:
 * Anticipate likely elements in the trigger.
 * Emphasize local languages
 * Emphasize browser-configured languages
 * Group languages by script type
 * Allow text search to filter the list.
 * Hide initially the less-frequent languages.
 * Automate default language selection.
 * Indicate languages are not available.
 * Emphasize previously selected languages.

Findability

 * Jump among a set of languages.
 * Shortcut to 'undo' previous changes.
 * User specified favourites.
 * (Re)enable and disable input aids while editiong. Provide shortcuts in the editing context.
 * Locate the selector easily.
 * Easy to find placement.
 * Use an icon to identify language selection.
 * Use languages in their own script.
 * Find language settings.
 * Easy to find placement.
 * Use cross-links from language related tools. For each tool that may requite a language settings adjustment, include a link to language settings.
 * Find input method configuration when needed.
 * Show shortcut to configuration when editing text.
 * Show shortcut to configuration on first removal.
 * Prioritize methods available for the current language.

Learnability

 * Distinguish UI from content.
 * Present as separate concepts.
 * Link to user settings UI.
 * Select content and indicate optionally whether to propagate the decission to the UI.
 * Present UI language as "Language for menus".
 * Explain input method config.
 * Provide help information.
 * Present input method as "input language". Provide the selection between keyboard layouts when more than one is available.
 * Make clear the consequences of the selection.
 * Add checkboxes for multiple selection.
 * Use a selected list for languages added.

Design principles

 * Make the user interface transparent. Language selection tools do not provide direct support of a specific user goal (e.g., find information) but provide mechanisms that make these goals easier to achieve. The experience should be transparent for two different usage patterns: sporadic use and repetitive use.
 * Provide tools where they are needed. Language selection is performed as a complement for certain tasks, the more easy it is form the user to find the selector while performing these tasks, the better.
 * Optimize for the probable, provide for the possible. The Universal Language Selector may be used by many different users in different contexts. Solutions proposed should make it easier to use for our target users without representing barriers that make the tool unusable for the rest.

Design patterns
Design patterns that can be applied to the Universal Language selector have compiled in this section to discuss their benefits and limitations. These are general interaction solutions that can be used i one or more of the ideas described in the mental model.

Autocompletion
As the user types what he is looking for, the system provides possible answers for the user to choose from. This pattern can be applied to free text searches or searches in a large but finite domain such as your list of contacts when sending an email. Suggestions can be provided even before the user types a single character. For the selector, language list can be hiden by using autocompletion. A solution for the language selector based on autocompletion was proposed by Guillaume Paumier.

Benefits:
 * Saves time. The user is not required to (a) explore all the possible answers, or (b) type the full answer.
 * Allows flexible input. Once the user starts typing, the suggestions can be provided as a result of different heuristics. Given two characters introduced by the user, suggestions can contain languages that contain these two characters in their name (in their own language or in a different one), languages that use these characters as part of their ISO code, and previous languages selected by the user.

Limitations:
 * Requires the use of keyboard. To take advantage of the feature, typing is required. This can be a problem for (a) users which are mainly consuming content, and (b) tablet users where the keyboard consumes a great percentage of the screen and represents a greater change of context.
 * Difficult to explore. Autocompletion do not expose the full list of choices to the user. Thus, when the user does not find the desired suggestion he is not sure whether he is not typing it in the appropriate way or the solution does not exist at all.

Inline edit
An element which is used for displaying state, when operated it is transformed into an editable element. More information about the pattern. For the case of the selector, indicators of current language or input method can turn into a selection mechanisms as an alternative way of changing them.

Benefits: Drawbacks:
 * Reduces complexity. Edition elements are removed from first-sight, which is good if the primary purpose of the element is to display.
 * Difficult to discover.Since edition elements are hidden, they require the user to discover them. It is important to provide an adequate invitation to act.

Responsive disclosure
Parts of the interface that depend on a specific decision can be hidden until the decision is made by the user. This can be applied for the case of language-relate settings since different dependencies exist.

Jennifer Tidwell provides more detail about this pattern.

Benefits:
 * Complexity is reduced. The user is offered choices only when they make sense.

Limitations:
 * Information is hidden. If the user is looking for a specific sub-option, he may overlook it.

Iconography to represent languages
There is (at the time of this writing) no universal icon for "select language". Some sites utilize "flag" iconography but this not acceptable because:


 * Flags are not culturally neutral. There are more English speakers in India than there are in the United States, for instance.
 * Language is not "owned" by any one political organization. Is "English" best served by the flag of the United Kingdom, Canada, United States of America, Australia, or any one of other nations that recognize English as an official language?
 * Users typically have very low "flag literacy". Not all flags are known to all peoples.
 * Flags can be political hot-buttons. Not all nations are recognized by all nations.
 * Flags have potential "expiration dates". Nations do not exist in perpetuity; they rise and fall. They may also change their flag symbology and colors.
 * Flag systems require maintenance for accuracy.

At this point in time, the best developed icon for this type of function is a stylized, wireframe globe. The globe should not display any land mass areas for two main reasons: cultural neutrality (which country is on the front of the globe) and for resolution-at-scale issues (reading the icon at 16x16 pixels).

Design directions
The solutions proposed will explore different design directions. For each aspects different options have been provided, but these options should not understood as binary, but a whole range of designs can target intermediate positions. In general terms the main design directions to explore are:
 * Minimal contextual selector. Define a selector that is almost invisible, but offers help where it is needed. By taking advantage of contextual information, it provides the most likely options.
 * Helpful exploration. Define a selector that exposes the available options but provides as much help as it is possible to re-arrange information easily.

More detailed aspects that can be adjusted are listed below.

General

 * Look like a single component.
 * Totally unified. The selector is presented as a single component where language-related actions and configurations are accessed.
 * Related components linked together. The selector can be presented as different components for which it is easy to jump among them.


 * Adapt to user context.
 * Adaptable: Information will be organized and located differently depending on the user current and previous actions, location, browser configuration, etc.
 * Consistent. The UI will be the same regardless of the user context.

The trigger

 * Trigger location.
 * Global. A single entry point is provided for activating the selector in a location that is consistent and easy to locate.
 * Contextual. The trigger is placed closer to where it is needed.


 * Trigger connection with the language list.
 * Separate. The language list is shown in a different view.
 * Connected. The language list is shown as an adjacent view when activated. From this moment, the trigger is not operated for language selection.
 * Integrated. The trigger is extended to act as the language list.


 * The trigger includes complementary information.
 * No.
 * Number fo available languages.
 * Current language(s) selected.
 * Subset of the language list.
 * Icon.

Current language indicator

 * Acts as a trigger.
 * No.
 * Yes.


 * Is feedback provided when the language is changed.
 * No.
 * Announce the change.
 * Provide additional information and actions (to revert, or jump to other languages).

Language list

 * Provides navigation aids:
 * Filter by geographic region.
 * Provide a meaningful ordering.
 * Provide grouping.
 * Provide pagination.
 * Provide (vertical/horizontal) scrolling.


 * Which languages are emphasized.
 * Browser configuration ones.
 * Locally relevant.
 * Previous choices.
 * Most spoken.


 * How are languages emphasized.
 * Size.
 * Order.
 * Background color.
 * Prominent position.

Multiple selection

 * Flow to support.
 * Select and repeat.
 * Check and uncheck.


 * Where to display the current selection.
 * At the trigger.
 * At the language list.

Settings

 * User guidance
 * Show all choices.
 * Step by step guidance.


 * Input text settings integration:
 * Global position
 * Link to settings
 * Embed relevant settings close to the input element.

How to use the framework
The steps for defining a solution will be:
 * 1) Define which area to explore from  the design directions.
 * 2) Select which ideas to incorporate in the solution from the mental model defined.
 * 3) Select the elements to address form the concept model (you can design the whole selector or just the trigger).
 * 4) Use design patterns as a toolbox for specific executions of the ideas (evaluate whether they apply to the specific context first).
 * 5) Make a sketch of the solution.
 * 6) Ask yourself whether the solution follows the design principles.
 * 7) Imagine the different user profiles using the tool in their scenarios. Pay attention to the support the solution provides to each step defined in [#workflows|the workflows].

Arun Ganesh's Original design
At the 2011 Mumbai Hackathon, a small team began discussions addressing a major problem facing Wikimedia sites: language selection. The team put their heads together and came up with several ideas. The basic workflow was captured by Arun Ganesh; he put together a pdf file.

Process
Once the selector is shown, the user may go about selecting the language of choice.

Note that all languages are to be displayed in their native spelling and with native fonts. Additionally, ISO codes should be displayed next to them.

The selector should begin with two panes, one on top of each other.

Top Pane
The first pane shall include a flattened map of the world divided into basic "regions" (not nation borders). The system should auto-detect the region that the user is located in (either via geoip lookup or GPS coordinate lookup in the case of mobile phones) and have that region auto-selected (and displayed in the lower pane).

Additionally, there will be an ordered list of the world's most common languages displayed (for quick selection).

The map is hot - selecting any region will reload the bottom pane with that region's languages.

Bottom Pane
This pane includes a language search function as well as two disparate lists of languages, in sectioned columnar format.

The first section shall show between 5 and 10 of the most common languages in the selected region, ordered by number of speakers.

The second section will again list out languages used in the region. However, this list will include as many as can be included. This list is ordered (alphabetically? by iso code?). Simple pagination controls (next/previous) will allow the user to browse the full list if it does not display within the confines of the dialog.

Specification Callouts
''This text is copied and pasted directly from the PDF file. Formatting has been wikified slightly.''

The widget has 4 parts: 1. Widget shortcut:
 * a. Permanent link displaying selected language alongwith icons to indicate it is language related.
 * b. Seperate icon to directly open keyboard input or on-screen keyboard widget

2. Primary selector:
 * a. Static world map with marker showing user’s location guessed from geolocation user timezone or system language options. Clicking map changes the data in the secondary selector (3)
 * b. Static list of primary gloabal languages or biggest wikipedia projects. This enables quickly selecting a major language which has a high probability of usage.

3. Secondary selector:
 * a. Text box allowing a user to search language or countries. Autocomplete list
 * b. Country flag icons based on the region selected in the primary selector map or guessed user location. User can select his country flag if he identifies it
 * c. Regional map of the user’s area of interest. No markers needed, but clicking can change the ordering of languages
 * d. One column listing primary languages of the region or country chosen
 * e. Two columns with a comprehensive listing of all the minor languages. 3 text sizes to indicate the number of speakers of the language in the region.

4. Keyboard Input:
 * a. Options for keyboard mapping. Selecting a language would automatically load the available options and switch to the recommended input method for that language. Disable option switches to system settings
 * b. Keyboard mapping reference and on-screen keyboard. Dockable widget which can be dragged and detached from the language widget
 * c. Dropdown font selector to switch webfonts
 * d. Link to typing help or reference material

The universal language selector will allow a user friendly method for a user to switch to his native language from a foreign language interface with the help of visual aids.

The language selector widget can be activated by a link placed as close to the top-left or top-right of the page as possible. This is usually the first place a person looks for customization options in a foreign interface. Once activated, the widget expands to display the language selection options.

Related bug reports

 * 33677 Enable setting language preference without requiring login.
 * 28900 Add a keyboard layout display option to Narayam.
 * 33460 WebFonts "Select font" portlet menu should only be shown if there are options to choose from
 * 30595 Inconsistent search results with language links.
 * 28970 There's no clean way to indicate the directionality of the content of the page.