602800 - Locale not shown in about:support or about box (or anywhere else)

Status: RESOLVED DUPLICATE of bug 1414975

(Toolkit :: General, defect)

Description

[Alan Thomas]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b6) Gecko/20100101 Firefox/4.0b6
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101007 Firefox/4.0b8pre

The user's build locale used to be shown in the about box, as part in the user agent string (now shown in about:support. But the locale has been removed from the UA string, and so now there is no simple way to view the locale of a particular installation of Firefox.

Reproducible: Always

Comment 1

[Dave Garrett]

Yes, this looks like a problem. Confirming and adding to meta bug.

I'd like to see a line added to about:support with both the UI locale and the content locales (HTTP accept languages). This information needs to be obtainable somewhere for support.

Comment 2

[Dave Garrett]

Implementation-wise, I see two ways to do this:
1) Full route: Add a "Language" line to the "Application Basics" heading with this information in full.
2) Lazy stringless route: Add a parenthetical with the UI locale after the version number on the existing "Version" line. (for all locales, including en-US)

As we're past string freeze (theoretically) I'll take the later if the former is not wanted at this time. Just need something in somewhere as the information was removed via bug 572656.

Comment 3

[Alan Thomas]

Attachment: Suggested lazy stringless patch

Here is a basic sample patch for the "lazy stringless route" dgarrett suggested.

Comment 4

[Alan Thomas]

Um, that patch refers to toolkit/content/aboutSupport.js, not "C:\\Documents". Something bad went wrong with git diff.

Comment 5

[Alan Thomas]

Attachment: patch, v. 2

This patch fixes the diff formatting issues with the earlier patch. The actual code contents are unchanged.

Comment 6

[Dave Garrett]

Comment on attachment 486569 [details] [diff] [review]
patch, v. 2

I can give you my feedback+ with two caveats:
1) You'll need a review from someone in charge of reviewing patches to get it landed.
2) navigator.language has the current desired effect of giving the application UI locale, however, once bug 580032 / bug 55366 lands it will expose the top accept-language and not the application locale itself.

nsILocaleService ~looks~ like what you'd want to get the actual UI locale, but it isn't if you read the fine print as it gets OS locale info, not application, even if the method names imply so.

The actual source to get the real UI locale reliably seems to be nsIHttpProtocolHandler of all places, as that's where navigator.language is getting things right now until it's changed. In JS to fetch the UI locale:
Components.classes["@mozilla.org/network/protocol;1?name=http"]
          .getService(Components.interfaces.nsIHttpProtocolHandler)
          .language;

I think if we're showing the locale in a parenthetical it should be reliably for the application UI locale, so under the assumption that navigator.language is going to change to not do this then I think getting it explicitly may be warranted. That being said, there's talk in bug 55366 that the nsIHttpProtocolHandler property shouldn't be there anymore either, so maybe getting the "general.useragent.locale" pref (regardless of its legacy naming) is what's wanted. Doing that reliably in JS is:
try { return Services.prefs.getComplexValue("general.useragent.locale",
             Components.interfaces.nsIPrefLocalizedString).data; }
catch (e) { return Services.prefs.getCharPref("general.useragent.locale"); }

As the API to get this info is in a bit of flux right now, I'm going to CC some people to ask which is the best intended method to get the application's UI locale.

Comment 7

[Dave Garrett]

Alex & Dan: per bug 55366 comment 130 - 137, what should be the best route to getting the application UI locale here? See comment 6 above for the 3 options.

Comment 8

[Dave Garrett]

(the pref route in comment 6 is basically just what I do in Flagfox right now, and it's what Quick Locale Switcher uses too, I think)

Comment 9

[Axel Hecht [:Pike]]

Hah, I'd have a third.

Chrome registry and selected locale for 'global'. I think that's best going forward.

Regarding accept-languages, I'm tempted to make that a site-specific pref at some point, or even something more involved working on url patterns. Not sure if that has an impact here yet.

Comment 10

[Dave Garrett]

(In reply to comment #9)
> Hah, I'd have a third.

Fourth, if you count the first to be navigator.language. ;)

> Chrome registry and selected locale for 'global'. I think that's best going
> forward.

Ah, I didn't know you could do that. Yes I agree, after a quick test that looks like the best route to reliably get the application's UI locale. Thanks!

Components.classes["@mozilla.org/chrome/chrome-registry;1"]
          .getService(Components.interfaces.nsIXULChromeRegistry)
          .getSelectedLocale("global")

Comment 11

[Dave Garrett]

I did another quick test and the "global" chrome package locale route will even correctly give the locale for a language pack running on an otherwise en-US application, which I think is a good thing here. We want the current in-use UI locale, be it as a native install or a language pack on top. (and I think some Linux distros may blur the line between the two, if I remember correctly)

The code in comment 10 seems to be the best route to fetch the locale we want.

Comment 12

[Alan Thomas]

Attachment: patch, v. 3

This patch uses nsIXULChromeRegistry to retrieve the user's current locale. I can't find a language pack that works properly with Firefox 4, so I couldn't test that.

Comment 13

[Dave Garrett]

I just tested the following using current Minefield builds on Linux:
native en-US build
native ja build
native he build (RTL)
en-US build with pt-BR pack

Alerting the comment 10 code from the Error Console code gives the current UI locale that's in-use as expected. Should all work fine.

Up-to-date builds and language packs are here, BTW:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/

Comment 14

[Alan Thomas]

Comment on attachment 486804 [details] [diff] [review]
patch, v. 3

On the Hebrew language pack (rtl), this causes the Version line to display "(4.0b8pre (he", with a leading (actually trailing) opening parenthesis. Is this what RTL users would expect to see, or does it need to be changed?

Comment 15

[Dave Garrett]

(In reply to comment #14)
> On the Hebrew language pack (rtl), this causes the Version line to display
> "(4.0b8pre (he", with a leading (actually trailing) opening parenthesis. Is
> this what RTL users would expect to see, or does it need to be changed?

Oh joy, I forgot about RTL junk with numbers. Yeah, it does that... a lot.

I suggest adding to aboutSupport.css something to the effect of:

td#application-box, td#version-box, td#useragent-box {
  direction: ltr;
}

This is LTR information so we should be able to force the RTL flipping off here. (though I haven't tested this instance)

Comment 16

[Alan Thomas]

(In reply to comment #15)
> (In reply to comment #14)
> I suggest adding to aboutSupport.css something to the effect of:
> 
> td#application-box, td#version-box, td#useragent-box {
>   direction: ltr;
> }

This causes the LTR text in the cells to be aligned left, and it looks a bit silly, particularly in a wide viewport. It might look better if the LTR text was aligned right (text-align: right) for RTL systems.

Comment 17

[Dave Garrett]

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > I suggest adding to aboutSupport.css something to the effect of:
> > 
> > td#application-box, td#version-box, td#useragent-box {
> >   direction: ltr;
> > }
> 
> This causes the LTR text in the cells to be aligned left, and it looks a bit
> silly, particularly in a wide viewport. It might look better if the LTR text
> was aligned right (text-align: right) for RTL systems.

Hmm, then give the table in question an id and make it:

#basics-table td:-moz-locale-dir(rtl) {
  direction: ltr;
  text-align: right;
}

This would have the effect of text-align:right for RTL and normal text-align:left for LTR.

Comment 18

[Alan Thomas]

Attachment: patch, v. 4

-moz-locale-dir doesn't work from HTML (bug 588996). So I used a bit of a kludge involving the locale.dir entity. 

Tested under en-US, en-US with fr and he langpacks, and a native he build.

Comment 19

[Dave Garrett]

(In reply to comment #18)
> kludge involving the locale.dir entity. 

The standardized-ish kludgey version of that should be to set an attribute chromedir="&locale.dir;" and then apply using an id and attribute selector.

Comment 20

[Alan Thomas]

Attachment: patch, v. 5

Comment 21

[Dave Garrett]

Comment on attachment 487222 [details] [diff] [review]
patch, v. 5

Assuming nsIXULChromeRegistry.getSelectedLocale("global") always works and is always available for all Toolkit apps which use about:support, then this looks good to me. Once bug 588996 is fixed someone will come around and update this to use -moz-locale-dir instead of chromedir="&locale.dir;".

Requesting review. Benjamin, you look like a good reviewer for this short patch.

about:support probably needs its own component under Toolkit at this point to make things more clear as to who should be reviewing. Think I should file a request to add it?

Comment 22

[Benjamin Smedberg]

Comment on attachment 487222 [details] [diff] [review]
patch, v. 5

.getSelectedLocale will give you the *current* locale of the user, but that will not match the installed locale if the user has a langpack installed. That's valuable information, but shouldn't be lumped with the version field.

Comment 23

[Alan Thomas]

(In reply to comment #22)
> .getSelectedLocale will give you the *current* locale of the user, but that
> will not match the installed locale if the user has a langpack installed.
> That's valuable information, but shouldn't be lumped with the version field.

So would a separate "Language" or "Locale" line, which contains both the app build locale and the current UI (langpack) locale, be better? This would require new strings.

Comment 24

[Alan Thomas]

Is it too late to do this? Because I'll do a patch now if it can still land in time for Firefox 4, with the strings which it will most likely need.

If it is too late for Fx4, I'll leave this bug for later.

Also, I don't seem to be able to change the assignee of this bug. What's up with that?

Comment 25

[Axel Hecht [:Pike]]

I don't think we have the installed locale really anywhere but in the update.locale field, which we only have for builds that actually have MOZ_UPDATER. I'd just postpone that to a follow up bug.

I'm not sure we need a separate line for the locale code, but if so, we should call it "Language" and not locale.

Comment 26

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: patch adding the UI Localization to about:support, version 1

This patch reads 'general.useragent.locale' from chrome://global/locale/intl.properties and displays it in about:support.

Comment 27

[Axel Hecht [:Pike]]

Comment on attachment 594496 [details] [diff] [review]
patch adding the UI Localization to about:support, version 1

It's not really the right value.

I think you're misreading bsmedberg's comment 22. That seems to be about lumping version and locale, not about the displayed value.

In particular for support, knowing which language was installed is likely less important than knowing which language the user is actually using.

Comment 28

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Comment 22 says that
a) version and locale shouldn't be in the same box
b) used locale and locale installed on application level can be different

My patch doesn't mix version and locale, which locales would you like to have shown?
Suggestion:
User Interface Localization: de (Firefox install: en-US)

Or in line with comment 27, only show the current locale?

So, it's only moving the locale from the version to a separate row?

Comment 29

[Axel Hecht [:Pike]]

One thing is that the string for general.useragent.locale can't be really assumed to be the language code, in particular on language packs. da still has da-DK, and in particular upcoming locale packs would probably have unreviewed stuff in there, if not just en-US. One thing I notice when I review new locales we take rather often.

What we should actually show, installed, used, available, that's really up for the support guys to spec out. Personally, I would think that "using right now" is the best bet, and doesn't leak all kinds of data. (All available might be just verbose not-really helpful in linux distro builds.)

Comment 30

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

So is this bug fixable if the language pack providers don't provide the necessary information? Can we trust the language pack name?

Comment 31

[Mark Banner (:standard8)]

Bug 1414975 added support for this.