Re: i18n
"Sasvata (Shash) Chatterjee" <[email protected]> Sun, 28 Aug 2005 21:19:56 -0500
| Newsgroups | gmane.comp.java.keel.devel |
|---|---|
| Message-ID | <[email protected]> |
Raoul,
> 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).
>
OK...I'll grab them in the next update I do (I have too many changes
to risk an update at the moment :-)).
> 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...
>
I still see them...but as long as I know that the files in
conf/client/struts are not needed, I'll clean them up in the next set
of checkins I do, if necessary.
>>
>> - 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.
>
> <snip>
OK...that's great, I'll start using this capability soon.
> 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?
>
+1
> 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?
I think conf/common/resources sounds great, we can modify the Maven
plugin to put this in both the client and server JARs. Have you tried
the JMS build to make sure that the server-side Translator class
works? Now that we don't enforce a different classloader (since Maven
build), it is easy to get bitten by this if developing only in a
webapp/direct Keel mode.
Shash
http://keelframework.org/documentation.shtml
Keelgroup mailing list
[email protected]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com