Mailing-List: contact jspwiki-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of andrew.r.jaquith@gmail.com
 designates 74.125.46.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:x-mailer:mime-version:subject:date
         :references;
        b=VnB9q/By0uL6hzIwJITYz9LjMBtUuGuwU4UttcgWdTLCL1uShiqYr36gWtf7s5CP2W
         LcmE3ExEPb4AZjH+oC14XSEF8pMFsetxslupOgMW7TghOB0S+xmUi8oGzBa/6E2CIfmM
         BK987/0hEvcx8QIt65tAA00m/Xni9NqQueTts=
Message-Id: <02C44C95-C54D-4F91-87CD-A15095C4C8AF@gmail.com>
From: Andrew Jaquith <andrew.r.jaquith@gmail.com>
To: jspwiki-user@incubator.apache.org
In-Reply-To: <20090418092749.ad5429b6@mail.poisoncentre.be>
Content-Type: text/plain;
	charset=utf-8;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (iPhone Mail 5H11)
Subject: Re: Where are messages stored?
Date: Sat, 18 Apr 2009 09:30:23 -0400
References: <20090418092749.ad5429b6@mail.poisoncentre.be>

Suggestion (2) isn't practical. The JSTL fmt: tags are defined to look =20=

things up in particular classpath locations; ditto with the Stripes =20
tags.

Andrew

On Apr 18, 2009, at 3:27, "Christophe Dupriez" =
<christophe.dupriez@poisoncentre.be=20
 > wrote:

> Hi!
>
> I would have a suggestion:
> 1) every message in every supported language would have a default =20
> version distributed with JSPWiki.
>   If a language is not supported, the installation could define a =20
> default language.
>   This would ensure that a message is always available even if =20
> JSPWiki is upgraded.
> 2) local version of **some** messages in a given language could be =20
> defined in a local configuration directory (never erased by a WAR =20
> deployment). If there is no local version of a message, the one =20
> bundled with JSPWiki is used.
> 3) If, for a given message, the number of parameters {0} changes, =20
> the message key would always be changed (this to ensure that if new =20=

> parameters are added, an innapropriate message is not used)
> 4) The message files should remain editable with a tool like Eclipse =20=

> property editor.
>
> Have a nice weekend!
>
> Christophe Dupriez
> Centre Antipoisons-Antigifcentrum
> C/o H=C3=B4pital 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: lgilardoni61@gmail.com [mailto:lgilardoni61@gmail.com]
> To: jspwiki-user@incubator.apache.org
> 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 =20
>> 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 =20=

>>> file
>>> to another (we've done this) or introduce new property files. This
>>> would make upgrades yet a bit more difficult, since these would =20
>>> become
>>> yet another configuration file to be merged.  In addition, they =20
>>> would
>>> be the burden of *everyone*, even those who do not wish to change =20=

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

>>> how
>>> rarely people need to change them.
>>>
>>> /Janne
>>
>>