...
| Warning |
|---|
Currently this localisation method is only available for properties set within a client config, so for example it's not yet possible to specify localised labels for an entity or a search using this method. |
The actual values to be displayed to the users are set in a separate client resources configuration item, where you outline the text to be displayed to the user and give each piece of text a unique id, then reference that id where previously you'd use the text directly.
...
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
<client:resources> <resource id="search.label">Search</resource> </client:resources> |
| Note |
|---|
The client resources item is not embedded within the client config, and is a separate top level configuration item in its own right and would be included at the same level as the client config item. |
...
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
<client:resources lang="sv"> <resource id="search.label">Hitta</resource> </client:resources> <client:resources lang="ru"> <resource id="search.label">находить</resource> </client:resources> |
Here we've set alternate values for the search label for Swedish and Russian users, with no change required to the configuration for the search panel and nothing required from the user.
| Info |
|---|
The original resource item didn't set a |
| Info |
|---|
Some newer client components will define their own set of resources that can be set to localise text, rather than having to set a property in the configuration of the component and then specify that the property should be replaced by a specific resource. |
Alternate configuration layout
If you need to set a lot of resources it can become quite verbose to set each item with a separate resource entry in a resources item, so as an alternative way of creating resources you can build fullstop separated items by nesting tags, for example
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
<client:resources> <search> <label>Search</label> <tooltip> <title>Search</title> <text>Search for an entity</text> <tooltip> </search> </client:resources> |
This will define search.label, search.tooltip.title and search.tooltip.text
Some default resources
The following resources are defined by default within Weave and will be used internally to represent these values.
Setting them in a resources item will allow you to change these values where ever they're used within Weave.
name | value |
|---|---|
open | Open |
close | Close |
ok | Ok |
cancel | Cancel |
generate | Generate |
new | New |
add | Add |
remove | Remove |
refine | Refine |
| Warning |
|---|
Not all component currently utilise these resources, but this will change over time as we go back and update these components to utilise these resources rather than hard coding the text within the components. |
Locale override
As of Weave 2.4.11 the user browser local can be specified by adding a 'locale' parameter to the startup url. If this is not set then the browsers default locale will be used to determine any language resources to load.
e.g. http://server:8080/weave/main.html?locale=sv
or http://server:8080/weave/index.html?locale=en_AU
Resource property files
Version 2.15.8 of the com.cohga.client.weave bundles adds support for resources defined in external properties files, rather than just in <resources> tags in config files.
All .properties files in a 'i18n' directory under the 'workspace' directory will be processed for loading of resources. The format of the files should follow the standard Java properties file format, e.g. each line should be of the format 'name=value'
If file name include an underscore, '_', in the base name then the characters after the underscore will be the locale for the resources, the part of the name before the underscore is ignored. e.g. test_sv.properties will contain Swedish resources. No underscore means no locale for the resources so they'll be used as default values.
| Info |
|---|
The file should be stored with UTF-8 encoding, although if the file contains a BOM (byte order mark) it can use other UTF encodings. |
| Note |
|---|
This encoding is different from "standard" Java properties files which assume an ISO-8859-1 encoding, but that would mean that a lot of non-ascii characters would have to be encoded using "\uXXXX" format in the file which would be too much of a pain to manage for people doing the translations. |
Finally, it's possible to zip up the contents of the i18n directory and have that used instead of the i18n directory itself.
Other text
By default Weave only performs i18n substitution of % prefixed values that are contained within the client config, so if you need to internationalise other items, for example map layer names, this will not happen by default.
You can enable i18n processing of all responses sent from the server to the client, which includes stuff like the layer names from map engines or toc model entries, you need to set the system property weave.i18n.all to true, by adding -Dweave.i18n.all=true to startup.cmd and/or weave-service.conf.
This way you can setup your underlying map engine (ArcIMS, ArcGIS, etc) to return "%map.layer.property", or for the toc model layer label, for the layer name for a Property layer, and by setting up the appropriate resources for the map.layer.property value the layer will appear in a localised name for the user.
Console
By default Windows may not correctly display UTF-8 characters in the OSGi console.
To fix this you need to change the default font for the Command Prompt to a true type font (for example Consolas or Lucinda Console) and then execute chcp 65001
This should be done before running startup.cmd, from the same command prompt window where you just entered the chcp command.
Alternatively you could edit the startup.cmd file to include the chcp 65001 command and set the command prompt as the default.