Support for message formats other than ICU about next-intl

[ilanbm]

It makes sense I guessed there is more to it in the plurals area, I've never used it...
For my usage the transformation was quick and simple.

I wonder if there are already migration scripts between them and other formats.

Thanks for the response, I'll keep an eye here also

[amannn]

There's Intl.MessageFormat on the horizon which uses the Message Format 2 syntax. It's still under heavy development, but if this makes it into the browsers that is probably a format we should support since it will decrease the library size significantly if we don't have to bundle a parser.

[amannn]

Thanks for opening this!

I have a bit of experience with i18next but from what I saw so far it is similar in things like interpolation, but differs quite a bit with more sophisticated features. E.g. for plurals and select you have to use different messages that are then embedded within the original message. With ICU there's just one message, which is a large factor why I prefer that syntax.

I'm not sure if there's support for selectordinal in i18next and rich text would require a different API at the call site (array instead of object, or alternatively indices as keys).

This library is quite integrated with the ICU functionalities at this point. To support a different syntax, forking the library might be the easier choice.

However what I think could be interesting is a migration guide from i18next to ICU / this lib, possibly with automated tools helping in the process.

I don't have any plans yet to support other localisation syntax, but I'll leave this open to see if there's more interest.

(and my motivation to not use i18next on a nextjs project was a heavy performance hit on client side, including having all languages locales sent to browser)

Glad to hear if this lib helps with this!

[jamuhl]

@ilanbm and others stumbling onto this. i18next is built to only load what is needed (separation of languages, namespaces) - running into performance issues where the clientside loads all languages and namespaces is basically a result of not using it right -> using next-i18next (or at least following how to do it right) will help: https://github.com/i18next/next-i18next

[amannn]

@jamuhl I'm sorry, I can't follow how that is related to this issue? Also please note that next-intl is not affiliated with i18next.

[jamuhl]

it's related to

(and my motivation to not use i18next on a nextjs project was a heavy performance hit on client side, including having all languages locales sent to browser)

just wanted to make clear that i18next does not have that problems mentioned (for others coming here)

[amannn]

Ah ok, I see! Good to hear! 🙌

[amannn]

I'll close this issue, since other message formats are currently not planned.