views:

1170

answers:

3

I am currently working on converting an existing web application to support an additional language (namely Welsh). My proposed approach is to extract all displayed text into property files and then access the text using JSTL fmt tags.

My question is: how should these property files be structured? I know they need to be on the classpath for the web application, but rather than storing them directly in WEB-INF/classes I would prefer to copy them there during the build step. This leaves me a lot of flexibility in how to store the files in subversion. Since they are closely aligned with the jsps is it a good idea to create a new top-level directory (e.g. resources) and mirror the jsp structure under this folder? This would give me a structure like

resources/jsp/index.properties
resources/jsp/index_cy.properties

This seems like a reasonable approach and it is extensible to property files for classes too, if they should be required:

resources/com/mycompany/myapp/CustomObject.properties
resources/com/mycompany/myapp/CustomObject_cy.properties

The build process could then copy all of these files into WEB-INF/classes ready for packaging into the war file.

Is this approach in line with industry standards? This is the first multilingual application for my current company, so it is likely to be used as a blueprint for all others.

Edit: It has been pointed out that this approach could lead to a lot of duplicated strings in the various property files. While this is true, it would only be as many duplicated strings as currently exist in the jsps. Is it better to have a clear mapping from jsp to property files, at the cost of some duplication in the property files?

+2  A: 

Is this approach in line with industry standards? This is the first multilingual application for my current company, so it is likely to be used as a blueprint for all others.

Yes, I think it is.

I believe Maven creates the following directory structure:

src
  +- main
  |    |- java
  |    |- resources
  +- test
       |- java
       |- resources

Which gives you a nice clean separation between your code and unit tests, and then between java code and resources such as property files etc.

Phill Sacre
A: 

I'm not sure it's a good idea to establish too strong a connection between the resource files and the code files that use them, since it could lead to unnecessary duplication of texts that could be reused.

This is especially problematic when the texts are translated by a third party, since the same expression, when occurring multiple times in different files, might be translated differently, which can greatly confuse the user.

I'd structure the resource files separately, and try to find an organization that makes sense inherently, e.g. UiLabels.properties, ErrorMessages.properties.

Michael Borgwardt
That's a very good point, as quite often the same label will be used across multiple jsps.
Caroline Orr
However, the current suituation is also that the same string is duplicated whenever it occurs on more than one page (or even more than once on the same page!). So I would be tempted to create a unique key for each instance of the string anyway, to allow contextual flexibility.
Caroline Orr
Reuse of strings in different locations is generally considered a bad idea as translations may be more context-sensitive than they are in source English. It is up to the translation specialists to set out translation guidelines to keep text consistent.
McDowell
+1  A: 

It has been pointed out that this approach could lead to a lot of duplicated strings in the various property files. While this is true, it would only be as many duplicated strings as currently exist in the jsps. Is it better to have a clear mapping from jsp to property files, at the cost of some duplication in the property files?

Yes, this is always better. While it is possible to 'reuse' a string at different places / JSPs in English, it still might not be possible in other languages. Reuse of localized strings could also create unwanted and tricky dependencies between components that are otherwise unrelated. The translators also need to be aware of use of texts they translate in your application.

david a.
I disagree strongly - IMO this is nearly always worse; of course you should not "reuse" strings on a word level without thinking about it; but usually the dependencies created this way are absolutely wanted: if you rename a field, you usually want it renamed everywhere, and translated consistently.
Michael Borgwardt