1. Background

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.

2. Language Identifiers In Use

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.

3. API Interfaces

3.1. Erply API

  • A "save" call accepts input fields "nameENG", "nameGER", "nameSPA" and so on (corresponding to the identifiers above)
  • A "get" call typically outputs data in one language only. To specify which one, pass input parameter "lang=ger", for example. If the parameter is omitted, API returns data in account's default language.
    • Some calls support input parameter "getAllLanguages=1", which will make the API return fields "nameENG", "nameGER", "nameSPA" and so on.

3.2. Other APIs

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", 


"name": {
    "en": "Other", 
    "zh_Hans": "其他"

Configuration Parameters

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"

Language Mapping

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
Polish pl gre PL
French fr lat CA,FR
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 lit VN
Arabic ar lit AE

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.


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".