Skip to content

sq-AL locale returning different results between node and chrome #41300

Closed as not planned
Closed as not planned
sq-AL locale returning different results between node and chrome#41300
Assignees
srl295
Labels
i18n-apiIssues and PRs related to Node.js internationalization support.

Description

@tiagovtristao
tiagovtristao
opened on Dec 23, 2021

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.

Activity

  1. tiagovtristao commented on Dec 23, 2021

    @tiagovtristao
    tiagovtristao
    on Dec 23, 2021
    Author

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

  2. Mesteery
    added
    i18n-apiIssues and PRs related to Node.js internationalization support.
    on Dec 23, 2021

  3. richardlau commented on Dec 23, 2021

    @richardlau
    richardlau
    on Dec 23, 2021
    Member

    cc @nodejs/i18n-api

  4. ryzokuken commented on Dec 23, 2021

    @ryzokuken
    ryzokuken
    on Dec 23, 2021
    Contributor

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

  5. srl295 commented on Dec 23, 2021

    @srl295
    srl295
    on Dec 23, 2021
    Member

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

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

  6. ryzokuken
    assigned
    srl295
    on Dec 23, 2021

  7. ryzokuken commented on Dec 23, 2021

    @ryzokuken
    ryzokuken
    on Dec 23, 2021
    Contributor

    Done!

  8. srl295 commented on Dec 23, 2021

    @srl295
    srl295
    on Dec 23, 2021
    Member

    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.

  9. kawazoe commented on Jan 13, 2023

    @kawazoe
    kawazoe
    on Jan 13, 2023

    @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?

  10. srl295 commented on Jan 13, 2023

    @srl295
    srl295
    on Jan 13, 2023
    Member

    @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?

  11. kawazoe commented on Jan 13, 2023

    @kawazoe
    kawazoe
    on Jan 13, 2023

    @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.

  12. srl295 commented on Jan 13, 2023

    @srl295
    srl295
    on Jan 13, 2023
    Member

    @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.

  13. kawazoe commented on Jan 13, 2023

    @kawazoe
    kawazoe
    on Jan 13, 2023

    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'

  14. bnoordhuis commented on Jan 14, 2023

    @bnoordhuis
    bnoordhuis
    on Jan 14, 2023
    Member

    @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.

  15. bnoordhuis
    closed this as not plannedon Jan 14, 2023

  16. kawazoe commented on Jan 14, 2023

    @kawazoe
    kawazoe
    on Jan 14, 2023

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

  17. srl295 commented on Jan 14, 2023

    @srl295
    srl295
    on Jan 14, 2023
    Member

    @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?

  18. kawazoe commented on Jan 14, 2023

    @kawazoe
    kawazoe
    on Jan 14, 2023

    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.

  19. srl295 commented on Jan 14, 2023

    @srl295
    srl295
    on Jan 14, 2023
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

i18n-apiIssues and PRs related to Node.js internationalization support.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions