> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> list-help: <mailto:[EMAIL PROTECTED]>
> list-unsubscribe: <mailto:[EMAIL PROTECTED]>
> list-post: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> From: "Takashi Okamoto" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Subject: Re: Proposal for implementation of lookup of localized
web-resources
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
>
> Hi!!
>
> From: "Arieh Markel" <[EMAIL PROTECTED]>
> > Assume locale in request is: fr_CA
> > Assume locale of where tomcat is set: en_US
> >
> >
> > requested path
> >
> > <docbase>/dir/.../index.html
> >
> > file-based: (path/<filebasename>[locale].filetype)
> >
> > 1. <docbase>/dir/.../index_fr_CA.html
> > 2. <docbase>/dir/.../index_fr.html
> > 3. <docbase>/dir/.../index_en_US.html
> > 4. <docbase>/dir/.../index_en.html
> > 5. <docbase>/dir/.../index.html
> >
> >
> > docbase-based: ([locale]/path/filename)
> >
> > 1. <docbase>/fr_CA/dir/.../index.html
> > 2. <docbase>/fr/.../index.html
> > 3. <docbase>/en_US/.../index.html
> > 4. <docbase>/en/.../index.html
> > 5. <docbase>/dir/.../index.html
>
> Did you read following apache URL?
> http://httpd.apache.org/docs-2.0/content-negotiation.html
>
> I think your proopsal is good. But unfortunately, your proposal will lose
> compatibility with Apache.
I am not aware that we have compatibility with Apache now.
>From my own perspective implementing exclusively apache localization
compatibility is actually 'bad'. Our deliverables are usually not apache
dependent/nor based. Out localization experts seek compatibility
with Java localization.
> Please rewrite your proposal.
No, I am not going to rewrite my proposal. I explain below how developers
interested on the apache scheme can implement it.
I 'scratched my own itch' with the proposal that I brought up. My own
itch does not include compatibility with Apache, it includes
compatibility with localization schemes in the Java world (the ones
I looked up are ResourceBundle and JavaHelp).
Given that the alternative is to choose from the below:
. use the current proposal as the basis, and extend to support
all kinds of localization
. not have localization at all until someone implements exclusive
apache localization
tell me which one you prefer.
---
As an aside, here is how apache compatibility can be achieved (I will
leave the implementation of apache-compatible localization as an exercise
to those who have that itch to scratch).
. the StaticInterceptor has the 'localization' attribute available.
currently, 'file', 'docbase' are the options.
Add a 'apache' option to the permissible values.
On FileUtil, implement a:
getApacheLocalizedResource ()
method
On Context, add to the logic of 'getRealFile()' to handle 'apache'
type localization, invoking the method in FileUtil.
Such a scheme will allow to add more different localization mechanisms
in the future.
---
So, what I proposed is the mechanism for introduction for various
localization lookup schemes, and to start from the set that I proposed.
Thanks for your comments.
Arieh
--
Arieh Markel Sun Microsystems Inc.
Network Storage 500 Eldorado Blvd. MS UBRM11-194
e-mail: [EMAIL PROTECTED] Broomfield, CO 80021
Pray for snow !!!! Phone: (303) 272-8547 x78547
(e-mail me with subject SEND PUBLIC KEY to get public key)
