Universal Language Selector/Design

This document describes the design of the Universal Language Selector: a tool that will allow users to select a language and configure its support in an easy way. Here you can find information about the design process followed for the Universal Language Selector including the scenarios analyzes, designs proposed and observations made when testing with users.

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.

The Universal Language selection comprises several aspects:

Language selection. A widget that can be used for selecting a language from a large set of possibilities. This widget can be used for any context that requires language selection (even for projects outside Wikimedia).
Language configuration. A dialog that allows users to configure support for different languages. This will act as a unified UI for configuring different language-related tools and options such as input method help, font configuration and UI language change.
Integration with current projects. Several considerations are taken into account on how to integrate the ULS functionality for different kinds of projects (e.g., monolingual and multi-lingual wikis), contexts (e.g., when users are editing content or they need to select several languages) and devices (e.g., support keyboard-only or touch-only use). 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).

Note that although the designs include remarks about most of the aspects above, not all of them will be available at the same time but incrementally added during the project.

We expect that making language selection easier and more intuitive:

Will allow for greater penetration into all languages
Will enable the sites to be more culturally neutral
Will promote cross-wiki collaboration

Schedule

This was enabled on all Wikimedia projects (with some limitations on available functionality) since 2013-06-11.

Feature requirements

Definition of the behavioral variables, user profiles and scenarios.

A detailed analysis on user profiles, requirements and ideas for the language selector have been collected in the interaction design framework. A summary of the design goals and the main features to be supported is provided below.

The following goals have been defined:

Discoverability. The selector and their features are easy to find.
Fluency. The solution should interfere 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.

Other general requirements obtained from the definition of user profiles and scenarios:

Support repeated language change among a small set of languages.
Easy access to local-spoken languages.
Provide indications of lack of language support.
Discoverability of UI language settings (e.g., input methods) and aids for accessing them when needed.
Easy disable/re-enable of input methods.
Distinction between UI and Content language settings.
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 be language agnostic

Proposed design

The proposed design is based on combining different mechanisms to reduce the complexity of the language list, but a way that requires minimal effort from the user. Many aids for dealing with information have been applied in this design, including searching, filtering, and grouping. By applying smart defaults, minimal user effort is required to take advantage of them.

Prototypes and tests with users

Testing the prototypes

Different prototypes were elaborated as a tool to communicate the designs and receive feedback. The summary of the observations made during the usability tests are available. The different prototypes developed are listed below.

Testing the implementation with users

Initial tests for the language picker have been compiled in a video.
A test scenario has been defined to make use of the ULS implementation in existing websites.

Prototypes to show the different views and their navigation

Two prototypes were created to illustrate the navigation between the views that compose the Universal Language selector when it is integrated at different locations:

Warning:

Brokenlinks

These prototypes are made of images linked together so they provide no freedom when searching and interactions have only defined for a English and Spanish languages.

Prototypes to support user scenarios

Test scenarios have been defined to evaluate prototypes.

Testing with users required the language list to be searchable so more interactive prototypes were created. In order to keep the prototypes easy to develop they provide support only to specific scenarios and the behavior shown for other interactions may not be representative of the desired behavior for the selector.

The prototypes support the following scenarios (more detail in the attached document):

Content language change. A user moves through different wikis changing the content language.
Input method change. The user wants to contribute some content but it includes characters for which his keyboard is not prepared.
UI language change. A user wants to export to PDF the Greek version of an article for a friend. Since the user has no idea of Greek he adjusts the UI language to English.
Edit context support. While editing content, the user wants to change between different input languages and input aids.

Prototypes used to evaluate integration in different contexts

An additional set of prototypes have been defined to test different options for placing the selector in the page and for the editing support.

Anatomy of the selector

The proposed version of the selector is composed by three elements: the trigger, the language picker and the language-related settings. In addition, some aids are provided in specific contexts such as the selection of multiple languages and when the user is editing.

A detailed specification provides more information on the specific behavior of the selector in different contexts such as right-to-left languages.

Initial sketch.
Wireframe illustrating the layout of languages by script type.
Wireframe for the language list with aids for filtering its content.
Prototype showing the list of languages.
Prototype showing language display settings.
Wireframes showing the navigation between setting views.
Wireframes showing the editing support.
Display settings.
Input settings.
List of languages.
Initial mockups of various ULS ideas

The trigger

The trigger is the element that makes the language picker to appear. The trigger may be used in different contexts:

For language settings. The trigger is represented as toggle buttons where only the current language can be pressed at a time. An "add" button allows the user to select a different language.

For context-specific language selection (e.g., content language or filling a form value). The trigger includes an indicator of the current language selected (if any). Available languages are presented as a short list of links plus a link indicating that there are more languages available (indicating the number of languages). This acts as a link that activates the language list for users to select a language.
- Likely languages which are not available in a specific context are also included in the list but in a way that indicates they are lacking (greyed-out or using red links). These languages are included since users may be interested in both accessing content and finding whether content is available in their favorite languages.

The criteria to select the list of likely languages are the following:

Languages defined in browser settings.
Contributed and consumed languages by the user (if this information is available).
Language defined in the user settings (if this information is available).
Languages spoken in the current geographic area.
Previously selected languages.
English as a global default.

The language picker

When the selector is activated, the language picker is shown. The language list provides several mechanisms to reduce the complexity of dealing with a long list of languages.

Search based filtering. The selector allows users to search for a specific language. The number of languages shown in the list will be reduced as the user types his search criteria.

Languages can be found by typing either their name (in any language), their ISO code or the country where they are spoken. Due technical limitations, language searches may be initially limited to language names in their own language and few major languages. Meaningful combinations can be later added (e.g., geographical proximity).

Geographic filtering. A World map divided vertically in three regions (with labels) is used to reduce the number of languages to the ones spoken in a specific region.

By default the filter is activated to show only the languages spoken in the current region the user is located.
Although the map represents broad regions, the list of languages can be ordered differently depending on the user location. For example, a user accessing from Africa will be provided African languages on top of the list.
Languages spoken in multiple regions such as English or Spanish will be shown for all the regions where they are spoken.

The fact that the World map is divided in broad regions with the current user location provides a simple way to reduce the language list to one third without requiring the user much geography literacy.

List of languages. Languages are shown in a multi-column grid.

Languages are organized in 5 columns with 10-items per column and two rows of items initially visible (to invite for scrolling if needed).
Since vertical scrolling may be needed, languages are grouped in clusters in a way that communicate the ordering of scanning to follow alphabetical order.
A category is defined for each geographic sub-region (e.g.: Europe, Africa...).
- The first region to be placed on top depends on the user current location.
Any language that is likely to be selected by the user (according to the same criteria followed with the trigger) will be highlighted in the list.

Languages with the same type of script will be displayed together. This allows the user to focus on the region of the list where more familiar text appears (see the image above).
- Scripts with the greater number of languages will be placed first.
- Script regions should avoid fragmentation and have a clear starting point.
  - Two scripts cannot be in the same cluster if they span more than one cluster.
  - If a set of languages spans multiple rows it should start at the first column.

Language settings

The selector includes links to two kinds of language-related settings:

Input settings. The user can select a different language for text input and enable specific input methods for this language. The options provided are the following:
- Input language. The current language used for input is shown with a list of likely languages to facilitate the selection. Although the initial criteria are the same used for the trigger, in this context previous selected input languages are prioritized.
- Input methods. For each language a set of input methods are provided grouped by types. For each type a brief description (and a help link) are provided. When several options are available, the appropriate control will be shown for selection. Conversely, when no options exist, widgets for selection must not be shown. For example, a language for which no methods are provided, will not show this section at all.
Display settings. The user can change the language of the user interface and make adjustments related to fonts settings.
- Language for menus. It allows the user to change the language used for the user interface without affecting the content. This change is previewed immediately as the user selects a different language. In any case, the action can be reverted if the user decides to cancel the selection.
- Font settings. The user will be allowed to disable the font downloading mechanism that allows fonts to be properly displayed. The user can indicate his preferred font to use in case that several fonts are available for a language. When content, UI and input languages are different, a mechanism will be provided to choose the preferred font for each language.

Both settings views require performing a language selection. This language selection will be supported by integrating the list of languages and filtering aids in the settings view.

It's worth noting that user preferences which are specific to a language (e.g., preferred input method) will be remembered across language changes.

Location for the selector

Different possibilities have been explored for the placement of the selector. The Universal Language Selector will not be a replacement for the current inter-language links initially. We want to place the selector in a location that is easy to find for the user but produces no confusion on the purpose of these two language-related functions.

The placements considered for the Universal Language selector have been the following:

Option A: Top-right. This was the original placement for configuring language-related extensions such as Narayam and WebFonts. It is located in a location that is easy to find and is normally associated to settings. For logged-in users, there are several links in this position that may reduce the room available (especially with small screens).
- An interactive prototype has been built to test this option.

Option B: Integrated in the left menu bar. This option integrates the language setting as part of the inter-language links. The rational is to provide language-related functionality in a single point to avoid confusion. Inter-language links have been extended to indicate the current language, where settings can be changed. This solution probably requires the user to have certain familiarity with the placement of inter-language links.
- An interactive prototype has been built to test this option.

Option C: In a page-wide settings section. This option uses a wider concept of settings. a "page settings" menu is created where language-related settings may be accessed. Other settings can be integrated there over time. The placement selected has been used to indicate article status (e.g., protected, featured, etc.), so it may be too cluttered for certain articles.
- An interactive prototype has been built to test this option.

Mock up for Option A
Mock up for Option B
Mock up for Option C

Application to different contexts

The selector is presented in a different manner depending on the context it is used.

Depending on the context, the language selection may have different purposes:

For contexts where the language of content can be modified, the language list will be shown by default, and the trigger will contain a list of likely languages.
For contexts where the content language cannot be modified, the settings view is provided instead as default. Since inter-language links are not being initially replaced by the language selector for monolingual wikis such as Wikipedia, the Universal Language selector will not be used to change content language.

Alternative designs

In addition, to the previous design, two additional designs have been considered:

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.
The original proposal by Arun Ganesh. The result of the first exploration of the problem at the 2011 Mumbai Hackathon.

External links

http://www.gpaumier.org/blog/628_universal-language-picker/