Can you please provide us with a sample html test case for the ease of finding regression.

I tested few other languages: this bug applies to all the scandinavian languages but German (using same seporators as scandinavian languages) is ok !

Ok here is sample html to show the intl.numberformat errors in Chrome.
Internet explorer passes this test.
Firefox fails for Norway.
Chrome fails for all scandinavian countries exept Finnland

..yes and if you are going to fix Scandinavian langueges do not to forget our favorate cusins the Faroese :)

Deleted: CrhromeIntlTest.html 3.2 KB

CrhromeIntlTest.html 3.2 KB View Download

.. yes and Greenland kl-KL  (same as Danish number format)

Able to reproduce the issue on Win 10,Mac 10.11.6 and Ubuntu 14.04 using stable 54.0.2840.99.
This is a non-regression issue since M 32.0.1652.0.
Untriaged so as to get addressed further.

Dan, could you take a look or pass on appropriately? Thanks!

I think Icelandic is likely not a supported locale of Chrome (not sure where the list is--is this the right list? https://developer.chrome.com/webstore/i18n?csw=1#localeTable). We should probably fall back to Danish here, but the ECMA 402 (Intl) spec doesn't actually permit that right now. Mark Davis has suggested to me that we pursue more advanced fallback APIs as an addition to Intl, but this work has not yet begun. Jungshik, do you have any more to add?

Fall backing 'is', 'fo' and 'kl' to the Danish locale 'da' would work fine for number formatting if.....  the 'da' locale where working correctly in the first place, which it is not.

I took a look at your test, and the failures break down as follows:
- For Danish, the locale is da (or da-DK), but your test uses dk
- Norwegian may be an unsupported locale for these purposes (fall back to Danish? sorry)
- The Swedish locale code is sv, which seems to work for me. Your test uses se, which is Sami, which is unsupported.
- Icelandic is unsupported.

AHA: I stand corrected for Danish and Swedish, sorry about that.
Norwegian number format should fall back to Swedish rather than Danish.

So the outstanding issue seems to be adding lots and lots of fallbacks for unsuported languages.  
The idea of Intl seems pointless if only portion of the world locales are supported.  
Firefox and IE are handling Intl pretty well so it should not be unreasonable that Chrome could cover it as well.

I took a better look at Norwegian cultures, my previous test did not cover Norwegian correctly.
Norwegian has two cultures:
nb-NO - Norwegian Book language (Bokmål)   and
nn-NO - New Norwegian - (Nynorsk)

nb-NO Renders correctly in Chrome but nn-NO not.

Deleted: CrhromeIntlTest.html 3.7 KB

CrhromeIntlTest.html 3.7 KB View Download

That makes sense that we have the locale with more speakers supported but not the one with fewer speakers. There is cost to shipping more locales--it increases the size of the download, which is important to keep small on mobile. This may be a reason to invest in dynamically downloading more language support later, but we don't currently have the infrastructure for this supoort. That's a broader issue, so let's consider this big working as intended.

In tha case there is one fall back you may consider using for smaller languages:
using fallback mapping per country, since there are only 300+ of them and you can eniminate from that those that are supported.
For example:
IS -> da-DK
NO -> nb-NO
FI -> fi-FI
..
This really should not make a bent in your download size.

To: littledan@chromium.org
I am not sure that Intl implementation is satisfied by relying on users downloading language pack for his or her language/culture.   One reason is that many users just prefer to use the default English as the browser language.   Web applications may also for some reason choose to display values in different cultures despite what language the browser supports.

I found an excellent article from Igor Krupitsky explaining number formats for world cultures.
http://www.codeproject.com/Articles/78175/International-Number-Formats

  According to this article the raw data needed to calculate number format for each world culture takes only up 100bytes (see below).

  I would like to suggest to you a method for calculating the number format for each county based on this data.  Extra benefit for this method, besides handling all cultures and being light weighted, is that this method is also error tolerant to misspelled culture strings, and handles 2 char culture strings sometimes used for some countries.  Example:   ‘is’ as a replacement for ‘is-IS’

We have 7 different combinations of number formats:
1	,.	default
2	.,	
3	'.
4	 ,	(space ,)
5	,/
6	 -	(space -)
7	 .	(space .)

Countries that need second round for mapping since Canada and Luxembourg can have two different number formats within the same country:
CA,LU

Countries that map to 2:
DK,DE, GR, IS,IT,NL,BR,RO,HR,AL,SE,TR,ID,SL,LT,VN,MK, FO,MY, BE,PT, CS, BN, AT,ES, CR, VE,CO, AR, EC, CL, UY, PY, BO,BA, 
de-LU

Countries that map to 3:
CH,LI
Then countries that map to 4:
BG, CZ, FI,FR,HU, NO,PL,RU,SK, UA, BY, LV, AZ,GE, UZ, MN, FI, MC
fr-CA, lb-LU, fr-LU
Countries that map to 5:
IR
Countries that map to 6:
KZ, KG
Countries that map to 7:
EE


Calculation steps:
0.	Check cashing array of calculated value for the culture
1.	x = Uppercase last 2 characters of the culture
2.	case x in LU,CA  x = the whole culture string
3.	case x in mapto2 return culture 2
4.	case x in mapto3 return culture 3
5.	case x in mapto4 return culture 4
6.	case x in mapto5 return culture 5
7.	case x in mapto6 return culture 6
8.	case x in mapto7 return culture 7
9.	else return culture 1 (default).
10.	Save the calculated value to cashing array