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