sq-AL locale returning different results between node and chrome

[tiagovtristao]

Version

v16.13.1

Platform

Linux xxxxxxxxxxxxx 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

const formatter = new Intl.NumberFormat('sq-AL', {style: 'currency', currency: 'USD', maximumFractionDigits: 20, currencyDisplay: 'narrowSymbol'})

const value = formatter.format(65421.45)

// `value === '65 421,45 USD'` on Node v16.13.1
// `value === '$65,421.45'` on Chrome Version 96.0.4664.111 (Official Build) (64-bit)

How often does it reproduce? Is there a required condition?

Always. No.

What is the expected behavior?

The value $65,421.45 seems to be the correct one. We used to load the ICU data onto the runtime when using Node 12 and this was the value that we were getting. This mismatch i being experienced as we are upgrading to Node 16.

What do you see instead?

65 421,45 USD instead of $65,421.45

Additional information

The node tarball was installed from the node website.

[tiagovtristao]

I'm seeing the same issue across all related locales: sq-MK, sq-XK and sq. All other locales seem fine.

[richardlau]

cc @nodejs/i18n-api

[ryzokuken]

@srl295 any idea why this might be happening? Perhaps missing CLDR data?

[srl295]

@srl295 any idea why this might be happening? Perhaps missing CLDR data?

You can assign to me and mention @nodejs/i18n-api

[ryzokuken]

Done!

[srl295]

OK so it's working as designed— the Albanian data shows USD as the currency symbol. I'll mention this to CLDR https://cldr.unicode.org to verify that the data is correct.

[kawazoe]

@srl295 Hey sorry for necroposting, but I thought it might be appropriate. I'm seeing a similar issue with the en-CA locale. Dates uses - in chrome but / in node (tested on linux and macos on v19.3). Do you want me to create a new issue for this?

[srl295]

@srl295 Hey sorry for necroposting, but I thought it might be appropriate. I'm seeing a similar issue with the en-CA locale. Dates uses - in chrome but / in node (tested on linux and macos on v19.3). Do you want me to create a new issue for this?

What exact chrome version? What does process.versions.cldr give and process.versions.icu?

[kawazoe]

@srl295 I've tested with:
macOS 13.1 - Chrome Version 108.0.5359.124 (Official Build) (arm64)
Garuda Linux - Brave Version 1.46.144 Chromium: 108.0.5359.128 (Official Build) unknown (64-bit)

Node 19.3.0 (on mac and linux) with ICU 72.1 and CLDR 42.0 (on mac and linux).

Running new Date().toLocaleDateString('en-CA') gives different results.

[srl295]

@srl295 I've tested with:

macOS 13.1 - Chrome Version 108.0.5359.124 (Official Build) (arm64)

Garuda Linux - Brave Version 1.46.144 Chromium: 108.0.5359.128 (Official Build) unknown (64-bit)

Node 19.3.0 (on mac and linux) with ICU 72.1 and CLDR 42.0 (on mac and linux).

Running new Date().toLocaleDateString('en-CA') gives different results.

Kindly post the results.

9/10 chance it's working as designed but I'll check into it.

And all, we should perhaps have some kind of guide as to how to deal with these questions.

[kawazoe]

The results are completely different. They use different separators, and even a different date order.

new Date().toLocaleDateString('en-CA')

browsers: '2023-01-13'
node:     '1/13/2023'

[bnoordhuis]

@kawazoe see #45945 (comment) for an explanation. I'm going to close this issue because I don't think there's anything left to do.

@srl295 by all means reopen if I'm mistaken.

[kawazoe]

@bnoordhuis Thanks for pointing out this issue to me. I don't know why it didn't came up in my searches yesterday.

[srl295]

@bnoordhuis 💯 correct.

Q for you or anyone Is there a better way to handle this? I would have 100% of these 'different results' tickets go through some kind of FAQ and steps to do what you did in evaluating changes. Would that be useful to have in the intl docs? Or even in ecma402 and or MDN docs?

[kawazoe]

As long as its visible, with links to the relevant cldr deltas, that would be amazing. Something that would really help avoid the questions in the first play, though, is a way to easily check which version of ICU the browser was compiled against. Looking through Chromium's repo, I eventually found that they are using v72.1, but I have no way to tell if this has been released or not already and when it was/will happen(ed).

What made me ask in the first place wasn't that node results differed from Chrome. It was that I blindly assumed Chrome to be correct in the first place.

[srl295]

As long as its visible, with links to the relevant cldr deltas, that would be amazing.

CLDR charts are at https://cldr.unicode.org/index/charts ( note: please do not bookmark deep links into these, we are adjusting how/where the charts are hosted. )

What I had in mind was a guide for doing what @bnoordhuis did in terms of analysis.

Something that would really help avoid the questions in the first play, though, is a way to easily check which version of ICU the browser was compiled against. Looking through Chromium's repo, I eventually found that they are using v72.1, but I have no way to tell if this has been released or not already and when it was/will happen(ed).

@sffc can you answer this? Otherwise maybe file a Chromium ticket I suppose.

What made me ask in the first place wasn't that node results differed from Chrome. It was that I blindly assumed Chrome to be correct in the first place.

I'd check the CLDR charts and/or data. But again, perhaps a guide would help here.