fmt is based on bundles and bundles can be implemented the way we decide, is'nt it?
Christophe Dupriez Centre Antipoisons-Antigifcentrum C/o Hôpital Central de la Base Reine Astrid Rue Bruyn 1120 Bruxelles Belgique tel 32-(0)2.264.96.36 fax 32-(0)2.264.96.46 ----- Original Message ----- From: Andrew Jaquith [mailto:[email protected]] To: [email protected] Subject: Re: Where are messages stored? > Suggestion (2) isn't practical. The JSTL fmt: tags are defined to look > things up in particular classpath locations; ditto with the Stripes > tags. > > Andrew > > On Apr 18, 2009, at 3:27, "Christophe Dupriez" > <[email protected] > > wrote: > > > Hi! > > > > I would have a suggestion: > > 1) every message in every supported language would have a default > > version distributed with JSPWiki. > > If a language is not supported, the installation could define a > > default language. > > This would ensure that a message is always available even if > > JSPWiki is upgraded. > > 2) local version of **some** messages in a given language could be > > defined in a local configuration directory (never erased by a WAR > > deployment). If there is no local version of a message, the one > > bundled with JSPWiki is used. > > 3) If, for a given message, the number of parameters {0} changes, > > the message key would always be changed (this to ensure that if new > > parameters are added, an innapropriate message is not used) > > 4) The message files should remain editable with a tool like Eclipse > > property editor. > > > > Have a nice weekend! > > > > Christophe Dupriez > > Centre Antipoisons-Antigifcentrum > > C/o Hôpital Central de la Base Reine Astrid > > Rue Bruyn > > 1120 Bruxelles > > Belgique > > tel 32-(0)2.264.96.36 > > fax 32-(0)2.264.96.46 > > > > > > > > ----- Original Message ----- > > From: [email protected] [mailto:[email protected]] > > To: [email protected] > > Subject: Re: Where are messages stored? > > > > > >> Janne, I agree with you. Moreover given that (at least in tomcat 5.5, > >> but i believe in general) class loading order is > >> > >> * //WEB-INF/classes/ of your web application first > >> * //WEB-INF/lib/*.jar/ of your web application later > >> > >> so, if someone needs to modify a localized version for any reason, > >> he/she can simply extract the relevant file from the bundle and > >> leave it > >> directly into classes. > >> If a new version come, it has simply to be checked variations against > >> modified version; or drop it to see 'default' behaviour. And the > >> 'normal' user would had to > >> do nothing. > >> > >> Luca > >> > >> > >> Janne Jalkanen ha scritto: > >>>> > >>>> I agree with Harry. My only difficulty was finding out what was > >>>> needed. Why not have the templates directory in /WEB-INF/classes by > >>>> default on install but have all the values commented out. Then, > >>>> should anyone want to make changes, they simply have to find the > >>>> right one, uncomment the line, edit it and they are away! Leave the > >>>> default values in JSPWiki.jar. > >>> > >>> A good reason to keep them out of /classes/ is the difficulty of > >>> upgrading. For example, we might reshuffle keys from one property > >>> file > >>> to another (we've done this) or introduce new property files. This > >>> would make upgrades yet a bit more difficult, since these would > >>> become > >>> yet another configuration file to be merged. In addition, they > >>> would > >>> be the burden of *everyone*, even those who do not wish to change > >>> any > >>> localization. > >>> > >>> It's better to have few bigger files than a lot of small files when > >>> upgrading... > >>> > >>> So in short, I'm worried about the overall maintenance overhead this > >>> would cause people, which might not be worth the while considering > >>> how > >>> rarely people need to change them. > >>> > >>> /Janne > >> > >> >
