> 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: Mike Braden <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: RE: Proposal for implementation of lookup of localized web-resour ces > X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > It seems like this would be much more logical to manage > multi-lingual sites, since each lang would be in it's > own dir structure. > > Of course, it also means that you would have to duplicate > anything that is not lang dependent, such as images. > (I assume that the doc-based locale would re-direct all > requests???) There is no need to duplicate things that do not to be language dependent, since the lookup falls back to the non-locale-relevant name. For example, request to get: /foo/foobar.gif requestLocale: fr_FR fallbackLocale: en_US lookup sequence: using docbase scheme: 1. /fr_FR/foo/foobar.gif 2. /fr/foo/foobar.gif 3. /en_US/foo/foobar.gif 4. /en/foo/foobar.gif 5. /foo/foobar.gif using filebase scheme: 1. /foo/foobar_fr_FR.gif 2. /foo/foobar_fr.gif 3. /foo/foobar_en_US.gif 4. /foo/foobar_en.gif 5. /foo/foobar.gif There is also no need to change the contents of the links inside of the documents. The localized resource lookup method is also exposed to developers so that they can invoke obtaining the resource from within a servlet as well. Arieh > > Mike. > -- > Mike Braden > [EMAIL PROTECTED] > > > -----Original Message----- > From: Arieh Markel [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 14, 2001 10:19 AM > To: [EMAIL PROTECTED] > Subject: Proposal for implementation of lookup of localized > web-resources > > > We are about to release a product on which we include Tomcat 3.2. > > Our testing and localization people have been banging at our product > and come up with several remarks about how lookup for a localized > resource (file: html, gif, javascript, etc) are being done. > > I have in the past contributed localization code to the 3.2 code base. > > I have received a couple of remarks from the localization people. > > The current way that localization is done on the code I contributed > to 3.2 was what I called 'file-based' lookup. > > An alternative method that I implemented in our application (but have > not contributed to Jakarta yet) is 'docbase-based' lookup. > > Here is a brief overview of both mechanisms: > > 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 > > > File-based lookup works in a manner similar to how ResourceBundle does. > > Docbase-based lookup is similar to how JavaHelp organizes the files. > > ---- > > Implementation proposal: > > a. create a class 'org.apache.tomcat.util.Localization' (for 3.x). > 'org.apache.catalina.util.Localization' (for 4.x). > > b. implement two static methods: > > public static String getLocalizedPathFileBased ( > String dir, String path, Locale loc, Locale fbLoc) > > public static String getLocalizedPathDocBaseBased ( > String dir, String path, Locale loc, Locale fbLoc) > > > c. For 3.x: in StaticInterceptor, add "localization" as a property > with valid values of: > "file" "docbase" > > d. For 4.x: (I have just begun looking at the code yesterday - would > appreciate some pointers from the 4.x experts of where the > serving of resource is done) > > ---- > > Any opinions ? > > Much of the code has already been written and has been tested. > > > 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) -- 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)
