8188 - Locale fallback for string bundle

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect, P3)

Description

[Frank Tang]

split from bug 8152

Comment 1

[Frank Tang]

Enhancement
I also added code that looked for the URL without locale, if the URL+locale
could not be found. I'm not sure if this is wanted or not, but otherwise the
StringBundleTest doesn't do anything, as it can't find the properties file.

I guess another step would be to look for the three files..

eg.

file_en_AU.properties
file_en.properties
file.properties

-dave

see the attachement in 8152

I am not sure that we should take the locale fallback part since it is one of
the major performance problem in JDK. Erik, plesae make decision since you know
better about this.

The problem JDK have is it have 6 level fallback (instead of 3) and it need to
search through (open and decompressed) all the .JAR and . ZIP file for those
property file for every access of property file. And since most of the
application do not ship with the locale one, it always fallback 5 times in non
English locale which suck the performance a lot. However, we are not package
property file into zip or jar file (YET). So, we may have different story here.

Erik , I assume you already hand the string bundle stuff to tao.
Tao, please talk to erik first. Thanks.

Comment 2

[Frank Tang]

Mark this M8. We should make decision before M8. Take the changes or not ?

Comment 3

[Erik van der Poel]

Bob and I tentatively set the milestone for this fallback feature to M8. I'm
working on M7 now, so let's discuss this later.

Comment 4

[tao]

Eventually, we gonna support a mirror JS object of this. The property file
might be local anymore. We shall get net developers and web pages developers
involved. In other words, we need to discuss this in the newsgroup.

Comment 5

[tao]

I had checked in a patch to fallback to less specific locale name from more
specific one. For example, a user locale such as en-US would make strres look
for a file named "xxx_en_US.properties", and fallback to xxx_en.properties and
even xx.properties when files in the fallback sequence not found.

In the current Seamonkey, the default property file without locale decoration
will be the last resort when the intended target can not be found.

Comment 6

[tao]

Steps of testing the fix with StringBundleTest(.exe)

1. StirngBundleTest can be found in x86rel/StringBundleTest.exe in WIN32 build;
   or package/StringBundleTest.
2. On WIN32,

   2.1. open a command prompt window.
   2.2. "cd" to where StringBundleTest resides and run it.
   2.3  The default locale for an English NT system shall be en-US. By default,
        the program will look for strres_en_US.properties under x86rel/res/
        directory. Since there is not such file in that directory, it shall try
        to open strres_en.properties. Again, this file is not there either,
        it shall try to open strres.properties. This time, it shall succeed.

        When the file is found and opened, the program will perform some
        query by id or name and dump the result to the console.

    2.4 Rename strres.properties to strres_en.properties and run
        StringBundleTest again. You shall see the program succeed on the second
        attempt.
    2.5 Rename strres_en.properties to strres_en_US.properties and run
        StringBundleTest again. You shall see the program succeed on the first
        attempt.

  3. You may want to edit strres[_en_US].properties and change some of the text
     entries so you know which file is opened.

  4. Retest the program on Ja system to see how it turns out.

Feel free to let know if you run into any problem.

Comment 7

[Katsuhiko Momoi]

As I'm writing M8 Intl release notes, I would like to note
the follwing:

The name of the StringBundleTest is "Stringbu.exe" due to
DOS file name truncation and this file can be found in the
same directory where the apprunner is located.
Please also note that this test is probably not available unless
you get the "extratest.exe" file and run it -- in addition to the
basic.zip file.

It would also be a good idea to have several "distinct" stress_LOC.properties
files at the same time to see if a correct one is selected
when there are several stress_LOC.properties files are availble.

Comment 8

[Katsuhiko Momoi]

Additional informaiton on: "Stringbu.exe"

1. The Netsacpe-internal base.zip file does not contain this item, but
   you can find it in "xtratest.exe".
2. The Mozilla (external) nightly build contains "Stringbu.exe" and
   external people should be able to check this out. The assumption
   is that this test will be included in the upcoming M8 release.

Comment 9

[Teruko Kobayashi]

I verified this in 8-06-09 Win32 build.

Comment 10

[tao]

Per the discussion and conclusion I posted here:

     news://news.mozilla.org/37AA344F.CBBC9D57%40netscape.com

I am reopening the bug and will embed the locale name in the URL
path instead of filename.

Comment 11

[tao]

Clearr the resolution

Comment 12

[tao]

*** Bug 8525 has been marked as a duplicate of this bug. ***

Comment 13

[tao]

Not show stopper; push to M11.

Comment 14

[tao]

Not a show blocker. Push to M12.

Comment 15

[tao]

Non-stopper->M12.

Comment 16

[tao]

Non blockers; push off to M14.

Comment 17

[Phil Peterson]

PDT- until we see some connection to the beta spec

Comment 18

[tao]

There are some performance drag of the current fallback implementation. It 
always look for .../foo_en-US.properties and .../foo_en.properties first, before
../foo.properties which does exist in our build.

I can take out the fallback and look for the ../foo.properties first to improve
the performance a bit. This might take care 
http://bugzilla.mozilla.org/show_bug.cgi?id=25283 and 
http://bugzilla.mozilla.org/show_bug.cgi?id=26291.

I had submitted the patch in bug 26291.

Comment 19

[tao]

I had checked in the patch to take out the attempts of opening non-existing
files.

I have no plan to address the fallback mechanism now. Push to M18

Comment 20

[tao]

This is not an urgent issue in the near future. Mark it remind!

Comment 21

[tao]

.

Comment 22

[Christopher Hoess (gone)]

REMIND is deprecated per bug 35839.

Comment 23

[tao]

Hi, Bob: please reassign these i18n/l10n/l12y bugs accordingly. thx!

Comment 24

[Vedran Miletic]

retargeting

Comment 25

[Simon Montagu :smontagu]

I don't think we want to do this.