feat: build next version on top of `i18next`

tafelnl commented 1 year ago

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:

and probably some more

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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?

intlify / vue-i18n