I am just looking into how my project might handle the i18n concens of Dust templates and JS generated text. It seems we've landed upon the librbary
i18next. Regardless of the library choice however, I'm guessing most client side message resolution is going to require a JSON object containing message keys to message values (in a particular language).
I'm thinking wro4j could help us out here quite a bit - we could make use of its caching and neat framework. So the need for a MessagePropertiesProcessor seems to be emerging.
What I imagine my wro.xml file might look like:
...
<group name="i18n.myTable">
<js>/i18n/messages.properties</js>
</group>
...
Then my messages_en.properties:
welcomeMsg = Welcome to my site!
userStatus = Logged in as {user}
And a compiled JavaScript snippet (for English) looking something like this:
if (!i18n)
{
i18n = {};
}
i18n.myTable = {
'welcomeMsg' : 'Welcome to my site!'
'userStatus' : 'Logged in as {user}'
}
My MessagePropertiesProcessor might look roughly like this:
...
Locale requestedLocale = // Hmmmm??
ResourceBundle bundle = getBundle(requestedLocale);
...
Now the actual reading of a Java properties file and converting to a JSON object is the simple bit. The bit that I'm looking for advice over is the way in which we might decide which language properties file to read...do I look at the request and check for a GET param 'lang'? I figure this isn't going to work if the resource is cached and then the parameter changes from 'en' to 'fr'; we'd presumably still see the JSON for English, not French.
My current thought is to take a look at the GroupExtractor (and its implementations). Possibly when requesting groups it could be done either by requesting a particular localised version of the resources (which for most resources would be disregarded) or just the default locale's version of the resource.
For example I would request a table.js group in any of the following ways, where all would be identical assuming the group contains no message.properties files:
/wro/table.js
/wro/en/table.js
/wro/fr/table.js
And then my localised text files for specific locales like so:
/wro/i18n.myTable.js // Returns English since it's my default locale
/wro/en/i18n.myTable.js // Identical to above
/wro/fr/i18n.myTable.js // French version
I don't think I've got all of the design figured out yet though - caching is still of concern.The easiest way might be to maintain copies of each resource in the cache as many times as they are requesting in different locales, regardless of whether their content differs.
Is there a better way? Maybe this would be quite neat..having a new PreProcessor interface:
public interface LocaleAwareResourcePreProcessor extends ResourcePreProcessor {
void process(final Locale locale, final Resource resource, final Reader reader, final Writer writer)
throws IOException;
}
Thoughts and suggestions..?