To reach out to the users in the global market, it is essential to provide your apps and services in many different languages. 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 internationalization (i18n) library provided by webOS OSE.
This page provides the links to external pages with detailed information on libraries and coding rules for each programming language.
Prepare multi-language string resources in the guided format.
You can prepare string resources yourself, or use the localization tool to make string resources generated at build time.
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, where the language code is a required field. For example,
fr-FR: French - France
fr-CA: French - Canada
zh-Hant-HK: Chinese - Chinese Traditional - Hong Kong
For more information about BCP 47 and the language tag, refer to the following:
(1) Write codes using the internationalization(i18n) library
In order to get localized strings on your project, Strings need to be wrapped with a function appropriate to the file type.
Please refer to the following guide: Writing Localizable Code.
Note If you want to create resources manually without using a localization tool, Please skip the next steps and go to the Resource Formats section.
(2) Prepare XLIFF files
(2-1) What is XLIFF?
XLIFF (XML Localization Interchange File Format) is an XML format file that contains the actual translation data. XLIFF must exist for each locale.
The following table describes the key elements and attributes of XLIFF.
<xliff> - srcLang
Source language - the code of the language, in which the text to be translated is expressed
<xliff> - trgLang
Target language - the code of the language, in which the translated text is expressed
<group> - name
Source string - the text to be translated
Target string - the translated text
The source language is defined as en-KR.
basename : The short name for the application. The right-most word of the dot-connected string of the application name becomes the basename.
If an application name is com.webos.app.home, the basename is home.
If an application name is sample, the basename is sample.
(2-2) How to write XLIFF files?
When writing an XLIFF file, the value of original attribute must match the basename. In addition, the value of name attribute in group must match the type of programming language used for developing the apps or services, as follows:
The localization tool parses source codes along with XLIFF files, and generates string resources in formats required by each programming language.
Therefore, you must provide translation data in XLIFF format to use the localization tool.
In order to run the localization tool on your machine, you need to check out the localization tool repository and then install the plugins.
In order to install the loctool, make sure you have Node.js installed on your machine and in your path, as this is used to run the code (Use 7.0 or later).
Once Node.js is installed, you can install the loctool.
git clone https://github.com/iLib-js/ilib-loctool-webos-dist
// or to install it globally: npm install -g
(3-2) Prepare a configuration file
To run the tool, create a project.json configuration file for each project and place it in the root of that project.
The loctool recursively search the given directory (current dir by default) for project.json files to find the roots of the projects. The root of each project will be recursively searched for localizable files.
node <path-to-the-loctool-dir>/loctool.js// To see the usage
node <path-to-the-loctool-dir>/loctool.js-h// Example) options on webOS
(4) Update Recipes to apply webOS build
In order to enable the localization task during build, recipes need to be updated properly.
To use the localization tool for generating string resources at build time, add the following line to the recipe to inherit the webos_localizable bbclass.
Regarding C/C++ cases, the i18n library (libwebosi18n) needs to be built first.
In order to do that, add a dependency for the library to the recipe.
This section explains the resource format of each supported programming language.
Web Application relys on the iLib library and it requires string resources in JSON format.
If you are not using the localization tool, create a file named strings.json and write strings for translation in key-value format.
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.
You can also specify the name of the JSON file. However, it is recommended that you use cppstrings.json for C++ and cstrings.json for C.
Basically, you can follow the localization guidelines of Qt. For details, refer to the Qt documentation.
If you use the localization tool, .qm files for each locale are generated in the following file name format.
If you consider preventing the use of duplicate data, 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)
To avoid duplicates, 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.
│ └── strings.json : Colour, Underground
│ └── strings.json : Color, Subway
└── strings.json : Hi
You can also specify the name of the JSON file, but it is recommended that you use cppstrings.json for C++ and cstrings.json for C.
Pseudolocalization (or pseudo-localization) is a software testing method used for testing internationalization aspects of software. Instead of translating the text of the software into a foreign language, as in the process of localization, the textual elements of an application are replaced with an altered version of the original language.
When you use the localization tool, it generates the string resources for pseudo locale by default. (You do not need to add an XLIFF file for this locale.)
A pseudo string is generated by processing the source string. For hard-coded strings, however, a pseudo string is not generated.
The pseudo locales defined in webOS OSE are as follows. The character set differs per locale. Therefore, you can check the localization issue even before the actual translation data is updated.