Internationalization of applications

Support and Announcements for the LDS Tech Java Web Application Platform (setup, configuration, bugs, feedback).
Posts: 100
Joined: Mon Mar 29, 2010 2:11 pm
Location: Utah, USA

Internationalization of applications

Postby YoungstromMJ » Wed Apr 07, 2010 12:25 pm

This is an email thread between Chris Chapman and Mike Neilson about internationalization. I wanted to move it here for further discussion.


-----Original Message-----
From: Chris Chapman []
Sent: Wednesday, April 07, 2010 11:08 AM
To: Michael Nielsen
Cc: Neal Midgley; Paul Wilhelm; Josh Cummings;
Subject: Re: Timeline Localization

Thanks, Mike

I wasn't very specific about my localization question. Let me try again. The
current db schema has a timeline table and an event table. Each of these
tables has an attribute that references a language table. The language table
has three attributes: CODE, NAME, DESCRIPTION. The plan has been to make these
timelines and events available in multiple languages. What I was wondering is
whether it is possible to take out the language table and use Java locale or
ICU4J for the language codes for a timeline or event, or if these libraries
are not robust enough for the Church's language requirements and we need to
implement and/or extend the ISO standards ourselves?


On Wednesday 07 April 2010 10:45:28 am Michael Nielsen wrote:
> Generally what we've done for localization is put the strings in a
> properties file and for database strings, we have a table with a language
> code and the strings located there.
> However, I need to verify that the new stack still recommends doing it this
> way. I was under the impression that things have changed. I'll check
> with the community guys today.
> I know Paul and Neal are still having trouble getting the app running. I
> haven't taken a look at it yet. I will have some time this weekend to look
> at it.
> I think going forward, we should at least take into consideration
> localization and build it with localization in mind.
> Neal's email is
> -----Original Message-----
> From: Chris Chapman []
> Sent: Wednesday, April 07, 2010 5:52 AM
> To: Paul Wilhelm; Michael Nielsen; Josh Cummings
> Cc: Robert Husted
> Subject: Timeline Localization
> I do have a question about localization. What is the stack standard for
> localization? I was not able to make it to the localization deep dive last
> week. (I wish I could have attended all of them!) From what I know, we can
> use a pre-built solution (like Java Locale or icu4j) or roll our own. I
> kind of hesitate to roll our own, unless that is common with Church
> applications. What is commonly done?
> Were any of you able to get the timeline app working with Oracle? Robert
> has updated the timeline-db project with an Oracle schema. It includes a
> language table with foreign key constraints, which is why I am asking
> about localization now. I don't know whether to start creating language
> objects or to just save a language code (from a Java library) to the
> database.
> Also, does anyone know Neal's email address? I couldn't seem to find it.
> Thanks,
> Chris

Posts: 100
Joined: Mon Mar 29, 2010 2:11 pm
Location: Utah, USA

Postby YoungstromMJ » Wed Apr 07, 2010 12:39 pm

Currently we try to use Java Locale wherever possible. ICU4J is an option if you need features it provides and the project is willing to take on the complexity of it. Though for the most part we try to just stick to Java Locale.

As far as managing current locale we use Spring MVC's I18N support:

Reference docs are here:

Messages are resolved using an implementation of MessageSource

And displayed on a webpage using the "spring" taglib. Though if you're developing a JS UI then you'll have to figure out some custom way to do the translation as we don't really have a standard mechanism yet and I'm not aware of what projects are currently doing for I18N of JS UI apps.

Here are the taglib docs for Spring's taglib. "message" is going to be the primary tag for displaying I18N messages in a JSP.

Does that help at all? Adding good MVC I18N support for our petstore app is high on our list of things to do.


Posts: 100
Joined: Mon Mar 29, 2010 2:11 pm
Location: Utah, USA

Postby YoungstromMJ » Wed Apr 07, 2010 12:49 pm

In case I wasn't clear above. If you wanted to use a database to store your localized strings then you simply need to create an implementation of MessageSource that queries the DB and does optional caching. We don't have a hard and fast standard about using properties files vs. DB backed properties. It's largely dependent upon the requirements of the project.

If you need to be able to update internationalized strings without deploying a new version of the app then use DB strings. Otherwise use might use properties files.

Or you might want to do both. Check properties files first then db.

New Member
Posts: 15
Joined: Mon Apr 05, 2010 10:38 am
Location: UT, USA

Postby christopherchapman » Wed Apr 07, 2010 12:59 pm

Thanks Mike, that helps point us in the right direction. The localization support for Spring MVC 3 is really nice, though it will not help us much since we are doing the UI in javascript. It does make the domain model and database schema a bit simpler though. :)

Posts: 100
Joined: Mon Mar 29, 2010 2:11 pm
Location: Utah, USA

Postby YoungstromMJ » Wed Apr 07, 2010 1:01 pm

Yeah, perhaps I can get Tom to post how Calendar is planning to do it's I81N.


Posts: 100
Joined: Mon Mar 29, 2010 2:11 pm
Location: Utah, USA

Postby YoungstromMJ » Wed Apr 07, 2010 1:08 pm

Tom's on vacation but I'll see if I can get someone else with some insight to post some ideas.


New Member
Posts: 1
Joined: Thu Apr 08, 2010 7:32 am
Location: Riverton, Utah, USA

I18N internationalization approach in Calendar and Directory

Postby terrydm-p40 » Thu Apr 08, 2010 3:51 pm

I will not attempted to describe in great deal the complete implementation, but rather a basic framework for internationalizing applications that use javascript for the front end presentation. This approach presents a couple of challenges. One of the largest is the fact that one needs to dynamically load and display strings, dates, etc based on the users language preference.

To handle this problem we have implemented rest service calls that delivers all the needed translation Strings and resources to the client based on the page that is being displayed. The resources are sent to the client in JSON format where the client can assign the JSON data to a Javascript variable. This variable is a handle to the JSON object and that its elements can be used to retrieve the actually value that is used in the display.

for example

var localeData;

function(locale) {
$.getJSON('restURI/Resources/' + locale,
function(localeData) {
if (localeData) {
userLocaleInfo = localeData;
function(data) {
// place a call to the function that will do the page rendereding here. Within this function just access the localeData.??? element that you need at the appropriate points.

This function is place in the Jquery Document Ready method, so that it will be able to retrieve the needed resources before any thing else can reference the localData variable.

On the server side of things there are two services


which returns the users locale. The logic for determining the users locale is based on the church standard. One the appropriate locale is determined the result is sent to the client. (we actually return the java locate but you could use what ever is appropriate)

(Note: the Rest URI can be anything you want, so for these example I and using restURI/?????)

and a second service

this server is used to lookup the resource strings which can be JSONed to the client. This service may use any one of a number of implements to get the resources, but you will want to get all the resources for a "page" at once to reduce the number of calls to the server. The "page" name can be the actual html file name or some name that both the client and the server can agree upon for grouping a set of related resources.

In the calendar and directory the implement is based on a interface that always us to treat all requests as if there are accessing property files but the implementation could be pulling rows from a database. The implementation just pulls the "properties" from the agreed upon name for the specified locale and sends them to the client.

Things that you application may want to include is a way to cache the resource, acquiring the resources from a database rather than properties, etc. but these are just implementation details that any server programmer should have a handle on.

Return to “Java Web Project Support (Stack)”

Who is online

Users browsing this forum: No registered users and 1 guest