AW: AW: i18n

"Uta Kapp" <[email protected]> Wed, 27 Jul 2005 18:55:32 +0200
Newsgroups gmane.comp.java.keel.devel
Message-ID <[email protected]>
Hi Pierre,

yes, I think a shortname for each module will prevent conflicts. Since each
module usually has some unique shortname anyhow, like you used in struts,
that would do perfectly.
The AbstractWebappClientConnector would solve the cocoon and other client
message issues.

I can do the translations to German for all the modules that have
localizations.
Are there any others than app-personality?

Uta

-----Ursprüngliche Nachricht-----
Von: keelgroup-keelframework.com-admin-rI8AND0JKYOgdSakss0wQjGcDxdMUgRv@public.gmane.org
[mailto:keelgroup-keelframework.com-admin-rI8AND0JKYOgdSakss0wQjGcDxdMUgRv@public.gmane.org]Im
Auftrag von Raoul Pierre
Gesendet: Mittwoch, 27. Juli 2005 12:55
An: developers-6VIttnCrOeJXNEnpj1eHPNi2O/[email protected]
Betreff: Re: AW: [Keelgroup] i18n


Uta Kapp a écrit :

>Hi Pierre,
>
>thank you very much for the help. I think conf/client/resources is a
>good neutral place for the resource files.
>I translated messages with keys already existing
>
OK

>for crud, navigate and
>register
>
>
Do you use app-personality? There is also a properties file.

>and send them as zip file.
>
>
I received it. I'll put it on CVS this afternoon/

>A policy for property key names would certainly be usefull.
>One way could be to have a shortname for each application/model/class
>that is defined in an Interface with only static final names, implemented
by
>classes that use the messages. This would centralize the messagekeys for
the
>application.
>
>
I think about a shortname only for each module, somethink very like the
struts message resources. The shortname list would be deal with by
AbstractWebappClientConnector.

And each applicaton is free to deal the keys as it wants.

Pierre




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

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