> For the complete documentation index, see [llms.txt](https://docs.navigaglobal.com/writer/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.navigaglobal.com/writer/admin-guide/language-configuration.md). # Language Configuration ## 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 {% hint style="info" %} This section assumes the reader is familiar with the Writer's client configuration file and general structure. {% endhint %} Example client configuration: ```javascript { "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](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) 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](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) standard, which is two letters, lowercased. * `[region-identifier]` follows the [ISO 3166-2](https://en.wikipedia.org/wiki/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. ```javascript { "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 ``-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.* ```markup Headline here ``` ## 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. ```javascript { ... "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) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.navigaglobal.com/writer/admin-guide/language-configuration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.