-
Notifications
You must be signed in to change notification settings - Fork 9
Internationalisation
The registry's language negotiation is based on the Accept-Language header that is supplied by the request.
This is usually set by the user's browser.
However, users can also override their default language by selecting a language on the UI (if available),
or supplying the lang query parameter, with a ISO 639-1
language code as its value.
The labels and descriptions of items in the registry are rendered in the user's chosen language, if an appropriately language-tagged value is available. Otherwise, they are rendered in an arbitrary default language (usually English).
Similarly, if you are using the latest version of registry-config-base, the UI templates will be rendered in the user's chosen language, if a corresponding messages file exists for that language. Otherwise, they are rendered in English. Note that messages emitted by the registry API will still be in English, even if the UI language is not.
You can enable multilingual rendering of registry content without configuring a messages file. In this case, the registry content will be rendered in the user's chosen language, but the UI templates will be rendered in English.
If you have upgraded to the latest version of registry-core, but you have not upgraded your registry config, your registry may produce warning logs stating that the default language is not configured. You can safely ignore these logs as long as your UI templates and configuration files do not use the multilingual UI features.
You can configure a set of languages that are supported by your registry by adding them to the /system/language system register,
which contains items of type dbo:Language (you may need to add the prefix to your system/prefixes system register).
This is necessary to enable language selection through the user interface.
| Prefix | Value |
|---|---|
dbo |
http://dbpedia.org/ontology/ |
Each supported language must have an ISO 639-1 language code, given by the dbo:languageCode property.
You can also set labels for the language, given by rdfs:label, which will be displayed on the user interface.
The labels will be displayed in their corresponding language, if available, so you should include language tags on the label values.
| Property | Definition |
|---|---|
dbo:languageCode |
The two-letter ISO 639-1 language code. |
rdfs:label |
The user-friendly label which the language is known by. |
You must also configure the language management feature by defining the necessary components in your app.conf,
and setting the languageManager property on your Registry component (usually registry.languageManager).
langConfig = com.epimorphics.registry.language.LanguageRegister
langManager = com.epimorphics.registry.language.MultiLanguageManager
langManager.config = $langConfig
registry.languageManager=$langManagerYou can store the user's preferred language as a cookie in their browser by setting the useCookies property on your
MultiLanguageManager component to true (usually langManager.useCookies).
The cookie is stored as registry-pref-lang and is updated whenever the user selects a language on the UI or supplies
a language query parameter.
This feature is disabled by default.
NOTE: If you enable language cookies, then you must take whatever measures are necessary to inform users that your registry site uses cookies for this purpose, and that by using the registry they agree to those cookies.
You may do this by modifying the default UI templates provided in registry-config-base.
langConfig = com.epimorphics.registry.language.LanguageRegister
langManager = com.epimorphics.registry.language.MultiLanguageManager
langManager.config = $langConfig
langManager.useCookies = true
registry.languageManager=$langManagerYou can configure your registry to render UI templates in the user's language of choice by providing a messages file for that language.
A messages file is a .properties file containing a mapping of message identifiers to values,
whose file name indicates the language it belongs to, eg. en.properties, fr.properties.
Messages files are automatically detected by the registry when they are located in the /opt/ldregistry/config/language/messages directory.
A default messages file for English language rendering is provided in registry-config-base. This contains the identifiers and values for all of the messages on the default UI templates.
You can change the location of the messages directory by configuring a FileMessageManager component in your app.conf.
You can do this with either the multilingual implementation (MultiLanguageManager)
or the default implementation (LanguageManager.Default).
msgManager = com.epimorphics.registry.language.message.FileMessageManager
msgManager.messageDir = /path/to/messages
multiLangManager = com.epimorphics.registry.language.MultiLanguageManager
multiLangManager.messageManager=$msgManager
defaultLangManager = com.epimorphics.registry.language.DefaultLanguageManager
defaultLangManager.messageManager=$msgManagerMessages files must be written with UTF-8 character encoding.
registerItem.setStatus.button=Set status
registerItem.setStatus.heading=Set status of {0} to ...
registerItem.createManual.heading=Create a new entry in {0}
registerItem.createManual.button=Manual entry
# ...Some messages are parameterised using the standard Java MessageFormat format. For example, when the message:
Welcome, {0} {1}!
is invoked with the parameters ("John", "Smith"), it will be rendered as:
Welcome, John Smith!
Translated messages should retain the indices and intended meaning of the original message's parameters.
To invoke an internationalised message on a UI template, simply use the $msg global Velocity variable, which corresponds to an
instance of com.epimorphics.registry.language.Messages.
To evaluate a message in the user's requested language, call the get method with the corresponding message identifier.
To evaluate a parameterised message, call the get method with the message identifier, followed by the parameters.
You can use Velocity's index notation to make these
calls more concise.
<h1>$msg['example.page.heading']</h1>
<p>$msg.get('example.page.welcome', $user.firstName, $user.surname)</p>If you have customised the UI templates with additional messages, you can create unique identifiers for them and add them to your messages files to make them invocable in the same way.
The registry UI uses the data tables plugin to render some table elements.
The text elements rendered by the plugin can be translated by providing a translation file in the
ui/assets/js/locales/dataTables directory of your registry configuration.
The translation file should contain a JSON object and be named by the language code that it corresponds to,
for example en.json.
The translation will be applied to the tables on the registry UI automatically.
See the here for a list of translation files that are ready to use.