Language Configuration

This page provides information about language configuration, support, spellcheck and how language codes are stored in the NewsML article.

Article Language vs UI Language

There is a difference between Article Language and Client Language which is important to understand when configuring the writer client.

User Interface Language

User Interface Language refers to the language used for the Writer itself, i.e. buttons, labels, notification messages, and so on. Basically anything part of the User Interface is the User Interface (UI) Language.
It's possible to set the UI Language in the writer-client config file, see below for examples and formatting.
It's not possible for normal users to change this setting.

Calendar Locale

It is also possible to change the locale used for date formatting, mainly used in date and time input fields. This could be useful if, for example, the UI language is set to Swedish but the calendar locale should use Finnish locale.
Calendar locale will use the default Article Language if not specified.

Article Language

Article Language refers to the actual language of the article content. This value is used for spellchecking and is stored in the article's NewsML.
The user can select article language using the language selector in the bottom bar.
Changing the article language also changes which language is used for spellchecking.
It's possible to configure which languages are available in the language selector using the writer-client config file. See below for examples.

Client Configuration

This section assumes the reader is familiar with the Writer's client configuration file and general structure.
Example client configuration:
"labelLanguage": "en",
"language": "en_US",
"calendarLocale": "en",
"languageFallbacks": {
"sv": "sv_SE"
"plugins": ...

Setting UI Language

Use the property labelLanguage to set UI Language.
The format for this value should be two characters, following the ISO 639-1 standard, e.g. "sv", "en", "no".

Setting Default Article Language

The article will first try to find its language value in its XML using the value of the contentSet > inlineXML > idf[xml:lang] -attribute.
If the XML value does not follow the format xx-YY (note the dash separator which is standard for XML-tags), then the languageFallbacks-property will be used to attempt to find the language. For instance, if language found in the xml:lang-attribute has the value "sv", then the languageFallbacks will be used and discover that it should use sv_SE.
If the language can not be found in languageFallbacks, then the value configured in the language-property will be used for spellchecking. The language-property can be seen as the default article language.
The language-property should be set to a pair of two-character codes separated by an underscore xx_YY (note the underscore, which is different from the xml:lang-value), e.g. "sv_SE", "en_GB", "en_US".
Technically this format can be described as [language-identifier]_[region_identifier],
  • [language-identifier] follows the ISO 639-1 standard, which is two letters, lowercased.
  • [region-identifier] follows the ISO 3166-2 standard, which is two letters, uppercased.
To summarize: Article Language will first look at its xml:lang-property, then at configured languageFallbacks, then finally use the value from the language-property in the configuration file.

Setting Calendar Locale (optional)

Setting the calendar locale is optional, and if not set will use the value of the language-property as a fallback.
This value is flexible and will accept either xx or xx_YY formats.

Setting Available Languages (optional)

In cases where only a subset of the supported languages should be available to the users, use the languageOptions-object and add languages-property to it.
The languages-property is a list of objects with label, code, and direction-properties. The direction-property has a default value of "rtl" (right to left), the other possible value is "ltr" (left to right).
Example of configuration where only Swedish and English languages are available.
"language": "en_US",
"languageOptions": {
"languages": [
"label": "Svenska",
"code": "sv_SE"
"label": "English",
"code": "en_US"
"plugins": ...
When adding a language which is not part of the list of supported languages, the internal spellchecking might stop working, or revert to english.

Article Template Configuration

First of all the template should be configured correctly. The <idf>-element should have correct values for dir, which can be either ltr (left to right) or rtl (right to left). The attribute xml:lang should be set to the correct locale used by the customer. It should have the same value as the language-property in the client configuration, except replaces the underscore with a dash.
Note that locales in xml use a dash - to separate language and country (en-GB, en-US) whereas elsewhere in the Writer configuration an underscore is used (en_GB, en_US). This is according to standards.
<idf xmlns="" dir="ltr" xml:lang="en-US">
<group type="body">
<element id="headline-d1f5ac9f52fc17b4da89004c9c7493da" type="headline">Headline here</element>

User Interface Translation

By default English and Swedish, are supported by the Writer. This can be extended by adding translations using the branding plugin (see below).
This is controlled by the Writer client configuration setting labelLanguage. Set this to either sv or en as in the example below.
If this setting is incorrect the user interface will fall back to English.
As there are many instances where installations might want to use one language for the user interface, but still display date and time using a format from another language the date and time format can be controlled using the configuration setting calendarLocale.
See below for an example where the user interface uses Swedish but the date and time format will be displayed using the Finnish format.
"labelLanguage": "sv",
"calendarLocale": "fi"

Individual plugins

Many plugins can be configured to display different fields, labels and descriptions. These plugins must be configured independently. Examples include, but are not limited to, publish flow, generic text field, option and the content part plugins.
See documentation for each plugin at

Branding plugin

The branding plugin can be used in two ways. Either as a way of overriding specific "labels", text, used in the user interface to allow organizations to use their own vocabulary if different from what is used in the Writer.
It can also be used to add labels for a completely new language, or in short, translate the Writer user interface.
For more information see the documentation for the Branding plugin at

Currently Supported Languages

The internal spellcheck and suggestion feature currently supports the following languages:
  • en_GB - English (Great Britain)
  • en_US - English (American)
  • en_CA - English (Canadian)
  • en_AU - English (Australian)
  • en_NZ - English (New Zealand)
  • it_IT - Italian
  • nb_NO - Norsk Bokmål
  • nn_NO - Nynorsk
  • nl_NL - Nederlands
  • sv_SE - Svenska
  • sv_FI - Svenska (Finland)
  • pl_PL - Polskie
  • de_DE - Deutsch
  • de_AT - Deutsch (Österreich)
  • de_CH - Deutsch (Schweiz)
  • fr_FR - Français
  • is_IS - Íslensku
  • pt_PT - Português
  • es_ES - Spanish (Traditional)
  • es_MX - Spanish (Mexican)