split from bug 8152
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.
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; 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.
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.
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: 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.
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 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.
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
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.