Multiple pull requests / potential co-maintainership

[kkuegler]

Hi,

I worked on a couple changes to this fork of vue-i18next. I like the reduced approach you are taking with the library. However some features of the original vue-i18next version were quite helpful and I'd like to re-introduce them. That's mostly support for re-rendering when the translations/languages change and supporting some of the 'i18nOptions' options API the original vue-i18next had.

After some tinkering I ended up with a working fork of vue-i18next that has these features.
The code for the Vue 2 version of this lives at https://github.com/kkuegler/vue-i18next/tree/add-i18n-options-support.
I also made a Vue 3 version with the same feature set at https://github.com/kkuegler/vue-i18next/tree/vue-3.

I'd like to contribute the code to this repo instead of having yet another fork. I'm happy to polish the changes up and make them into smaller, more 'digestible'' PRs. Would you be interested in that?

While working on the changes I also thought, that having a couple people maintain this library would make each maintainer's job easier and keep this little i18next wrapper thriving. I use and like vue-i18n quite a bit and would be happy to join as a co-maintainer, if you like this idea. If not, that's also totally fine with me :)

Kind regards,
Konrad

[kkuegler]

@friedow Did you happen to have chance to think about this?

We could also move this project under the i18next umbrella as suggested in #5 (comment), so the project could be more independent of individual maintainers.

[adrai]

+1 for @kkuegler's idea 👍
@dlw93 @friedow what's your opinion on this?
As soon as you decide I can create an empty repository under i18next/vue-i18next and invite all who needs to have admin permissions...

[adrai]

@kkuegler would be nice if async backends like i18next-http-backend would be supported: https://github.com/i18next/i18next-http-backend/blob/master/example/vue/src/i18n.js#L15

This approach here seems to work good: https://github.com/i18next/i18next-http-backend/blob/master/example/vue/src/vue-i18next.js

[kkuegler]

@kkuegler would be nice if async backends like i18next-http-backend would be supported: https://github.com/i18next/i18next-http-backend/blob/master/example/vue/src/i18n.js#L15

This approach here seems to work good: https://github.com/i18next/i18next-http-backend/blob/master/example/vue/src/vue-i18next.js

@adrai Fully agree, support for async backends and language switching is a good feature for vue-i18next to have.

The draft code at https://github.com/kkuegler/vue-i18next/blob/add-i18n-options-support/index.ts#L38-L53 also takes care of this, albeit a little less obvious than the $forceUpdate() approach. By using an observable (or ref() in Vue 3) one can archieve the same effect of Vue automatically re-rendering all components that used translations when i18next fires one of the relevant events.

[adrai]

@dlw93 @friedow seems you're very busy... should @kkuegler start with a new repo and as soon as you've time to contribute, you let him know?

[friedow]

Hey guys, sorry for the delayed answer :)! For sure, lets move this into a new organization! Instead of creating a new repository I suggest that I move this one into the new organization.

[adrai]

Whatever you like better...
We can:

• move this repo to i18next/vue-i18next
• move kkuegler/vue-i18next to i18next/vue-i18next
• create a new repo for i18next/vue-i18next

Let me know what you prefer...

[adrai]

ohh, just saw, you created a new organisation "vue-i18next"... do you think it is better to keep it there or to move it to the i18next org?

[adrai]

@kkuegler what are your thoughts?

[adrai]

I'm not a Vue developer, but honestly I think creating a new repo for vue V3 compatibility is probably a good chance to make a clean cut... but this is just my personal opinion... you (@dlw93 @friedow @kkuegler) have to decide.

[friedow]

Now I see what you were thinkin ;). I would love to migrate this to the @i18next organization. Do you have any contact to them?

On the "starting a new reposiotry" side, I would prefer to preserve the git history and therefore stick with any of the existing repositories.

[adrai]

I'm one of the core maintainer of i18next 😉

[adrai]

btw: the history could still be preserved, by creating a new repo and pushing there... this way the "forked from" would disappear:

[friedow]

Oh nice :D
I agree, migrating into a new repository and preserving the history would be best. Would you be so kind to do that and invite me and @kkuegler into the i18next organization?