A locale is a set of parameters that defines the user’s language, country and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language identifier and a region identifier.
When creating a project in WebTranslateIt, you are required to choose a source locale, as well as several target locales.
🔗Locales and Files
Files are mapped to locales in the File Manager. For instance, when you add a locale, WebTranslateIt automatically creates target files for each master file in the File Manager.
Furthermore, when you add a new master file in WebTranslateIt, target files are automatically created and mapped to existing locales.
Deleting a locale deletes the related files in the File Manager.
The locale builder allows you to construct locales. To use it, start by typing the beginning of the language you want to use.
In the example above, I typed “az” and the locale builder offers me a large choice of locales:
|Locale Name||Locale Code||Script|
|Azerbaijani, Azerbaijan (Arabic)||az-AZ-Arab||Arabic|
|Azerbaijani, Azerbaijan (Cyrillic)||az-AZ-Cyrl||Cyrillic|
|Azerbaijani, Azerbaijan (Latin)||az-AZ-Latn||Latin|
WebTranslateIt knows relevant informations about each locales:
- Which countries (or territories) use a language,
- Which scripts a language is written in (for instance:
- Which script is the official one or mostly used one.
If your locale doesn’t provide an explicit script (like the locale code
az for instance) an implicit locale is chosen for you:
Latin in Azerbaijani’s case. If you’d rather use another script you can build a locale with the correct script. The default locale is the official or most important script for a language or for a language/country compound.
🔗Hyphen and Underscore
Is is prefered to use an hyphen (or dash) rather than a underscore sign to separate the language code, the country code and the script code. RFC 3066 recommends using
en-GB instead of
Language tag syntax
The language tag is composed of one or more parts: A primary language
subtag and a (possibly empty) series of subsequent subtags.
The syntax of this tag in ABNF RFC 2234 is:
Language-Tag = Primary-subtag \*( "-" Subtag ) Primary-subtag = 1\*8ALPHA Subtag = 1\*8(ALPHA / DIGIT)
The productions ALPHA and DIGIT are imported from RFC 2234; they
denote respectively the characters A to Z in upper or lower case and
the digits from 0 to 9. The character “-” is HYPHEN-MINUS (ABNF:
All tags are to be treated as case insensitive; there exist
conventions for capitalization of some of them, but these should not
be taken to carry meaning. For instance, ISO 3166 recommends that
country codes are capitalized (MN Mongolia), while ISO 639
recommends that language codes are written in lower case (mn
However, even if using an hyphen (or dash) is preferred, some software use underscores (
en_GB), so you can choose to use dashed locales in your project settings.
This setting impacts the generated file names, the API URLs, and in some linguistic files the locale code used.
Sometimes you’ll want to create your own locale. For instance, if your development team write an English copy that needs to be proofread, you might want to create a fake locale “English by developers”. The copy in this locale will, in turn, be modified and proofread by a professional proofreader before being translated into other languages.
Another reason could be that your app needs a specific custom locale based on a very specific location. There can be many good reasons.
In the Locale manager, start by choosing a base locale. Then, click on “Create a specific locale” to toggle additional options.
These additional options will be postfixed to the base locale code and name.
- Postfix code is a code that will be postfixed to the locale code. For instance dev.
- Postfix description is the description of the postfix you add. For Instance “by developers”.
This will generate a new custom locale with the code en_dev and name “English by developers”.