Introduction

As with many things, only the first time something new is tried it is really difficult. Doing it again becomes a lot easier. That applies to localization. The first two languages we are implementing for sipXconfig are German and Polish. Adding another language is really simple:

1. Find all the *.properties files

   Code Block
   find . -name *.properties

2. Add a new set of properties files for your language with a file name _*xx.properties and translate all the strings

Done!

Many words common to all pages (Name, Description etc.) are localized in the common message repository:

If you see something on the screen and are not sure where to add translation for it, you can use grep to find the specific file. For example to find all the places where 'Active' is translated run this command:

HTML pages localization

All template (.html) and component/page definition (.page, .jwc) files are kept in:

Template (.html) files

sipXconfig is a Tapestry application. You can read more on localizing Tapestry applications here

All hardcoded string need to be replaced with the references to named properties (keys). For example to replace Harcoded string in the markup below you need to replace:

with:

and add myKey to the .properties file:

If you want to instert a localized text that with HTML markup in it use @Insert component instead of span method.

With this method you can use HTML tags in your properties file

Specification (.page and .jwc) files

You need to replace "literal:Hardcoded string" binding with "message:myKey" binding and add myKey to properties file.
You have a choice of adding the key to component/page specific properties file (i.e. if Login.page that would be Login.properties) or to global message repository -
sipXconfig-web.properties

For example if you have the following in common/ItemCommon.jwc:

replace it by:

And add key 'enabled' to common/ItemCommon.properties or to sipXconfig-web.properties.
You can try running:

to find unlocalized strings. Some of the literal bindings should not be localized: for example internal page names.

Models localization

It works in a very similar way to translating the pages. For every model file (eg. snom/phone.xml) there is a property file (let's say
snom/phone.properties). When adding support for a new language, you add a new, localized .properties file (eg. snome/phone_de.properties for German,
snom/phone_pl.properties for Polish etc.)

For those using Eclipse your JInto plugin should work.

Full setting name followed either by '.label' or by '.description' is used to idenfity properties for settings labels and descriptions. To continue with SNOM example:

In phone.xml we have:

In phone.properties

The system will default to whatever is in XML file if it does not find a property. However if the
property value is empty it'll display empty string.

If you want to start translating model that does not have .properties file, you can run xml_to_properties script to
generate skeleton file with English labels skimmed from xml file.

If started with no options it behaves as filter - reads standard input and writes to standard output.

Enumeration types labels localization

You can optionally localize the labels for enumeration settings. Those settings are displayed in UI as a drop down selection list widget: user selects a value from the small set of options rather than typing in the correct options.
There are options that you probably do not want to localize (such as protocol names: UDP/TFTP?) but in many cases localization would increase usability.

There are couple of ways in which labels can be localized. If the enumeration type has an id, you can use it to construct the keys for the labels. For example:

You'd need to put the following keys in the .properties file corresponding to the model.

As you can see you can localize an empty value as well.
It is perfectly valid not to localize some of the options. In such cases do not add the key at all. Adding empty key would make sipXconfig to display empty label instead of default (English) one.

If type does not have to id you can explicitely set the label key prefix ("type.ringer-pattern" in the example above). You need to modify enum elemenent in xml file. For example:

In this case your properties need to look like this:

Finally you can use the setting name as a prefix for the label. This works best if enumeration is used only for a very specific setting.

In this case your phone.properties will have to include the following keys: