918465 - Record locale in FHR environment

Status: RESOLVED DUPLICATE of bug 922694

(Firefox Health Report Graveyard :: Client: Android, defect)

Description

[brendan c]

I have a sample of 1300 v3 payloads, none of which have the strings "locale" or "en-US".

Comment 1

[Richard Newman [:rnewman]]

Presumably you want this in the environment? What do you mean by "locale" -- Gecko pref, OS setting, both?

http://developer.android.com/reference/java/util/Locale.html
http://mxr.mozilla.org/mozilla-central/source/services/healthreport/providers.jsm#343

Comment 2

[brendan c]

(In reply to Richard Newman [:rnewman] from comment #1)
> Presumably you want this in the environment? What do you mean by "locale" --
> Gecko pref, OS setting, both?

Good question. Both I think.

Comment 3

[Richard Newman [:rnewman]]

Brendan: there are four potential locales in the system. Right now some of them are clamped together, but Fennec plans to allow for more choice in this regard fairly soon.

They are:

1. The OS locale.
2. The Android app locale (typically the same, but can be different).
3. The Gecko locale, which we *probably* will keep the same as 2, but maybe not!
4. The requested content locale.

For example: you could be in India using a v2.2 Android device set to en_GB, with Firefox running in en_IN (only supported in Android since 2.3), Gecko using en_IN, and requesting pages in Kannada (kn-IN).

How much do we care about these distinctions?

Karen, Axel: could you weigh in?

Comment 4

[Richard Newman [:rnewman]]

Due to implementation constraints, this really needs to land alongside Bug 922694, which is tracking-fennec 26+. As such, setting tracking?, and needinfo folks: please reply as soon as you get a chance!

Comment 5

[Axel Hecht [:Pike]]

I'd say
- OS locale
- Android locale
- made a choice for content locale list yes/no, but not which

Gecko locale shouldn't matter really.

I'm a little torn on the content locale. I think "made a choice" is interesting to measure the need/popularity of that option. I don't know if there's real value in getting which choice was made. Hypothetically, it could indicate a locale to support on the java side, but as I said, I'm torn. I'm throwing a dice on the side of less-data here.

Comment 6

[Karen Rudnitski [:kar]]

I like OS locale and Android locale, and I also don't really see a need for Gecko locale.

I think I would argue for content locale since it would show us not only that local content is being requested, but I think it is important to know which are being requested. Reasoning includes where locale-specific queries are being made (to not only demonstrate where we're making an impact) but to identify the markets that are thirsty for locale-specific info. BUT I could see Axel's point here in whether this would genuinely be useful other than an interesting data point. Could we implement Axel's suggestion (*whether* local content is requested) and if we find a compelling question that could be answered with more refined data, tweak it later?

Comment 7

[Richard Newman [:rnewman]]

OK, I'm most of the way through recording OS locale, Fennec locale, and whether intl.accept_languages is user-set, along with distribution ID.

Initial pull req:

https://github.com/mozilla-services/android-sync/pull/363

Will continue to comment on the other bug. Thanks for the input, Karen and Axel!

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Don't forget to update the associated payload documentation:

https://docs.services.mozilla.com/healthreport/index.html

Comment 9

[Richard Newman [:rnewman]]

See the dev-doc-needed keyword!

Comment 10

[Richard Newman [:rnewman]]

Forward-duping to the bigger bug.