ICU breaks 'replace' and 'replaceObjects: true' & XSS about i18next-icu HOT 11 OPEN

Basically using i18next-icu - non of the i18next specific stuff is available...only what intl-messageformat provides...

so all things that are bound to i18next plurals, interpolation, context does not get applied...only the direct t call with messageformat specific options.

Alternative: use locize.com -> the i18next plurals work perfectly there (beside other benefits). And you directly support the people bringing i18next to you.

from i18next-icu.

if not sure if i18next format is mature enough in comparison to intl...just check https://npmtrends.com/react-i18next-vs-react-intl

from i18next-icu.

Note that my use case is NOT React, but something server-side. I need to be able to render to string, not asynchronous via React Suspense, etc.

Alternative: use locize.com -> the i18next plurals work perfectly there (beside other benefits). And you directly support the people bringing i18next to you.

I can't make that decision.

from i18next-icu.

i18next with both client and serverside in mind. first version basically was pure clientside js and serverside nodejs with expressjs

--> latest module for serverside: https://github.com/i18next/i18next-http-middleware

from i18next-icu.

Thanks for your quick reply.

Basically using i18next-icu - non of the i18next specific stuff is available...only what intl-messageformat provides...

so all things that are bound to i18next plurals, interpolation, context does not get applied...only the direct t call with messageformat specific options.

I really think this should be part of the docs! A big fat disclaimer a the top.

from i18next-icu.

https://github.com/i18next/i18next-icu/tree/master?tab=readme-ov-file#hints

from i18next-icu.

8811eb0
👍 ❤️

i18next-icu calls Intl immediately. I have the feeling though this is a design choice, and instead the plugin could also be implemented in a way that only the interpolation is handed off to Intl, still supporting objects, don't you agree?

from i18next-icu.

just one other sidenote to consider...there is a working group for messageformat 2 https://github.com/unicode-org/message-format-wg so the current icu stuff might be outdated midterm

from i18next-icu.

the design choice was supporting some formats beside i18next: https://www.i18next.com/overview/plugins-and-utils#i18n-formats

as those are very different eg. fluent coming with some catalog format not only single strings we made the decision you get stuff like language-detectors, backends, ... but all the interpolation, nesting, formatting,... will be as in the raw format

from i18next-icu.

Clear. It just wasn't clear to me that switching format you then loose all i18n features I was looking for 😅 I have static resources and a language is also already given (set in user profile), so really the only relevant thing was the interpolation & formatting. (Coming from a place where we did dictionary lookups and { } splitting & XSS-protection ourselves).

from i18next-icu.

then why not just use https://formatjs.io/docs/intl-messageformat/

from i18next-icu.