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
>
>
