Re: [enhydra] i18n of Enhydra apps

[Mathieu MANGEOT-NAGATA <mangeot@xxxxxxxxx>]

Well, in our application (http://www.papillon-dictionary.org) we use another system for i18n:

Instead of having an id for each string we want to localize, we localize an entire html page and then,
during the execution time, when the user is resqusting a certain page, we take its preferred language list and
we serve the html page corresponding to the best language match.

We are working with very different languages (like French, Japanese, Thaï, Arabic, etc.), thus
we think that localizing only one string is nto adequate because very often, the length of the strings will be
very different among languages, furthermore, there are languages written from right to left, or from top to
bottom, etc. 
For example, it is very easy to adapt the width of a table to the longest word in a given language, or to indicate
special data in a given language (like the xml:lang or the lang attributes).
It also forces you to keep consistency and coherence in the whole HTML page. You have everything translated
or nothing. I really don't like when some website propose you a Version Française link, and when you click,
half of the strings are translated. I'd rather read the English version!

So far, our experience has been quite positive.

The difficult choice you have to make is the level of fragmentation of your html pages in order to have 
a good balance between the coherence of the html pieces easier to localize and the inconvenient to copy and paste 
the template page everytime you modify the structure of the HTML page.

To summarize:

If you deal only with similar languages, like roman languages, it may be easier to deal with strings and IDs,
otherwise, I tend to think that our solution is better.

Here is an excerpt of the code from Gilles Sérasset that loads the appropriate page for a given language:

/*
* papillon project
*
* MultilingualHtmlTemplateFactory.java
*
* © Gilles Sérasset - GETA CLIPS IMAG
 */
private final static String PACKAGE = "main.presentation.html.";
private final static String ORIG_PACKAGE = PACKAGE + "orig.";

private final static String DEFAULT_LANGUAGE = "eng";

/**
* Return an HTML Template object that is an localized instance of the
* requested class. The language of the returned object depends on
* the HTTPRequest (which contains the user's preferred languages).
*
* @return The localized HTML Template Object
*/
public static java.lang.Object createTemplate(String htmlClass,

HttpPresentationComms comms,
PapillonSessionData sessiondata)
throws HttpPresentationException
{

ArrayList languages = sessiondata.getUserAcceptLanguages();

int i = 0;
java.lang.Object template = null;

while (i != languages.size() &&
(template = getTemplateForLanguage(htmlClass, (String)languages.get(i), comms)) == null) {
i++;
}
if (i == languages.size()) {
try {
template = comms.xmlcFactory.create(Class.forName(ORIG_PACKAGE + htmlClass));
} catch (java.lang.ClassNotFoundException e) {
throw new HttpPresentationException("ERREUR:", e);
}
}

return template;

}

public static java.lang.Object getTemplateForLanguage(String htmlClass, String lang, HttpPresentationComms comms) {
String className = PACKAGE + lang + "." + htmlClass;
java.lang.Object template = null;

try {
template = comms.xmlcFactory.create(Class.forName(className));
} catch (java.lang.ClassNotFoundException e) {
}
return template;
}

Mathieu

On 19 janv. 04, at 21:19, Petr Stehlik wrote:

> On Mon, 2004-01-19 at 12:34, Sinisa Milosevic wrote:
> > Hi,
> >
> > You can use scenario like in CacheAdmin enhydra application. All
> > multilanguage labels in HTML pages can be dynamically changed from java
> > code. For every labels 'id' attribute must be set in HTML pages. For every
> > language - different property file with the same key words. In that case you
> > can translate HTML pages using different property files. But you must change
> > your application - presentation layer...
>
> That is the manual work I would like to avoid.
>
> How about something more automatic. Say that for each tag with a certain
> class XMLC would automatically extract its firstTextNode() value and
> also its title and value attributes' values to a special file and then,
> upon writeDOM it would automatically load the appropriate language file
> and replace the text strings. It would be similar to 'CLASS="discardMe"'
> approach for automatic striping of unneeded nodes.
>
> The language files could be based on gettext.
>
> Petr
>
>
>
>
> --
> You receive this message as a subscriber of the enhydra@xxxxxxxxxxxxx mailing list.
> To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Mathieu MANGEOT-NAGATA
Visiting Researcher National Institute of Informatics
Hitotsubashi 2-1-2-1913 Chiyoda-ku Tokyo 101-8430 Japan
Tel: +81-3-4212-2672    Fax: +81-3-3556-1916
http://www-clips.imag.fr/geta/mathieu.mangeot
Papillon project: www.papillon-dictionary.org

Attachment: smime.p7s
Description: S/MIME cryptographic signature