search

QuiiBz / next-international

Type-safe internationalization (i18n) for Next.js
https://next-international.vercel.app
MIT License
1.2k stars 54 forks source link

Plural translations (with count paramater) does not match server-rendered HTML #281

Closed nikitastryuk closed 7 months ago

nikitastryuk commented 8 months ago

Describe the bug Plural translations (with count paramater) which uses "Intl.PluralRules" API determined incorrectly on server ("ua" locale).

locale.ts file { 'test#one': '{count} #one', 'test#other': '{count} #other', }

Issue <p>{t('test', { count: 21 })}</p>

#other is returned from server-rendered html and then transformed to#one on client side.

To Reproduce

  1. Go to Sandbox
  2. Type/ua/client url (like in screenshot below).

Expected behavior Plural translations should be same on both server and client.

About next-international version: 1.1.3 Next.js version: 14.0.1

Video https://github.com/QuiiBz/next-international/assets/32720808/89b4c9aa-8abb-4834-b2c2-01546a03f11e

Screenshots

image
QuiiBz commented 8 months ago

What's your browser? I suspect this is due to a difference in the Intl.PluralRules API across engines.

Here's a test with Firefox, Safari & Chrome and I can't reproduce the bug: Screenshot 2023-11-07 at 10 39 27

nikitastryuk commented 8 months ago

What's your browser? I suspect this is due to a difference in the Intl.PluralRules API across engines.

Here's a test with Firefox, Safari & Chrome and I can't reproduce the bug: Screenshot 2023-11-07 at 10 39 27

@QuiiBz Thanks for such a quick response! I'm using latest chrome.

Could you try ua locale, please? It seems to be working fine for en.

Are you able to open this? Pls, check To Reproduce section from issue description - I see your sandbox is different from mine. Translations should also be used within a client component.

QuiiBz commented 8 months ago

Thanks for fixing the sandbox link. Indeed the issue isn't related to the browser, but that the backend's Intl.PluralRule instance uses a different locale (prob en) than the frontend's Intl.PluralRule instance (ua).

nikitastryuk commented 8 months ago

Thanks for fixing the sandbox link. Indeed the issue isn't related to the browser, but that the backend's Intl.PluralRule instance uses a different locale (prob en) than the frontend's Intl.PluralRule instance (ua).

Just to clarify, you was able to reproduce it as well, right? Should it be fixed on package lvl? Big thanks for taking a look 🙏

QuiiBz commented 8 months ago

Yeah I was able to reproduce with the steps you mentioned, I'll take a look asap to fix it at the package-level.

nikitastryuk commented 8 months ago

UPD after some debugging and investigation:

It started working with uk instead of ua. Looks like Intl.PluralRules works with codes from this list only. Maybe it's a good thing to mention in docs, since ppl could not be aware of internal plural implementation api and it's requirements.

But still not sure why server side initial result is different. Code looks fine.

QuiiBz commented 8 months ago

I just tried and I'm not able to reproduce the bug with the provided CodeSandbox, with en as my default browser language or ua. Both /en/client & /ua/client pages works fine. I'm also using Chrome.

nikitastryuk commented 7 months ago

Issue also exists in next-intl - they say it's env problem. https://github.com/amannn/next-intl/issues/605

Closing this since it's not a pckg issue. Thanks for your support!