Use plural formats and native digits

Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
Where native digits are not appropriate (non-UI), call sites were
adjusted.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation;tryserver.blink:linux_blink_rel,mac_blink_rel

Committed: https://crrev.com/bccecf36c6ae6bf612174eaaac7effec854877ee
Cr-Commit-Position: refs/heads/master@{#397608}

[jungshik at Google, 2016-05-21 00:07:04]

Description was changed from

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

BUG=613331
==========

to

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[Greg Levin, 2016-05-25 18:33:10]

Description was changed from

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[jungshik at Google, 2016-05-27 17:54:52]

The CQ bit was checked by jshin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-27 17:55:07]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2002783002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2002783002/20001

[jungshik at Google, 2016-05-27 18:01:21]

Description was changed from

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[jungshik at Google, 2016-05-27 18:11:20]

Description was changed from

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
and changed call sites when native digits are not appropriate.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[commit-bot: I haz the power, 2016-05-27 18:12:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-27 18:12:26]

Dry run: Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_x86-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)

[jungshik at Google, 2016-05-27 20:35:10]

The CQ bit was checked by jshin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-27 20:35:39]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2002783002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2002783002/40001

[commit-bot: I haz the power, 2016-05-27 20:53:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-27 20:53:11]

Dry run: Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromeos_x86-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)

[jungshik at Google, 2016-05-29 08:05:51]

The CQ bit was checked by jshin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-29 08:05:56]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2002783002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2002783002/60001

[commit-bot: I haz the power, 2016-05-29 08:19:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-29 08:19:48]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  chromeos_x86-generic_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)

[jungshik at Google, 2016-05-29 08:33:06]

Description was changed from

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
and changed call sites when native digits are not appropriate.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
and changed call sites when native digits are not appropriate.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel,mac_blink_rel
==========

[jungshik at Google, 2016-05-29 08:34:20]

Description was changed from

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
and changed call sites when native digits are not appropriate.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel,mac_blink_rel
==========

to

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
and changed call sites when native digits are not appropriate.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation;tryserver.blink:linux_blink_rel,mac_blink_rel
==========

[jungshik at Google, 2016-05-29 08:35:45]

The CQ bit was checked by jshin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-29 08:35:48]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2002783002/60002
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2002783002/60002

[commit-bot: I haz the power, 2016-05-29 14:25:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-29 14:25:14]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[jungshik at Google, 2016-05-30 08:50:06]

The CQ bit was checked by jshin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-30 08:50:27]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2002783002/90001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2002783002/90001

[commit-bot: I haz the power, 2016-05-30 11:03:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-30 11:03:04]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[jungshik at Google, 2016-05-31 23:15:42]

jshin@chromium.org changed reviewers:
+ anthonyvd@chromium.org, cpu@chromium.org, dbeam@chromium.org,
glevin@chromium.org, mark@chromium.org, rsesek@chromium.org,
sdefresne@chromium.org, sergeyu@chromium.org, stevenjb@chromium.org,
tkent@chromium.org

[jungshik at Google, 2016-05-31 23:15:43]

Hi can you take a look with the following area of focus? 

stevenjb@ : ash/system
mark@: base/,  components/crash/
cpu@: chrome/app/*grd*
sergeyu@: chrome/browser/media/:
anthonyvd@ : chrome/browser/profiles/:
dbeam@: chrome/browser/{ui,resources}
rsesek@: components/crash/core/
sdefresne@: ios/chrome
tkent@: WebKit/..../layout
glevin@: l10n_util, 

Thank you

[jungshik at Google, 2016-05-31 23:17:01]

Description was changed from

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
and changed call sites when native digits are not appropriate.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation;tryserver.blink:linux_blink_rel,mac_blink_rel
==========

to

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
Where native digits are not appropriate (non-UI), call sites were
adjusted.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation;tryserver.blink:linux_blink_rel,mac_blink_rel
==========

[stevenjb, 2016-05-31 23:34:09]

ash/ lgtm

[tkent, 2016-06-01 03:22:02]

third_party/WebKit lgtm

[Sergey Ulanov, 2016-06-01 08:02:17]

chrome/browser/media lgtm

[anthonyvd, 2016-06-01 14:22:12]

c/b/profiles/* lgtm

[Robert Sesek, 2016-06-01 14:34:57]

components/crash/ LGTM

[Mark Mentovai, 2016-06-01 16:42:02]

LGTM in base

[Dan Beam, 2016-06-01 21:33:24]

if i'm reading the documentation on toLocaleString() correctly, should we be
pass the UI language as the first parameter (|locales|)?

[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje...

it seems like the UI language and "the effective locale" might sometimes differ?

https://codereview.chromium.org/2002783002/diff/110001/chrome/browser/resourc...
File chrome/browser/resources/print_preview/settings/dpi_settings.js (right):

https://codereview.chromium.org/2002783002/diff/110001/chrome/browser/resourc...
chrome/browser/resources/print_preview/settings/dpi_settings.js:26: if (hDpi > 0
&& vDpi > 0 && hDpi != vDpi)
needs { curlies } now

[jungshik at Google, 2016-06-01 23:07:19]

Thank you all for taking a look. 

On 2016/06/01 21:33:24, Dan Beam wrote:
> if i'm reading the documentation on toLocaleString() correctly, should we be
> pass the UI language as the first parameter (|locales|)?

It's an optional parameter. When missing, the default locale (in Chrome's web
ui, it'd correspond to Chrome's UI locale). BTW,
Number.prototype.toLocaleString() is implemented as a part of EcmaScript Intl
API in v8. (the default non-i18n implementation in v8 - the same as
Number.prototype.toString() -  is overidden by  i18n-aware implementation in
Intl API. 
( http://www.ecma-international.org/ecma-402/1.0/#sec-13.2.1 )

In Bengali Chrome (on Linux, "LANGUAGE=bn chrome" will do the job), I got this
in the JS console :

(new Number(345)).toLocaleString()
"৩৪৫"


> 
> [1]
>
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje...
> 
> it seems like the UI language and "the effective locale" might sometimes
differ?

Do you have this in mind (
http://w3c.github.io/html/webappapis.html#language-preferences )? Afaik, Blink's
navigator.language (singular) implementation does not follow the draft spec
(according to which its value should be the top language in the Accept-Language
list). Instead, it just returns the UI language. So, we can pass
'window.navigator.language' explicitly (is window.* always available for web
ui?). 

Anyway, right now, toLocaleString() and
toLocaleString(window.navigator.language) would be identical. 

BTW,going off a bit tangential...  distinguishing UI-resource language from the
default 'i18n' language (formatting, sorting, etc) when necessary is in my TODO
list. For instance, if the OS UI language is en-AU on Mac, Android or Linux,
Chrome's resource bundle language (translated strings) would fall back to en-GB
(because we don't have separate translation for en-AU), but en-AU should be used
for formatting, sorting, etc.

[jungshik at Google, 2016-06-01 23:20:22]

https://codereview.chromium.org/2002783002/diff/110001/chrome/browser/resourc...
File chrome/browser/resources/print_preview/settings/dpi_settings.js (right):

https://codereview.chromium.org/2002783002/diff/110001/chrome/browser/resourc...
chrome/browser/resources/print_preview/settings/dpi_settings.js:26: if (hDpi > 0
&& vDpi > 0 && hDpi != vDpi)
On 2016/06/01 21:33:24, Dan Beam wrote:
> needs { curlies } now

Done.

[jungshik at Google, 2016-06-01 23:31:02]

On 2016/06/01 23:07:19, jungshik at google wrote:
> Thank you all for taking a look. 
> 
> On 2016/06/01 21:33:24, Dan Beam wrote:
> > if i'm reading the documentation on toLocaleString() correctly, should we be
> > pass the UI language as the first parameter (|locales|)?
> 
> It's an optional parameter. When missing, the default locale (in Chrome's web
> ui, it'd correspond to Chrome's UI locale). BTW,
> Number.prototype.toLocaleString() is implemented as a part of EcmaScript Intl
> API in v8. (the default non-i18n implementation in v8 - the same as
> Number.prototype.toString() -  is overidden by  i18n-aware implementation in
> Intl API. 
> ( http://www.ecma-international.org/ecma-402/1.0/#sec-13.2.1 )
> 
> In Bengali Chrome (on Linux, "LANGUAGE=bn chrome" will do the job), I got this
> in the JS console :
> 
> (new Number(345)).toLocaleString()
> "৩৪৫"
> 
> 
> > 
> > [1]
> >
>
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje...
> > 
> > it seems like the UI language and "the effective locale" might sometimes
> differ?
> 
> Do you have this in mind (
> http://w3c.github.io/html/webappapis.html#language-preferences )? Afaik,
Blink's
> navigator.language (singular) implementation does not follow the draft spec
> (according to which its value should be the top language in the
Accept-Language
> list). Instead, it just returns the UI language. So, we can pass
> 'window.navigator.language' explicitly (is window.* always available for web
> ui?). 
> 
> Anyway, right now, toLocaleString() and
> toLocaleString(window.navigator.language) would be identical. 

To clarify, in general, I prefer specifying an explicit language/locale to
relying on the default. 
However, using window.navigator.language is not future-proof because Blink may
decide to follow the 
draft spec and returns the top language in the Accept-Language list (that can be
different from the browser 
UI language). 

If chrome.i18n.getUILanguage() can be used, I'd use it, but I guess it can't be
here.

[Dan Beam, 2016-06-01 23:33:31]

On 2016/06/01 23:07:19, jungshik at google wrote:
> Thank you all for taking a look. 
> 
> On 2016/06/01 21:33:24, Dan Beam wrote:
> > if i'm reading the documentation on toLocaleString() correctly, should we be
> > pass the UI language as the first parameter (|locales|)?
> 
> It's an optional parameter. When missing, the default locale (in Chrome's web
> ui, it'd correspond to Chrome's UI locale). BTW,
> Number.prototype.toLocaleString() is implemented as a part of EcmaScript Intl
> API in v8. (the default non-i18n implementation in v8 - the same as
> Number.prototype.toString() -  is overidden by  i18n-aware implementation in
> Intl API. 
> ( http://www.ecma-international.org/ecma-402/1.0/#sec-13.2.1 )
> 
> In Bengali Chrome (on Linux, "LANGUAGE=bn chrome" will do the job), I got this
> in the JS console :
> 
> (new Number(345)).toLocaleString()
> "৩৪৫"
> 
> 
> > 
> > [1]
> >
>
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje...
> > 
> > it seems like the UI language and "the effective locale" might sometimes
> differ?
> 
> Do you have this in mind (
> http://w3c.github.io/html/webappapis.html#language-preferences )? Afaik,
Blink's
> navigator.language (singular) implementation does not follow the draft spec
> (according to which its value should be the top language in the
Accept-Language
> list). Instead, it just returns the UI language. So, we can pass
> 'window.navigator.language' explicitly (is window.* always available for web
> ui?). 
> 
> Anyway, right now, toLocaleString() and
> toLocaleString(window.navigator.language) would be identical. 
> 
> BTW,going off a bit tangential...  distinguishing UI-resource language from
the
> default 'i18n' language (formatting, sorting, etc) when necessary is in my
TODO
> list. For instance, if the OS UI language is en-AU on Mac, Android or Linux,
> Chrome's resource bundle language (translated strings) would fall back to
en-GB
> (because we don't have separate translation for en-AU), but en-AU should be
used
> for formatting, sorting, etc.

http://w3c.github.io/html/webappapis.html#plausible-languages this does imply
that Accept-Language should be used to specify "a plausible language".  I'm
getting similar results for `navigator.language` (UI lang) and
`navigator.languages` (Accept-Language in the order I've specified in
chrome://settings/languages).

Many users probably prefer their web content in a language different than the UI
language they run Chrome.  Because these translations are in the context of the
browser UI, Accept-Language should not affect them (now or in the future if we
update `navigator.language`).  I propose we pass something like:

  .toLocaleString(loadTimeData.getString('lang'))

or create a more specific 'locale' key in loadTimeData to allow additional
qualifiers.

And yes: you identified the example of using LANGUAGE= on Linux in which you can
get into a state that the UI lang, system lang, and `navigator.language` could
all differ (though this seems crazy rare in practice).

[Dan Beam, 2016-06-01 23:34:55]

On 2016/06/01 23:33:31, Dan Beam wrote:
> On 2016/06/01 23:07:19, jungshik at google wrote:
> > Thank you all for taking a look. 
> > 
> > On 2016/06/01 21:33:24, Dan Beam wrote:
> > > if i'm reading the documentation on toLocaleString() correctly, should we
be
> > > pass the UI language as the first parameter (|locales|)?
> > 
> > It's an optional parameter. When missing, the default locale (in Chrome's
web
> > ui, it'd correspond to Chrome's UI locale). BTW,
> > Number.prototype.toLocaleString() is implemented as a part of EcmaScript
Intl
> > API in v8. (the default non-i18n implementation in v8 - the same as
> > Number.prototype.toString() -  is overidden by  i18n-aware implementation in
> > Intl API. 
> > ( http://www.ecma-international.org/ecma-402/1.0/#sec-13.2.1 )
> > 
> > In Bengali Chrome (on Linux, "LANGUAGE=bn chrome" will do the job), I got
this
> > in the JS console :
> > 
> > (new Number(345)).toLocaleString()
> > "৩৪৫"
> > 
> > 
> > > 
> > > [1]
> > >
> >
>
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje...
> > > 
> > > it seems like the UI language and "the effective locale" might sometimes
> > differ?
> > 
> > Do you have this in mind (
> > http://w3c.github.io/html/webappapis.html#language-preferences )? Afaik,
> Blink's
> > navigator.language (singular) implementation does not follow the draft spec
> > (according to which its value should be the top language in the
> Accept-Language
> > list). Instead, it just returns the UI language. So, we can pass
> > 'window.navigator.language' explicitly (is window.* always available for web
> > ui?). 
> > 
> > Anyway, right now, toLocaleString() and
> > toLocaleString(window.navigator.language) would be identical. 
> > 
> > BTW,going off a bit tangential...  distinguishing UI-resource language from
> the
> > default 'i18n' language (formatting, sorting, etc) when necessary is in my
> TODO
> > list. For instance, if the OS UI language is en-AU on Mac, Android or Linux,
> > Chrome's resource bundle language (translated strings) would fall back to
> en-GB
> > (because we don't have separate translation for en-AU), but en-AU should be
> used
> > for formatting, sorting, etc.
> 
> http://w3c.github.io/html/webappapis.html#plausible-languages this does imply
> that Accept-Language should be used to specify "a plausible language".  I'm
> getting similar results for `navigator.language` (UI lang) and
> `navigator.languages` (Accept-Language in the order I've specified in
> chrome://settings/languages).
> 
> Many users probably prefer their web content in a language different than the
UI
> language they run Chrome.  Because these translations are in the context of
the
> browser UI, Accept-Language should not affect them (now or in the future if we
> update `navigator.language`).  I propose we pass something like:
> 
>   .toLocaleString(loadTimeData.getString('lang'))
> 
> or create a more specific 'locale' key in loadTimeData to allow additional
> qualifiers.
> 
> And yes: you identified the example of using LANGUAGE= on Linux in which you
can
> get into a state that the UI lang, system lang, and `navigator.language` could
> all differ (though this seems crazy rare in practice).

`navigator.language` => `navigator.languages[0]`

[jungshik at Google, 2016-06-02 00:13:22]

On 2016/06/01 23:34:55, Dan Beam wrote:
> On 2016/06/01 23:33:31, Dan Beam wrote:
> > On 2016/06/01 23:07:19, jungshik at google wrote:
> > > Thank you all for taking a look. 
> > > 
> > > On 2016/06/01 21:33:24, Dan Beam wrote:
> > > > if i'm reading the documentation on toLocaleString() correctly, should
we
> be
> > > > pass the UI language as the first parameter (|locales|)?
> > > 
> > > It's an optional parameter. When missing, the default locale (in Chrome's
> web
> > > ui, it'd correspond to Chrome's UI locale). BTW,
> > > Number.prototype.toLocaleString() is implemented as a part of EcmaScript
> Intl
> > > API in v8. (the default non-i18n implementation in v8 - the same as
> > > Number.prototype.toString() -  is overidden by  i18n-aware implementation
in
> > > Intl API. 
> > > ( http://www.ecma-international.org/ecma-402/1.0/#sec-13.2.1 )
> > > 
> > > In Bengali Chrome (on Linux, "LANGUAGE=bn chrome" will do the job), I got
> this
> > > in the JS console :
> > > 
> > > (new Number(345)).toLocaleString()
> > > "৩৪৫"
> > > 
> > > 
> > > > 
> > > > [1]
> > > >
> > >
> >
>
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje...
> > > > 
> > > > it seems like the UI language and "the effective locale" might sometimes
> > > differ?
> > > 
> > > Do you have this in mind (
> > > http://w3c.github.io/html/webappapis.html#language-preferences )? Afaik,
> > Blink's
> > > navigator.language (singular) implementation does not follow the draft
spec
> > > (according to which its value should be the top language in the
> > Accept-Language
> > > list). Instead, it just returns the UI language. So, we can pass
> > > 'window.navigator.language' explicitly (is window.* always available for
web
> > > ui?). 
> > > 
> > > Anyway, right now, toLocaleString() and
> > > toLocaleString(window.navigator.language) would be identical. 
> > > 
> > > BTW,going off a bit tangential...  distinguishing UI-resource language
from
> > the
> > > default 'i18n' language (formatting, sorting, etc) when necessary is in my
> > TODO
> > > list. For instance, if the OS UI language is en-AU on Mac, Android or
Linux,
> > > Chrome's resource bundle language (translated strings) would fall back to
> > en-GB
> > > (because we don't have separate translation for en-AU), but en-AU should
be
> > used
> > > for formatting, sorting, etc.
> > 
> > http://w3c.github.io/html/webappapis.html#plausible-languages this does
imply
> > that Accept-Language should be used to specify "a plausible language".  I'm
> > getting similar results for `navigator.language` (UI lang) and
> > `navigator.languages` (Accept-Language in the order I've specified in
> > chrome://settings/languages).

The draft spec requires that navigator.language == navigator.languages[0], but
Blink does not
implement that (i.e. in Blink it's possible that navigator.language !=
navigator.languages[0]). 
I was against the proposal because having two ways to get to the top of A-L list
is not
that useful. More importantly, we'd lose a way to get the browser UI language.
(With the A-L
list available, making the UI language available does not seem to be a huge
additional risk 
in terms of privacy/user profiling). 

> > 
> > Many users probably prefer their web content in a language different than
the
> UI
> > language they run Chrome.  Because these translations are in the context of
> the
> > browser UI, Accept-Language should not affect them (now or in the future if
we
> > update `navigator.language`).  

I fully agree with you.  navigator.language (when it is CHANGED to be equal to
navigator.languages[0]) should NOT
affect the way numbers are formatted in Chrome's web UI, which is why I'd not
use it. 

> > I propose we pass something like:
> > 
> >   .toLocaleString(loadTimeData.getString('lang'))
> > 
> > or create a more specific 'locale' key in loadTimeData to allow additional
> > qualifiers.

Is there a central place where I can add 'locale' key to be propagated
everywhere in webUI instead of calling AddString() in individual
WebUIDataSource's?  

BTW, |AddString('uiLocale', g_browser_process->GetApplicationLocale())| and
retrieving the value with loadTimeData and passing it to toLocaleString() is 
equivalent to using toLocaleString() with no parameter in all the scenarios
considered here. So, I'm not sure what we're gaining except for the general
'kosherness' of not relying on the default.

[Dan Beam, 2016-06-02 01:05:25]

On 2016/06/02 00:13:22, jungshik at google wrote:
> On 2016/06/01 23:34:55, Dan Beam wrote:
> > On 2016/06/01 23:33:31, Dan Beam wrote:
> > > On 2016/06/01 23:07:19, jungshik at google wrote:
> > > > Thank you all for taking a look. 
> > > > 
> > > > On 2016/06/01 21:33:24, Dan Beam wrote:
> > > > > if i'm reading the documentation on toLocaleString() correctly, should
> we
> > be
> > > > > pass the UI language as the first parameter (|locales|)?
> > > > 
> > > > It's an optional parameter. When missing, the default locale (in
Chrome's
> > web
> > > > ui, it'd correspond to Chrome's UI locale). BTW,
> > > > Number.prototype.toLocaleString() is implemented as a part of EcmaScript
> > Intl
> > > > API in v8. (the default non-i18n implementation in v8 - the same as
> > > > Number.prototype.toString() -  is overidden by  i18n-aware
implementation
> in
> > > > Intl API. 
> > > > ( http://www.ecma-international.org/ecma-402/1.0/#sec-13.2.1 )
> > > > 
> > > > In Bengali Chrome (on Linux, "LANGUAGE=bn chrome" will do the job), I
got
> > this
> > > > in the JS console :
> > > > 
> > > > (new Number(345)).toLocaleString()
> > > > "৩৪৫"
> > > > 
> > > > 
> > > > > 
> > > > > [1]
> > > > >
> > > >
> > >
> >
>
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Obje...
> > > > > 
> > > > > it seems like the UI language and "the effective locale" might
sometimes
> > > > differ?
> > > > 
> > > > Do you have this in mind (
> > > > http://w3c.github.io/html/webappapis.html#language-preferences )? Afaik,
> > > Blink's
> > > > navigator.language (singular) implementation does not follow the draft
> spec
> > > > (according to which its value should be the top language in the
> > > Accept-Language
> > > > list). Instead, it just returns the UI language. So, we can pass
> > > > 'window.navigator.language' explicitly (is window.* always available for
> web
> > > > ui?). 
> > > > 
> > > > Anyway, right now, toLocaleString() and
> > > > toLocaleString(window.navigator.language) would be identical. 
> > > > 
> > > > BTW,going off a bit tangential...  distinguishing UI-resource language
> from
> > > the
> > > > default 'i18n' language (formatting, sorting, etc) when necessary is in
my
> > > TODO
> > > > list. For instance, if the OS UI language is en-AU on Mac, Android or
> Linux,
> > > > Chrome's resource bundle language (translated strings) would fall back
to
> > > en-GB
> > > > (because we don't have separate translation for en-AU), but en-AU should
> be
> > > used
> > > > for formatting, sorting, etc.
> > > 
> > > http://w3c.github.io/html/webappapis.html#plausible-languages this does
> imply
> > > that Accept-Language should be used to specify "a plausible language". 
I'm
> > > getting similar results for `navigator.language` (UI lang) and
> > > `navigator.languages` (Accept-Language in the order I've specified in
> > > chrome://settings/languages).
> 
> The draft spec requires that navigator.language == navigator.languages[0], but
> Blink does not
> implement that (i.e. in Blink it's possible that navigator.language !=
> navigator.languages[0]). 
> I was against the proposal because having two ways to get to the top of A-L
list
> is not
> that useful. More importantly, we'd lose a way to get the browser UI language.
> (With the A-L
> list available, making the UI language available does not seem to be a huge
> additional risk 
> in terms of privacy/user profiling). 
> 
> > > 
> > > Many users probably prefer their web content in a language different than
> the
> > UI
> > > language they run Chrome.  Because these translations are in the context
of
> > the
> > > browser UI, Accept-Language should not affect them (now or in the future
if
> we
> > > update `navigator.language`).  
> 
> I fully agree with you.  navigator.language (when it is CHANGED to be equal to
> navigator.languages[0]) should NOT
> affect the way numbers are formatted in Chrome's web UI, which is why I'd not
> use it. 
> 
> > > I propose we pass something like:
> > > 
> > >   .toLocaleString(loadTimeData.getString('lang'))
> > > 
> > > or create a more specific 'locale' key in loadTimeData to allow additional
> > > qualifiers.
> 
> Is there a central place where I can add 'locale' key to be propagated
> everywhere in webUI instead of calling AddString() in individual
> WebUIDataSource's?  

This looks like a good one: https://codereview.chromium.org/2032843002/

> 
> BTW, |AddString('uiLocale', g_browser_process->GetApplicationLocale())| and
> retrieving the value with loadTimeData and passing it to toLocaleString() is 
> equivalent to using toLocaleString() with no parameter in all the scenarios
> considered here. So, I'm not sure what we're gaining except for the general
> 'kosherness' of not relying on the default.

this is kind of an anti-pattern, but maybe you could make a change detection
test that determines if `navigator.language` differs from the UI language or
anything else that might make it necessary to plumb this value for something
other than precaution?

[jungshik at Google, 2016-06-02 09:04:44]

> > > > I propose we pass something like:
> > > > 
> > > >   .toLocaleString(loadTimeData.getString('lang'))
> > > > 
> > > > or create a more specific 'locale' key in loadTimeData to allow
additional
> > > > qualifiers.
> > 
> > Is there a central place where I can add 'locale' key to be propagated
> > everywhere in webUI instead of calling AddString() in individual
> > WebUIDataSource's?  
> 
> This looks like a good one: https://codereview.chromium.org/2032843002/

Thank for your proposal. I thought about that function as well.  As your CL 
subject line implies, the function has to be called explicitly wherever 'locale'
is necessary, doesn't it?. 

Hmm...  that function is also called in WebUIDataSource's factory method
(eventually going to WebUIDataSourceImpl) 
https://cs.chromium.org/chromium/src/content/browser/webui/web_ui_data_source...
So, it seems to fit the bill in most cases except that it's passing the value
obtained with GetApplicationLocale() (which is kinda passing
the value that is already available to v8 as explained below). 


> > 
> > BTW, |AddString('uiLocale', g_browser_process->GetApplicationLocale())| and
> > retrieving the value with loadTimeData and passing it to toLocaleString() is

> > equivalent to using toLocaleString() with no parameter in all the scenarios
> > considered here. So, I'm not sure what we're gaining except for the general
> > 'kosherness' of not relying on the default.
> 
> this is kind of an anti-pattern, but maybe you could make a change detection
> test that determines if `navigator.language` differs from the UI language or
> anything else that might make it necessary to plumb this value for something
> other than precaution?

I'm not sure what you have in mind with 'a change detection test'. 

Taking a step back, I suspect your *initial* worry about using toLocaleString
with NO parameter comes from your concern that
the default locale used by toLocaleString() CAN be different from the browser UI
language. 

They're  identical in Chrome because  of the following:
1. the default locale in v8 (toLocaleString()) comes from the ICU default locale
in a render process.  
2. The ICU default locale in a render process is inherited from the ICU default
locale in the browser process. 
3. The ICU default locale in browser locale is set to the browser UI locale
after determining the browser 
  UI language in a platform-dependent manner ( a. On Windows, OS locales and
command line
  param is considered. b. On Mac, System pref-Intl-Lang is used.  c. Linux: 
LANGUAGE, LC_ALL, etc are taken into account
  d. Android: OS locale 5. Chrome OS: the OS locale == browser locale ) 

When the OS locale is changed (while Chrome is running) in Settings app on
Android, Chrome-Android automatically restarts [1] . On Linux/Mac/Windows,
Chrome does not
change the UI language until it's manually restarted by a user.   On Chrome OS,
changing the browser UI language requires restart/relaunch. 

So, on all platforms, they should agree.  

The only thing I'm not sure about is Android WebView. Somehow I can't make the
test page [1] work in Android WebView. 
I'll try something else to see how Android WebView responds to the Android OS
language preference change. 

[1] 1. Go to http://jungshik.github.io/cr/default_locale.html and touch on the
button. Note that the 2nd line
        uses toLocaleString()  for a Date object. 
     2. In Settings app on Android, change the OS UI language
     3. Go back to Chrome. Note that it's 'restarted' and the page is reloading
     4. Touch on the button and see the (new Date).toLocaleString() now formats
Date per the new browser locale.

[Dan Beam, 2016-06-02 19:15:29]

if that's the trail of how the default locale makes it to v8, then lgtm

thanks for bearing with me

[jungshik at Google, 2016-06-02 20:33:36]

jshin@chromium.org changed reviewers:
+ pkasting@google.com

[jungshik at Google, 2016-06-02 20:33:38]

Thank you, Dan !

Peter, can you take a look at chrome/browser/ui?  Thank

[jungshik at Google, 2016-06-02 20:38:11]

jshin@chromium.org changed reviewers:
+ jyquinn@chromium.org, pkasting@chromium.org
- pkasting@google.com

[jungshik at Google, 2016-06-02 20:38:12]

Jackie, can you take a look at ios/chrome/app/resources/history/? Thanks !

Peter (this time @chromium.org email), can you take a look at
chrome/browser/ui/?  Thanks

[Peter Kasting, 2016-06-02 21:55:08]

LGTM

[Jackie Quinn, 2016-06-02 23:12:06]

On 2016/06/02 21:55:08, Peter Kasting wrote:
> LGTM

ios lgtm

[jungshik at Google, 2016-06-02 23:51:55]

The CQ bit was checked by jshin@chromium.org

[jungshik at Google, 2016-06-02 23:51:56]

The patchset sent to the CQ was uploaded after l-g-t-m from
stevenjb@chromium.org, sergeyu@chromium.org, anthonyvd@chromium.org,
mark@chromium.org, tkent@chromium.org, rsesek@chromium.org,
pkasting@chromium.org, dbeam@chromium.org, jyquinn@chromium.org
Link to the patchset: https://codereview.chromium.org/2002783002/#ps150001
(title: "plural: use "=1" instead of "one" for pop-up block infobar")

[commit-bot: I haz the power, 2016-06-02 23:53:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2002783002/150001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2002783002/150001

[commit-bot: I haz the power, 2016-06-03 03:00:16]

Committed patchset #9 (id:150001)

[commit-bot: I haz the power, 2016-06-03 03:01:17]

Description was changed from

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
Where native digits are not appropriate (non-UI), call sites were
adjusted.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation;tryserver.blink:linux_blink_rel,mac_blink_rel
==========

to

==========
Use plural formats and native digits

With codesearch, look for '<ex>[0-9]+</ex> file:grd'. Review each of
matches and change them to use plural formats(C++), toLocaleString(JavaScript),
or other i18n-safe ways.

Moreover, change GetStringFUTF16Int() to use 'FormatNumber' instead
of Int*ToString(). Call sites of GetStringFUTF16Int() were reviewed
Where native digits are not appropriate (non-UI), call sites were
adjusted.

Besides, add a warning about 'ASCII digits vs native digits' to
base/strings/string_number_conversions.h and add more details
on GetPlural* to ui/base/l10n/l10n_util.h.

BUG=613331
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation;tryserver.blink:linux_blink_rel,mac_blink_rel

Committed: https://crrev.com/bccecf36c6ae6bf612174eaaac7effec854877ee
Cr-Commit-Position: refs/heads/master@{#397608}
==========

[commit-bot: I haz the power, 2016-06-03 03:01:19]

Patchset 9 (id:??) landed as
https://crrev.com/bccecf36c6ae6bf612174eaaac7effec854877ee
Cr-Commit-Position: refs/heads/master@{#397608}