Re: i18n

Shash,

> - I could use this, so started trying already.  I ran into a problem 
> about the keel-resources.xml file not parsing, SAX complained that it 
> is not well-formed after root elements.  I enclosed the generated file 
> withing <resources></resources> (just made up the root element), and 
> it worked.
>
Oups! As you stated in your next email I forgot to commit 
keel-client/conf/client/snippets/resources_{prefix,suffix}.xml. It's 
done now.

The root element is <resources-list> (note: there is a DTD in 
resources_prefix.xml).

> - Looks like the old resources are still under conf/client/struts.  
> Hopefully, we don't need to duplicate, right? Same set of  resources 
> can be used by both Struts/keel-client, correct?

I already removed the old resources from the conf/client/struts 
directory in CVS. And when I update my local repository I get  removed 
messages. So...

>
> - Since the i18n code is in keel-common, it'd be really cool to share 
> the same resources between both the Keel client and server sides, if 
> one wanted to. 

Yes. And it's already possible. I have begun to translate some server 
side exception messages.

You even have the choice:
- with dynamic message, see i.e. AbstractPersistent in svc-persist-base 
or DefaultPersistentBase in svc-persist-default;
- with org.keel.util.i18n.Translator class, see StandardLogEnabledModel, 
ThreadedLogEnabledModel, DefaultModelResponse and DefaultModelRequest.

I think it's better to translate messages as soon as possible. That's 
why I prefer Translator class to dynamic messages.

As Translator uses a logger, I implemented it only in the four above 
classes. But Translator uses System.err.println if no logger is 
available, so it's possible to use it anywhere.

It's the responsability of each sub class to overwrite, if needed, the 
attributes:
- bundleBasename
- logPrefix
- keyPrefix

See i.e. DefaultModel in svc-model-defaultmodel.

Todo: at the moment, Tranlator uses the base name of the bundle file to 
load it. It will be nice if we can give it the key of a bundle, like 
with dynamic message. But I don't think it's a blocking point: on server 
side, I can"t figure a case where  we don't know the resource file to use.

A last point: I derived Translator class from Keel Message class. I'm 
not sur it's a good idea: a Translator isn't a Message. But I was a 
little lazy, so...
May be we can rewrite Translator with Message as an attribute?

> We could put a translator class in keel-server as well, and we'd have 
> to package resources both in the client and server JARs.  That way 
> even error logs and such could be i18n-alized.

Yes: Translator is in keel-common. So I think that it's already packaged 
in server jars.

About  packaging of resources: I don't know. As DefaultModel uses 
KeelFrameworkResources from keel-common, there is no trouble at the 
moment. But it'd be cleaner if each server side module can define its 
own resources.
Then what about a server/client neutral place to the resource files? Sth 
like conf/resources or conf/common/resources? Or may be directly under conf?

Pierre


http://keelframework.org/documentation.shtml
Keelgroup mailing list
[email protected]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com