the Chromium logo

The Chromium Projects

Text Input

OBSOLETE: The contents need to be updated

Abstract

Objective

Build text input support for Chromium OS to make it well internationalized.

Background

Chromium OS will be supporting multiple languages other than English. Regardless of the UI language (the language shown in menu items and any other strings in Chromium OS), Chromium OS should allow you to type in many languages. We will build text input support for Chromium OS on top of the existing text input technologies available for Linux.

Requirements

Chromium OS will provide users several ways to type in text:

There are also Chromium OS-specific requirements, such as supporting both x86 and ARM processors and following Chromium OS UI design guidelines. Meeting all of these requirements is not trivial. We'll reuse existing input technologies as much as possible.

We will support the following languages by any of the ways listed above.

Arabic Bulgarian Catalan Croatian Czech Danish Dutch English (GB) English (US) Estonian Filipino Finnish French German Greek Hebrew Hindi Hungarian Indonesian Italian Japanese Korean Latvian Lithuanian Norwegian Polish Portuguese (Brazil) Portuguese (Portugal) Romanian Russian Serbian Simplified Chinese Slovak Slovenian Spanish Spanish in Latin America Swedish Thai Traditional Chinese Turkish Ukrainian Vietnamese

Design

Basic architecture

For languages that can be supported by Simple Keyboard or Switchable Keyboard, we'll use XKB (X Keyboard Extension). For languages in other categories, we'll use IBus (Intelligent Input Bus). The following diagram illustrates the basic architecture of text input support for Chromium OS.

image

Keyboard layout: XKB

We will create the XKB definition file for each keyboard layout.

Input method framework: IBus

We will use IBus as the input method framework (IM framework). IBus is an open-source input method framework that works as a middle layer between applications and language-specific backend conversion engines.

We decided to use IBus for the following reasons.

Conversion engines

Many conversion engines are available for IBus, such as ibus-pinyin for Chinese. We'll use the following open source conversion engines.

IBus engine ibus-pinyin ibus-chewing ibus-table ibus-hangul Language Chinese (Simplified) Chinese (Traditional - Chewing) Chinese (Traditional - Bopomofo and Cangjie) Korean
New: For Japanese, we plan to port [Google Japanese Input](http://www.google.com/intl/ja/ime/) to Chromium OS.

User experience

We'll make the text input experience be uniform with the user experience in Chromium OS. To achieve this goal, we'll rewrite all user interfaces using Chromium's UI toolkit library called Views.

Candidate window

Will be implemented as separate process. Communicates to IBus-daemon via D-Bus.

New: Here's a screenshot of a work-in-progress version of the candidate window. A demo is also available.

image

XKB configuration dialog

Will be part of Chromium's options dialog. Communicates to X server via libcros.

IBus configuration dialog

Will be part of Chromium's options dialog. Communicates to IBus-daemon via libcros.

Conversion engine specific configuration dialogs

Will be part of Chromium's options dialog. Communicates to conversion engines via libcros.

Input language selector

Will be part of Chromium's status area (near the time and the power indicator). Communicates to IBus-daemon and X Server via libcros. We'll integrate the input language selector with the keyboard layout selector, unlike traditional Linux desktops. Here's a mockup of what it will look like:

image

Input language selector (on login manager)

Probably not required, because Google accounts (that is, email addresses) used for login are all in ASCII characters, as are the passwords. We will implement it once it becomes necessary. Internationalized keyboards can be supported by XKB configurations.

Sync with the cloud

Text input-related data is synced with the cloud. We sync the user's choices of languages, keyboard layouts, and input method extensions as described in Syncing Languages and Input Methods.

In the future, we may sync:

Syncing configuration data is a must, but users can opt out of syncing other user data.

Security considerations

An indirect input layer like IBus can be a security weak point, as it can be exploited as a key logger. We plan to use GRSecurity to restrict resource access from IBus and conversion engines. We also plan to review the security of IBus.

Long-term goals

Although the following goals aren't targeted for the initial version, these are some of our long-term goals:

Code location

IBus

Configuration dialog and language selector

Candidate window