When configuring client items in Weave it's possible to set the text displayed to the user for various items directly, this is generally done by setting a 'label', 'text' or 'tooltip' type of properties for the items.

Previously when these values were set they would completely replace the value displayed for every user, however version 2.4.7 of Weave introduced a way to set these values indirectly and have a different value provided to the user based on their location.

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.
Note that as of version 2.4.12 this is no longer the case, and any item that's sent to the client will allow this.

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.

Referencing the text item is performed by prefixing the texts id with % where you'd usually put the text, for example

Original Search panel definition contained within a larger client:config item

	<view id="com.cohga.html.client.main.searchView">
		<label>Search</label>
		<location>west</location>
	</view>

would be become

Localised Search panel definition

	<view id="com.cohga.html.client.main.searchView">
		<label>%search.label</label>
		<location>west</location>
	</view>

To actually define the text to be used you need to create a separate client resources item

Setting the default resource value for search label

<client:resources>
	<resource id="search.label">Search</resource>
</client:resources>

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.

You can create as many resources configuration items as you like, this allows you to either keep one single large resources section or break them up and locate them close to the items that they're used in.
Keeping them in a separate file and including them into your configuration is also a useful way to reduce clutter.

The above example is intended to show the syntax required to configure text for localisation, and in itself hasn't really provided us with any advantage, since all we've done here is to replace the default text displayed for every client and that would've been easier just to replace the text directly.

However, the real point here is to allow the text to be changed for each user based on their preferred language, and the way we do that it to create another client resources item that contains the alternate text and specify what locale the user should ask for for that text to be used. To do this we duplicate the existing resources item and set a lang property for the resources, for example:

Setting alternate resource values for search label

<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.

The original resource item didn't set a lang property, so it will be the default value for any properties that haven't specifically been overwritten by locale specific versions, so someone from Italy would see the English label for the search panel.
The default value could have just as easily have been specified in Italian and an English specific resource could have been created (using 'en' and the language) if the site is intended primarily for Italian speaking users

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

Alternate resource syntax

<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

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.

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.

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.

Browser not supported