question: why maintain own version of Vue plugin and not make use of `vue-i18n` for example?

[tafelnl]

Why did you choose to maintain a separate i18n plugin for Vue, and not make use of existing solutions, like the widely used vue-i18n (over 1 million installs per week). It's hard to beat their community and features I guess. For example vue-i18n supports stuff like "Component Interpolation" out of the box.

It would still be possible to support in-context editing etc. as well. Phrase for example chooses to make a plugin/wrapper for vue-i18n like this: https://github.com/phrase/vue-i18n-phrase-in-context-editor/tree/master/examples/vue3

I'm saying this specifically for Vue, as that's what I'm using. But I guess the same thing could probably be said for React and Angular as well.

[JanCizmar]

Hey. Thanks for asking! This is exactly why Tolgee is different.

Every language and every technology has it's own solution for i18n. Every has different format and different API. Yep, you can sometimes use in-context editing with other solutions, but how many users actually do that? Not many. It's hard to setup and not reliable, since both components (phrase and vue-i18n has to work together).

Tolgee offers a convenient way how to get everything you need to do i18n in your project in minutes. You don't have to find a library and then look for platform which supports in-context editing for what you chose and then hope it will work together.

We are coming with complete solution, covering the whole process.

However, if you would like to use Tolgee with vue-i18n, you might be able to create an integration for that similarly as we did for i18next. PRs are welcomed! 🤩

[tafelnl]

Thanks for the quick elaborate answer :smile:

Every language and every technology has it's own solution for i18n. Every has different format and different API.

I get your point. But isn't maintaining a separate i18n plugin for every language/technology causing the same issues? You still need to take into account the different APIs (React vs Vue vs Angular).

Tolgee offers a convenient way how to get everything you need to do i18n in your project in minutes. You don't have to find a library and then look for platform which supports in-context editing for what you chose and then hope it will work together.

But wouldn't offering an in-context editing plugin for the major i18n libraries (e.g. react-i18n and vue-i18n) solve exactly this problem?

Also making use of available plugins makes it more platform agnostic. It also makes it easier to switch from an existing solution (e.g. a project where vue-i18n has already been implemented) to using Tolgee.

Developers also need to learn the API of your plugin vs the API they're probably more used to using. And if a feature is missing (e.g. "Component Interpolation" seems to be missing in the Tolgee Vue plugin, but I could be mistaken) what should a developer do? Create an issue with a feature request? That would also mean more developing overhead to Tolgee right?

However, if you would like to use Tolgee with vue-i18n, you might be able to create an integration for that similarly as we did for i18next. PRs are welcomed! star_struck

I'm willing to look into this. But I don't know where to get started. Could you please guide me in the right direction?

[JanCizmar]

But wouldn't offering an in-context editing plugin for the major i18n libraries (e.g. react-i18n and vue-i18n) solve exactly this problem?

No, since we cannot be sure about their implementation and API. The way Tolgee handles in-context editing (using it's invisible wrapper) is unique and cannot be implemented in all third party i18n libraries.

Also making use of available plugins makes it more platform agnostic. It also makes it easier to switch from an existing solution (e.g. a project where vue-i18n has already been implemented) to using Tolgee.

That's right. But it's a fact of life. If Vue changes their API from v2 to v3, you have to choose between updating your code or not. The same thing happens with Tolgee.

The most complex part of supporting all the libraries is that each uses different message format. Why? Because most of the libraries are developed this way:

1. someone needs it
2. someone starts implementing their own simple way, because they think localization is simple
3. users need to solve specific issues related to the format, parameter interpolation, pluralization, "component interpolation", security, etc.
4. the complexity grows
5. finally, we have thousands of implementations around the software development world.

We decided to finally do it right. We decided to create a solution which is easy to use, follows the standards (the ICU message format), is 100% reliable and has cool features like in-context editing.

what should a developer do? Create an issue with a feature request?

Exactly. Software evolves. I am not sure if we currently support "Component Interpolation" for Vue, but we support tag interpolation for React, so for Vue it might be similar. Right? @stepan662

Would you please guide me in the right direction? I would probably start with exploring the @tolgee/i18next integration and the vue-i18n plugin support, it might be possible to implement it very similar way as we did it for the i18next.

[JanCizmar]

We can also discuss it deeply in the slack community 🚀

[stepan662]

No we don't support interpolation for Vue right now. But we offer an i18next integration and with i18next and that supports it.

The i18next integration is basically what you are describing - we use existing library with injected in-context. But it's not ideal the i18next is one of the most versatile tools and still the integration is quite complicated to implement and not very user friendly.