This bug is filed after received message from edmundo@netscape.com (Edmundo Gonzalez) at 6/26: * Approx. 4,000 404 errors are being seen daily for users attempting to access International all-panels.rdf files. * These errors (which are coming from English version of N6.x browsers) are for URL's which have incorrect "LOCALE" codes in them. * Potential cause of problem could be due to migration of localized 4.x users to English version of N6.x browser.

In the sidebar we are creating a url based on the localized string coming from GetLocaleComponentForUserAgent. http://lxr.mozilla.org/seamonkey/source/intl/locale/src/nsLocaleService.cpp#514 From the code I see that this string is taken from the system's locale.

Here is my finding: The following is technical discussion, ignore if you don't care: in Mozilla code, I only see the following place include all-panels.rdf: /modules/libpref/src/init/all.js, line 482 -- pref("sidebar.customize.all_panels.url", "http://sidebar-rdf.netscape.com/%LOCALE%/sidebar-rdf/%SIDEBAR_VERSION%/all-pane ls.rdf"); We don't localized that setting, but the %LOCALE% and %SIDEBAR_VERSION% will be repalced by some other string and that might be localized. It seem %SIDEBAR_VERSION% will currently always replaced with "0.1" (see http://lxr.mozilla.org/seamonkey/source/xpfe/components/sidebar/resources/sideba rOverlay.js#64 ) and %LOCALE% will be replace with 1) preference "intl.content.langcode" with lower case. The problem is I don't think this preference exist. If it failed, it will fallback to 2), 2) user agent locale in lower case (nsLocaleService::GetLocaleComponentForUserAgent and lower case). It seems this value is not depend on localization, but depend on what system the user is currently using. For example, if an user running a English build on a Polish system, you may got a 'pl' there. Currently, I cannot find any other place in the code use this api. In /ns tree, we also add the "intl.content.langcode" pref in the activation code ( see http://lxr.mcom.com/commercial/source/profile/src/nsActivation.cpp#533 ) So... what happen is the following: 1. in /ns en-US build, if user go through activation, it probably will add a right "intl.content.langcode" into the pref, and therefore, we probably will produce a right URL for sidebar 2. in /ns en-US build, if user didn't go through activation correctly, then we will not have the right "intl.content.langcode", and it will generate an URL depend on system locale. And therefore, we may got 'pl' as locale if the user is running on a polish system, even the build is a english build. 3. in /ns non en-US build, since we don't have activation in place, we will have the same behavior as '2' 4. In mozilla build, since we do not have activation, we will have the same behavior as '3'. So... the incorrect URL hit are likely coming from 1. /ns en-US build which user skip the activation process and running on non English, Japanese, German, or French system 2. /ns non en-US build, which running on non English, Japanese, German, or French system 3. /mozilla build which running on non English, Japanese, German, or French system Suggest action, 1. add "intl.content.langcode" as "en-us" to all.js, in this way, the sidebar will always set to english one unless activation is in place. The problem of this strategy is then the Japanese build will also point to English sidebar unless we have Japanese activation. We probably should also change to put that setting into content pack or language pack.

> matt@netscape.com 2001-06-26 13:49 - >In the sidebar we are creating a url based on the localized string coming from >GetLocaleComponentForUserAgent. >http://lxr.mozilla.org/seamonkey/source/intl/locale/src/nsLocaleService.cpp#514 >From the code I see that this string is taken from the system's locale. The problem of system locale is it represent what the OS is, not what the application is. For example, if you run a French n6 or a German window, GetLocaleComponentForUserAgent will tell you German instead of French. That is not too bad. But think about if people running English version on Polish, Russian OS, it will report 'ru' and 'pl' and NetCenter simply are not ready for those locale yet. We should change to application locale instead. Nhotta- do you know how to do that?

Adding jbetak to cc, I remember you were trying to add a pref to remember the current content. I checked all.js but could not find it.

nsILocaleService has GetApplicationLocale(), implementation is platform dependent. I see Macintosh sets system locale for application locale, so we cannot use that service. We may use user agent. So what string do we need, language or country or both?

Currently, nsLocaleService::GetLocaleComponentForUserAgent is returning system locale which is wrong. It can return a pref valude of "general.useragent.locale". Since only the sidebar code uses GetLocaleComponentForUserAgent, changing it will not affect other feature.

nhotta: the language UI is currently using general.useragent.locale, since Ben has not modified my patch for UI locale and content pack swithing. Would it be preferrable to have a dedicated pref for the language UI?

We need to talk to tao is UI language switch supposed to change the user agent string. For this bug, "general.useragent.locale" change would not cause a problem. Because the sidebars are provided by language packs, the sidebar would always be found for the locale of the language pack.

r=ftang do more testing.

>do more testing. run a english build on Japanese window. If we do right, we should see English sidebar

Additional info from netcenter: Date: Tue, 26 Jun 2001 15:58:00 -0700 From: jmanjaly@netscape.com (Joy Manjaly) Here is the list from today's access log. I see around 40 of them. /ar-sa/sidebar-rdf/0.1/all-panels.rdf /bg-bg/sidebar-rdf/0.1/all-panels.rdf /ca/sidebar-rdf/0.1/all-panels.rdf /cs-cz/sidebar-rdf/0.1/all-panels.rdf /da-dk/sidebar-rdf/0.0/all-panels.rdf /de-at/sidebar-rdf/0.1/all-panels.rdf /de-ch/sidebar-rdf/0.1/all-panels.rdf /de_at%40euro/sidebar-rdf/0.1/all-panels.rdf /el-gr/sidebar-rdf/0.1/all-panels.rdf /en-au/sidebar-rdf/0.1/all-panels.rdf /en-ca/sidebar-rdf/0.1/all-panels.rdf /en-gb/sidebar-rdf/0.1/all-panels.rdf /en-nz/sidebar-rdf/0.1/all-panels.rdf /es-ar/sidebar-rdf/0.1/all-panels.rdf /es-co/sidebar-rdf/0.1/all-panels.rdf /es-mx/sidebar-rdf/0.1/all-panels.rdf /es/sidebar-rdf/0.0/all-panels.rdf /es/sidebar-rdf/0.1/all-panels.rdf /fi-fi/sidebar-rdf/0.0/all-panels.rdf /fi-fi/sidebar-rdf/0.1/all-panels.rdf /fr-ca/sidebar-rdf/0.1/all-panels.rdf /fr/sidebar-rdf/0.1/all-panels.rdf /he-il/sidebar-rdf/0.1/all-panels.rdf /hu-hu/sidebar-rdf/0.0/all-panels.rdf /ja-jp.eucjp/sidebar-rdf/0.1/all-panels.rdf /ko-ko/sidebar-rdf/0.1/all-panels.rdf /nl-nl/sidebar-rdf/0.1/all-panels.rdf /no-no/sidebar-rdf/0.1/all-panels.rdf /no/sidebar-rdf/0.1/all-panels.rdf /pl-pl/sidebar-rdf/0.1/all-panels.rdf /pt-br/sidebar-rdf/0.1/all-panels.rdf /pt-pt/sidebar-rdf/0.1/all-panels.rdf /ru-ru/sidebar-rdf/0.1/all-panels.rdf /sl-si/sidebar-rdf/0.1/all-panels.rdf /th-th/sidebar-rdf/0.1/all-panels.rdf /zh-cn/sidebar-rdf/0.1/all-panels.rdf /zh-tw/sidebar-rdf/0.1/all-panels.rdf

in sidebar we are calling this from js. Should just change the js not to call GetLocaleComponentForUserAgent and instead call general.useragent.locale ? Then we can keep the API in case someone in the future needs to call the system locale.

nsILocaleService::GetSystemLocale should be used in order to get a system locale.

>Should just change the js not to call GetLocaleComponentForUserAgent >and instead call general.useragent.locale ? >Then we can keep the API in case someone in the future needs >to call the system locale. I think that is better. Less c++ change mean less chance for crashing. Can you put a new patch which replace the call to GetLocaleComponentForUserAgent with access to general.useragent.locale pref?

I don't think that is better. GetLocaleComponentForUserAgent returns system locale is wrong.

Switching QA contact to jonrubin.

r=ftang matt, can you also review this one?

r=matt

sr=alecf

land to trunk first and keep this bug open for moz0.9.2 landing.

checked in to the trunk

PDT+ per pdt meeting. check it into both branch and trunk

land into moz0.9.2 branch. close this bug. cc gbush@netscape.com per lchiang

Not sure how to verify the fix for this. Is it necessary to first migrate a profile from localized 4.x version to US 6.x? Could someone please provide a testcase? Thanks.

per ftang's comments: >run a english build on Japanese window. If we do right, we should see English >sidebar The patch nhotta checked in derives the sidebar locale from the language UI settings, not the OS (system) locale.

So does this mean that if I install the US build on Japanese Windows, then install ja language pack and switch to ja UI, the sidebar panels should change to Japanese? And, if I then switch the UI language back to English, should the Sidebar panels revert back to English as well?

Jon, I believe you're correct. Tao is not objecting and I think I've observed said behavior in recent builds...

If that is the case, then this may still not be fixed. In the 07-06-06-trunk build, I have noticed the following behavior (on WinMe-Ja): If I create a new profile set to en-US, the Sidebar will be set to English. If I download ja lang pack and apply, the sidebar becomes Japanese. However, if I now create an entirely new profile set to en-US, Sidebar and Bookmarks are still set to Japanese. Does this look like a separate bug, or related to this one?

how to verify the fix. 1. find a machine which netcenter do not support the locale, say polish version of window. 2. install english version of n6. 3. launch n6. 4. check sidebar, if the bug is not fix, we should direct the sidebar to a non existing location. if the bug is fixed, then we should direct the sidebar to the english version. Edmundo: to reply your remail, yes I believe this is fixed. We need QA to verify it. Is that possible your team can download our latest build and help us to verify it ?It is easier since your team can access the server log.

Verified on branch using 07-13-06-branch build on Czech WinNT4.0. Verified using Frank's test case; sidebar did redirect correctly to English version. Also, Tabs>Customize Sidebar shows tabs in English. Changing qa --> edmundo for checking server logs as requested by Frank.