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
Keelgroup@list...
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com