To reach out to the users in the global market, providing your apps and services in many different languages is essential. There are a few things to keep in mind when you localize your apps or services for webOS Open Source Edition (OSE).

  • Write code using the multilingual library provided by webOS OSE. 
  • Prepare multi-language string resources in the guided format.

Locale identification in webOS OSE

Locales in webOS OSE follow the BCP 47 standard. A locale is represented as a language tag, typically in language-[script]-[region] format. For example,

  • fr-FR: French - France

  • fr-CA: French - Canada

  • zh-Hant-HK: Chinese Traditional - Hong Kong

For more information about BCP 47 and the language tag, refer to the below links.

The localization method varies depending on the programming language of your choosing.


For Enact apps or web apps developed in JavaScript, you can write code for localization using a library called iLib

For more information about iLib and Enact, refer to the below links.

iLib requires string resources in JSON format. Create a file named strings.json and write strings for translations according to the key-value format in the file.

  "String 1": "Translation 1",
  "String 2": "Translation 2"

You should prepare strings.json files for each locale under the resources directory. The directory structure is as below.

├── resources
│   └── language
│       ├── script
│       │   ├── region
│       │   │   └── strings.json
│       │   └── strings.json
│       └── strings.json
├── src

For example, the strings for French-language speakers in France need to be stored in resources/fr/FR/strings.json, while the strings for French-speaking residents of Canada stored in resources/fr/CA/strings.json.

Preventing the Use of Duplicate Data

If you consider preventing the use of duplicate data, you can configure the structure of string resources as follows. Let's take an example of English where there may be other translation terms by region.


en-US (English - USA)

en-GB (English - United Kingdom)

All All All
Hello Hi Hi
Color Color Colour
Subway Subway Underground

To avoid duplicates, you can configure directories and files as follows:

  • All: If the original term and translated strings are the same, there is no need to write translations in the resource file.

  • Hello: If the strings for en-US and en-GB are the same, write them in en/strings.json.

  • Color, Subway: If the translations for US and UK English are different, write them in en/US/strings.json and en/GB/strings.json respectively.

└── resources
    └── en
        ├── GB
        │   └── strings.json              : Colour, Underground
        ├── US
        │   └── strings.json              : Color, Subway
        └── strings.json                  : Hi

C & C++

If you are developing apps and services in C/C++, you can write code for localization using a library called libwebosi18n.

In C/C++, the string resources in JSON format are needed just like in JavaScript. Develop your app to support multiple languages using the same format and structure described in the JavaScript section. You can also specify the name of the JSON file, but we recommend using cppstrings.json for C++ and cstrings.json for C.

Qt & QML

Unlike JavaScript or C/C++, Qt/QML has different format and structure of string resources for localization.

Basically, you can use the localization method of Qt. For the detailed guide, refer to the below link.

If you choose to use the LocaleService module of webOS OSE (included in the qml-webos-bridge component) for localization, you should create a QM file for each locale with the following file name format.

Format: sample_[lang]_[script]_[region].qm

example: sample_en_GB.qm, sample_zh_Hans_CN.qm

Unlike JSON format, each QM file must have all of the translation strings needed for its locale, even if there are duplicate translation strings.

Except as noted, this content is licensed under Creative Commons Attribution 4.0 and sample code is licensed under Apache License 2.0.