This page provides information about language configuration, support, spellcheck and how language codes are stored in the NewsML article.
There is a difference between Article Language and Client Language which is important to understand when configuring the writer client.
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.
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 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.
This section assumes the reader is familiar with the Writer's client configuration file and general structure.
Example client configuration:
Use the property
labelLanguageto set UI Language.
The format for this value should be two characters, following the ISO 639-1 standard, e.g.
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
languageFallbackswill be used and discover that it should use
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.
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
Technically this format can be described as
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 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
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.
languages-property is a list of objects with
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.
When adding a language which is not part of the list of supported languages, the internal spellchecking might stop working, or revert to english.
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:langshould 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-US) whereas elsewhere in the Writer configuration an underscore is used (
en_US). This is according to standards.
<idf xmlns="http://www.infomaker.se/idf/1.0" dir="ltr" xml:lang="en-US">
<element id="headline-d1f5ac9f52fc17b4da89004c9c7493da" type="headline">Headline here</element>
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
enas 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
See below for an example where the user interface uses Swedish but the date and time format will be displayed using the Finnish format.
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.
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 https://plugins.writer.infomaker.io.
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)
nb_NO- Norsk Bokmål
sv_FI- Svenska (Finland)
de_AT- Deutsch (Österreich)
de_CH- Deutsch (Schweiz)
es_ES- Spanish (Traditional)
es_MX- Spanish (Mexican)