1

We have a huge project with more than 100 Custom Controls and XPages in place and now we intend to provide the project in multiple languages.

Localization in XPages, provides this beautiful and a very simple way to convert the entire project in the other language via the properties file. However, in our case, many custom controls are kind of carbon copies of others and many of the translations/keywords are the same, it becomes kind of redundant to change the same thing again and again.

So the question is, is there a simpler approach, where we can probably do a bulk of translation together? Something, where we can export the entire translation as one file and import it back?

Any suggestion/help in the right direction would really be appreciated.

Chintan Parekh
  • 1,101
  • 1
  • 12
  • 31

2 Answers2

4

Don't use XPage's build-in localization. It might work for a first translation but it's very difficult to maintain after (a lot of) changes in XPages.

Use a managed Java bean instead.
It manages own property files and implements Map interface.

You'd use the bean to get a string usually with EL.

Example:
Get name's label with str['name'] for following entry in property file

name=Name

Use java.text.MessageFormat for messages with data.
Create a method like getMessage(String name, Object arg1) in your bean.

Example:
Get the message for a missing view in JavaScript with
str.getMessage('message.view.not.found', viewName) for following entry in property file

message.view.not.found=Could not find view {0}
Knut Herrmann
  • 30,880
  • 4
  • 31
  • 67
  • Ah ok, never really worked with beans, however, it seems promising..will just look into it..Do you think there is any other solution possible with the Localization concept? or it is just something to be used for smaller projects? – Chintan Parekh Oct 23 '15 at 05:37
  • 1
    Build-in localisation might work for small projects or projects you won't change in future. We looked into this and especially what happens if you change XPage's elements like its ids. It seemed to us it's very difficult to handle it. So, we decided to use a managed Java bean instead, Once we started with it we added more functionality to it like using a cascade of property files like one with general strings valid for all applications and another application specific file. We like this approach a lot. – Knut Herrmann Oct 23 '15 at 07:04
  • Ya, still working on it, but I kind of see the advantage. Will just give it a day or two to find some more suggestions, otherwise this seems to be a proper way to approach. Thank you. – Chintan Parekh Oct 23 '15 at 07:40
1

Another approach would be to use manually created property-files

Here an example for two languages:

First of all you have to create the following two files under Resources/Files

messages.properties

global.welcome = Willkommen {0} auf meiner Webseite

messages_en.properties

global.welcome = Welcome {0} on my website

Now you can reference your message properties on every place in your code

<xp:this.resources>
    <xp:bundle src="/messages.properties" var="resMessage"></xp:bundle>
</xp:this.resources>

<xp:text escape="true" id="cfUser" themeId="Text.User">
    <xp:this.value><![CDATA[${javascript:I18n.format(resMessage['global.welcome'], sessionScope.commonUserName)}]]></xp:this.value>
</xp:text>
Georg Kastenhofer
  • 1,387
  • 12
  • 32
  • Thank you. Have tried this, but involves referencing the element everytime while creating a new element; With property files it usually just maps it automatically. – Chintan Parekh Oct 23 '15 at 07:41