feat: build next version on top of `i18next`

[tafelnl]

trafficstars

Clear and concise description of the problem

Building on top of the robust, long existing and battle tested i18next seems to be a more efficient and smart move than reinventing the wheel for quite some features. It would also increase compatibility with other plugins. It would also be easier to support the ICU format standard.

For example, these issues could be more easily resolved if you were to use i18next:

• https://github.com/intlify/vue-i18n-next/issues/1004
• https://github.com/intlify/vue-i18n-next/issues/958
• https://github.com/intlify/vue-i18n-next/issues/957
• https://github.com/intlify/vue-i18n-next/issues/1228
• https://github.com/intlify/vue-i18n-next/issues/1211
• https://github.com/intlify/vue-i18n-next/issues/1132
• https://github.com/intlify/vue-i18n-next/issues/93

and probably some more

Suggested solution

Build the next major version on top of i18next like the popular react-i18next has done.

For Vue some projects also exists, but they don't seem to take of quite well yet, because of their small community:

https://www.npmjs.com/package/@panter/vue-i18next https://www.npmjs.com/package/i18next-vue

Alternative

No response

Additional context

No response

Validations

• [X] Read the Contributing Guidelines
• [X] Read the Documentation
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[tafelnl]

Also if you look at the footprint (size of the code-base) of the react-i18next library, it's way, way smaller than that of vue-i18n

[tafelnl]

The i18next organization has their own implementation here: https://github.com/i18next/i18next-vue. Maybe some type of collab can be started? Why not bundle your powers to build something even more beautiful :partying_face:

[kazupon]

Hi! Thank you for your suggestion.

Yes, i18next does have many advantages over vue-i18n in many ways. Of course, I'm recognizing them. I have an idea to solve those problems and will develop the next major version of the intlify project.

Here is the roadmap. https://github.com/orgs/intlify/projects/1

In particular, the message format will support Intl.MessageFormat in the next major version, which is under discussion by the Unicode working group. https://github.com/unicode-org/message-format-wg

When Intl.MessageFormat will be supported in the future, All ECMA-402 APIs (Intl) will be supported.

In the next major version, I would like to focus especially on Experience for localization of applications, although DX will of course be a focus as well.

For this reason, I’m working on the Intlify project.

[tafelnl]

Thanks for the prompt reply!

In particular, the message format will support Intl.MessageFormat in the next major version, which is under discussion by the Unicode working group.

For reasons like this, wouldn't it make sense to build on top of the i18next platform? Because they will probably also have a plugin for this, just like they also already have one for ICU.

Right now, you're all on your own to implement stuff like that. Which is perfectly fine of course. But I think it could take a lot of work off your shoulders if you build on top of other strong shoulders. Just like react-i18n did.

Are there particular reasons you wouldn't want this? Or did I misinterpret your response.

[mrleblanc101]

Hi @kazupon, A small thing I'd love to see in the next major version, is to use js path for translation. I think it would reduce the amount of confusion. So instead of $t(`somepath.1.test`) it would be $t(`somepath[1].test`)

[tafelnl]

@mrleblanc101 I don't think it's wise to hijack this issue to do a non-related feature request. It's cluttering the issues for kazupon and it reduces the chance of it being implemented.

[unitydynamics]

i18next isn't written in Typescript--and if you use Typescript you'll find that it's not a great experience. As a side note, it also seems to have a lot more bugs--but the authors there seem to do a good job of responding to them. Resulting bundle sizes with i18next were quite bloated last time I tested it. And according to my notes there was a performance issue with translation files.

@tafelnl: why aren't you using i18next-vue?