Text content in Erply—product names, product descriptions, various classifiers—can be translated into multiple languages. Erply can be a backend for multi-language webshops, and users can browse back office or use point-of-sale applications in different languages.
On each account, there is a specific set of activated languages. To activate additional languages, please contact customer support.
Due to legacy limitations, a language identifier does not always mean what it appears to mean. The legacy identifiers are non-standard three-letter codes, and there are exactly 10 of them:
"eng", "spa", "ger", "rus", "swe", "fin", "gre", "est", "lat", "lit"
We have been "repurposing" these identifiers, and the repurposing rules have been defined by country. For example, on Canadian and French accounts, language identifier "lat"
actually refers to French, not Latvian.
In newer APIs, we have been avoiding this issue, and are using standard ISO-639-1 two-letter codes for identifying languages—but this also means there are two sets of identifiers in use.
Below you will find a table listing all the language identifiers in use, and their meanings.
"lang=ger"
, for example. If the parameter is omitted, API returns data in account's default language.
"getAllLanguages=1"
, which will make the API return fields "nameENG", "nameGER", "nameSPA" and so on.API calls input and output a translatable property (eg. a product's name) as a JSON structure (containing key-value pairs: language code + name in the respective language). Examples:
"name": {
"en": "Example",
"nl":"Voorbeeld"
}
or:
"name": {
"en": "Other",
"zh_Hans": "其他"
}
To detect which languages have been activated on an account, here are the configuration parameters that must be inspected.
Parameter name | Format of the value | Example | Parsing requirements |
---|---|---|---|
langs | A comma-separated list of languages enabled on the account (three-letter identifiers) | "eng,rus,fin" | Ignore any list elements that do not match the known 10 identifiers. |
country | Two-letter uppercase country identifier | "FI" | |
default_language | Three-letter identifier of the default language | "fin" |
The following table defines how the legacy identifiers must be interpreted. (This is the full list of all languages currently supported.)
Language or script name | Standard language code | Legacy identifier | Specific country? |
---|---|---|---|
English | en | eng | |
Estonian | et | est | |
Latvian | lv | lat | |
Russian | ru | rus | |
Finnish | fi | fin | |
Greek | el | gre | |
Spanish | es | spa | |
German | de | ger | |
Swedish | sv | swe | |
Lithuanian | lt | lit | |
Danish | da | spa | DK,FO |
Dutch | nl | gre | NL,BE |
Polish | pl | gre | PL |
French | fr | lat | CA,FR,BE,LU,CH,MU,MA,CD,SN,CI,TN,DZ |
Simplified Chinese | zh_Hans | lit | CN,TW,HK,MO |
Traditional Chinese | zh_Hant | lat | CN,TW,HK,MO |
Italian | it | lat | IT |
Turkish | tr | lit | TR |
Thai | th | fin | TH |
Faroese | fo | lit | DK,FO |
Vietnamese | vi | lat | VN |
Arabic | ar | lit | AE,BH,DJ,DZ,EG,JO,KM,KW,LB,LY,MA,MR,OM,PS,QA,SA,SD,SO,TD,TN,YE |
Czech | cs | est | CZ |
Norwegian | no | gre | NO,SE,FI,DK,FO,EE,IS |
Hebrew | he | est | IL,GB |
Bulgarian | bg | fin | BG |
Since the number of languages needed on one particular account is limited, we do not use locale codes at the moment (language + specific country, eg. "pt-PT" versus "pt-BR").
Chinese is a special case, as here the distinction is between scripts, not languages.
Sources:
Example: if configuration parameters are "langs" = "eng,gre"
and "country" = "NL"
, the enabled languages are English and Dutch (because in the Netherlands, identifier "gre" has been re-used to signify Dutch).
For this account, new REST APIs emit & accept language codes "en" and "nl".
If, however, configuration parameters are "langs" = "eng,gre"
and "country" = "US"
the enabled languages are English and Greek. There is no custom override for country US and lang "gre", so it must be interpreted as Greek by default.
For this account, new REST APIs emit & accept language codes "en" and "el".