chrome.i18n

Description Use the chrome.i18n infrastructure to implement internationalization across your whole app or extension. You need to put all of its user-visible strings into a file named messages.json. Each time you add a new locale, you add a messages file under a directory named _locales/localeCode, where localeCode is a code such as en for English. Here's the file hierarchy for an internationalized extension that supports English (en), Spanish (es), and Korean (ko): In the extension directory: manifest.json, *.html, *.js, _locales directory. In the _locales directory: en, es, and ko directories, each with a messages.json file. #How to support multiple languages Say you have an extension with the files shown in the following figure: A manifest.json file and a file with JavaScript. The .json file has "name": "Hello World". The JavaScript file has title = "Hello World"; To internationalize this extension, you name each user-visible string and put it into a messages file. The extension's manifest, CSS files, and JavaScript code use each string's name to get its localized version. Here's what the extension looks like when it's internationalized (note that it still has only English strings): In the manifest.json file, "Hello World" has been changed to "MSG_extName", and a new "default_locale" item has the value "en". In the JavaScript file, "Hello World" has been changed to chrome.i18n.getMessage("extName"). A new file named _locales/en/messages.json defines "extName". Important: If an extension has a _locales directory, the manifest must define "default_locale". Some notes about internationalizing: You can use any of the supported locales. If you use an unsupported locale, Google Chrome ignores it. In manifest.json and CSS files, refer to a string named messagename like this: MSG_messagename In your extension or app's JavaScript code, refer to a string named messagename like this: chrome.i18n.getMessage("messagename") In each call to getMessage(), you can supply up to 9 strings to be included in the message. See Examples: getMessage for details. Some messages, such as @@bidi_dir and @@ui_locale, are provided by the internationalization system. See the Predefined messages section for a full list of predefined message names. In messages.json, each user-visible string has a name, a "message" item, and an optional "description" item. The name is a key such as "extName" or "search_string" that identifies the string. The "message" specifies the value of the string in this locale. The optional "description" provides help to translators, who might not be able to see how the string is used in your extension. For example: { "search_string": { "message": "hello%20world", "description": "The string we search for. Put %20 between words that go together." }, ... } For more information, see Formats: Locale-Specific Messages. Once an extension or app is internationalized, translating it is simple. You copy messages.json, translate it, and put the copy into a new directory under _locales. For example, to support Spanish, just put a translated copy of messages.json under _locales/es. The following figure shows the previous extension with a new Spanish translation. This looks the same as the previous figure, but with a new file at locales/es/messages.json that contains a Spanish translation of the messages. #Predefined messages The internationalization system provides a few predefined messages to help you localize. These include @@ui_locale, so you can detect the current UI locale, and a few @@bidi... messages that let you detect the text direction. The latter messages have similar names to constants in the gadgets BIDI (bi-directional) API. The special message @@extension_id can be used in the CSS and JavaScript files, whether or not the extension or app is localized. This message doesn't work in manifest files. The following table describes each predefined message.