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:
- Find all the *.properties files (
)Code Block find . -name *.properties
- Add a new set of properties files for your language with a file name _*xx.properties and translate all the strings
...
Panel |
---|
find path/to/sipXconfig/sources -name *.properties | xargs grep "=Active" |
HTML pages localization
All template (.html) and component/page definition (.page, .jwc) files are kept in:
Panel |
---|
sipXconfig/web/context/WEB-INF |
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:
No Format |
---|
Panel |
<p>Harcoded string</p> {panel} |
with:
No Format |
---|
Panel |
<p><span key="myKey">this will get replaced by value read from .properties</span></p> {panel} |
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.
No Format |
---|
Panel |
<p jwcid="@Insert" value="message:myKey" raw="ognl:true" element="p"/> {panel} |
With this method you can use HTML tags in your properties file
Panel | |
---|---|
myKey= No Format | <em>Hardcoded</em> string |
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
...
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.)
...
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.
...