What is the proper way to internationalize a large web app?

[Paul Vincent Craven]

I've seen about 3 ways to internationalize a web app. I'm looking for
opinions from people that have actually internationalized a large app.

Here is what I've seen:

1. Pull all strings out of web pages and put in resource bundles.
This appears to be very popular in web site tutorials.
2. Use different JSP's with extensions based on locale and language.
This is Sun's J2EE recommended pattern. E.g:
index.jsp
index_en.jsp
index_es.jsp
index_US_es.jsp
3. Put JSP's in different directories, and have the directory carry
the extension. I saw this in a portlet sample code. Example:
docs/index.jsp
docs_en/index.jsp
docs_es/index.jsp
docs_US_en/index.jsp

I'm sure there are other options. Here are my problems:
1. I hate the idea of pulling every string out of my JSP. This would
be a lot of work and hard to maintain. Very difficult to use any
visual editor on such a file.
2 and 3: If you change one JSP, you have to change the JSP's for
every other language.

Is there something better? Is one of these solutions better than another?

Paul Vincent Craven
(e-mail address removed)
http://www.cravenfamily.com

 

[Mladen Adamovic]

That problem I resolve with class Language i.e.

language=new Language(selectedLanguage);
welcomeString=language.welcomeString();
....

class Language get data from textfiles or database...

Avoiding that _us, _fr, _ge extension and multipling unneccesery data.

 

[Digby]

I'd go for 1, despite your reservations. The whole point of
internationalising a JSP is that you have one view (the JSP) and it picks up
the relevant translations. It's not a burden to maintain the .properties
files, and it means all your translations are in one place - this is the
whole point of ResourceBundles. I haven't come across the other ways you
mention, but they sound like a lot more work - maybe IDEs don't support it,
but they don't support multiple index.jsps either.

Look at it from your translator's point of view: would they rather be given
a text file to translate words one-to-one, or a JSP, where they can mess up
your code at will.

Digby

 

[Paul Vincent Craven]

I'd go for 1, despite your reservations. The whole point of
internationalising a JSP is that you have one view (the JSP) and it picks up
the relevant translations. It's not a burden to maintain the .properties
files, and it means all your translations are in one place - this is the
whole point of ResourceBundles.

I see the ResourceBundles as the popular way to do things, but it
makes no sense to me.

One big resource file wouldn't work. For a site of any size,
centralizing all the text into one big text file is impractical. You'd
have to do a per-page resource bundle, wouldn't you?

Imagine deleting a page in the one-big-resource file way. You now have
to go though the property file and match every tag in that page with
the tag in the property file. Then delete it out of the property file.

Oh wait, what if it was a common text setting? You might have deleted
something out of another page.

But if I leave it there, I've got this text hanging around I don't
use.

Which brings another point. Say I modify a resource bundle. If all
pages reference that 1 resource bundle file, proper QA would then
require retesting the whole site. If you modify only 1 jsp, then you
only need to test that 1 jsp.

And how many text tags are in a page? If you include alternate image
text, it could be a lot couldn't it? We'd be talking thousands of
entries.

I just don't see how you could manage that except for a trivial
example.

I haven't come across the other ways you
mention, but they sound like a lot more work - maybe IDEs don't support it,
but they don't support multiple index.jsps either.

Sure they do. I double click on the JSP, and I can edit it just fine.
If I double click on a JSP that has no text, it is really hard to find
my way around it.

Look at it from your translator's point of view: would they rather be given
a text file to translate words one-to-one, or a JSP, where they can mess up
your code at will.

Um, I don't have a lot of code in my JSP's. I keep it out as much a
possible. Most editors a translator would use, would just ignore the
special tags.

If I was a translator, I'd rather translate in the context of page
itself. Would you rather translate Spanish to English on a sentence by
sentence basis, or an entire paragraph? I'd rather have the whole
context. What if a different language requires you to fine-tune the
width of a table? Or include a different image that has different text
on it?

What I'm really interested in, is someone who has worked on site X.
Site X has at least 30+ JSP pages on it. Site X supports multiple
languages. They have for at least 6 months in production.

What works for them? Do they do the Resource Bundle only way? How do
they get around the problems I mentioned? Is there a better way?

Paul Vincent Craven
(e-mail address removed)
http://www.cravenfamily.com

 

[Jeff Kish]

Which brings another point. Say I modify a resource bundle. If all
pages reference that 1 resource bundle file, proper QA would then
require retesting the whole site. If you modify only 1 jsp, then you
only need to test that 1 jsp.

If you modify a jsp, chances are you want that modification reflected in all
of your languages anyway, right? And if you are just
correcting a one off mistake, well sometimes good QA is
better (more realistic/acceptable) than "proper" QA.

And how many text tags are in a page? If you include alternate image
text, it could be a lot couldn't it? We'd be talking thousands of
entries.

I just don't see how you could manage that except for a trivial
example.

<snip>

HTH,

Jeff Kish

 

[Guest]

If I was a translator, I'd rather translate in the context of page
itself. Would you rather translate Spanish to English on a sentence by
sentence basis, or an entire paragraph? I'd rather have the whole
context. What if a different language requires you to fine-tune the
width of a table? Or include a different image that has different text
on it?

What I'm really interested in, is someone who has worked on site X.
Site X has at least 30+ JSP pages on it. Site X supports multiple
languages. They have for at least 6 months in production.

What works for them? Do they do the Resource Bundle only way? How do
they get around the problems I mentioned? Is there a better way?

Let me say up-front that I have *not* been involved in the localization
of a large JSP-based application. However, I have been involved (in
fact supervising) several very large localization projects in the
past.

Your points above are quite valid. The process we followed was that
the localization was handled by a small number of technical experts
who dealt with the technical issues, and a larger number of translators
whe translated the text in message catalogs (for which you can read
"Resource Bundle" in this case). The translations were regularily
merged back into the application and the experts would verify that
nothing had broken.

Your frustration probably comes from dealing with an application
which was not designed with localizability in mind in the first place.
There are several excellent publications on the subject, you might
want to go to a computer book store and see if any look good to
you. The short-short guide to designing for localizability is:

1. Never use words when you can use a graphic
2. Use as few words as possible when you do need to use words
3. Present all words in a full sentence context so they can
be translated properly without reference to the original app.

If your application cannot be designed around these guidelines,
than it simply may not be localizable at all, and should be
rewritten from the ground up for each locale that it will be deployed
in. Not everything is localizable. For example, many US e-commerce
sites simply do not map to how people in, say, Japan, do business.
Or, for that matter, conform to local trade laws, cultural expectations,
etc. In a case like this a total rewrite really does make sense.

Don't know if this helps or not.

--arne

DISCLAIMER: These opinions and statements are those of the author and
do not represent any views or positions of the Hewlett-Packard Co.

 

[John O'Conner]

Your frustration probably comes from dealing with an application
which was not designed with localizability in mind in the first place.
There are several excellent publications on the subject, you might
want to go to a computer book store and see if any look good to
you. The short-short guide to designing for localizability is:

1. Never use words when you can use a graphic
2. Use as few words as possible when you do need to use words
3. Present all words in a full sentence context so they can
be translated properly without reference to the original app.

Although the site is in the middle of a major redesign, you can still
see lots of help/tips for java internationalization here:

http://www.joconner.com/javai18n/

Regards,
John O'Conner

 

[Paul Vincent Craven]

Ok, here's my take:

Text in ResourceBundle files for internationalization:

Advantages
* All text is in one place
* Easier to have common text between files
* Do not need to change multiple JSP's when page structure changes
* Don't have to worry about translators stepping on code when changing
the JSP
* Don't have to go through a servlet to decide which JSP to include

Disadvantages
* Additional development work in cross-referencing text to labels
* No easy way to find unused labels
* Not immediately obvious when a text field is missing (have to run
app and look at the page)
* Looking at the JSP in an editor gives little feel for how the file
actually looks when the text and some images don't appear
* Resource file will get very large for text-heavy sites
* Requires a lot of effort in supporting text-heavy pages, like help
files, disclaimers, etc.
* Translators will do the translation in a text file, and not see how
the translated text will appear on screen.
* Additional development step required in pulling text out of a JSP.
If a site isn't translated and this step is still performed, this is
wasted effort.

Miscellaneous
* References to images with text on them will also need to be in the
ResourceBundle
* Images who's size changes based on text width will need to be
specified in the resource bundle
* Table width sizes will need to be moved into a resource file, if
needed by different widths of text.

Other points? Any thing I've got wrong?

Paul Vincent Craven
(e-mail address removed)
http://www.cravenfamily.com