split from bug 8152
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..
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.
Mark this M8. We should make decision before M8. Take the changes or not ?
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.
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.
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.
Steps of testing the fix with StringBundleTest(.exe)
1. StirngBundleTest can be found in x86rel/StringBundleTest.exe in WIN32 build;
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
2.5 Rename strres_en.properties to strres_en_US.properties and run
StringBundleTest again. You shall see the program succeed on the first
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.
As I'm writing M8 Intl release notes, I would like to note
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
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.
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.
I verified this in 8-06-09 Win32 build.
Per the discussion and conclusion I posted here:
I am reopening the bug and will embed the locale name in the URL
path instead of filename.
Clearr the resolution
*** Bug 8525 has been marked as a duplicate of this bug. ***
Not show stopper; push to M11.
Not a show blocker. Push to M12.
Non blockers; push off to M14.
PDT- until we see some connection to the beta spec
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
I had submitted the patch in bug 26291.
I had checked in the patch to take out the attempts of opening non-existing
I have no plan to address the fallback mechanism now. Push to M18
This is not an urgent issue in the near future. Mark it remind!
REMIND is deprecated per bug 35839.
Hi, Bob: please reassign these i18n/l10n/l12y bugs accordingly. thx!
I don't think we want to do this.