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).

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

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 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.

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 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.

Interactive prototypes

Test scenarios have been defined to evaluate prototypes.

Several interactive prototypes have been defined to evaluate the design solution. The prototypes support the following scenarios (more detail in the attached document):

• 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.

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

Anatomy of the selector

The proposed version of the selector is composed by three elements: the trigger, the list of languages and 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.

• 

  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.

The trigger

The trigger is represented by a short list of languages the user may be interested in. Languages are presented in their own script, and languages using the same (or similar) scripts are placed together to allow consistent alphabetical ordering. If the number of possible languages is greater than eight, the trigger will show six in the list 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.

The criteria to select these six languages is 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.

Likely languages which are not available in a specific context are also included in the list but in a way that indicate they are lacking (greyed-out or using red links if it is possible to trigger the creation of the lacking content). These languages are included since users may be interested in both accessing content and finding whether content is available in their favorite languages.

The trigger may include an indication of the current language that is also used for activating the language list.

The language list

When the selector is activated, the language list 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).
• When the selector is open, the search box will get the input focus. Focus should not be automatically gained for users accessing form a tablet or mobile device, since it can trigger their virtual keyboard.
• When searching, an aid for clearing the search will be shown (e.g., an X at the right of the search box).
• When searching, the first of the results will be strongly highlighted to indicate that can be selected by hitting the enter key. This allows users to complete keyboard-only language selection.
• When searching, the geographic filter is only applied if there are enough results to fill a complete page. When few or no results are provided for the current text entry, the geographic selector includes all regions to avoid results to be hidden by mistake (and indicates this graphically).

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.
• When scrolling is needed, a link placed at the bottom right indicates that more languages are available. By clicking on the link, the list will be smoothly scrolled to the next block of results (the next two rows which were not visible just below fold).

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 is 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 made 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 chose the preferred font for each language.

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

Is 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

We are exploring different possibilities 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.
  • 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.

Related bug reports

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

External links

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