coverage: 95.886% (+0.003%) from 95.883%
when pulling 6617013 on waivital:changelanguage-call-order
into 59498ae on i18next:master.

this PR will increase the package by approx. 3kb... this will undo all our efforts at v24 to reduce the bundle size... fyi: @VIKTORVAV99

maybe this is already sufficient?

@adrai Oh, you are right, this is indeed much simpler, and the test case still passed.

I think the new option is not necessary. Please remove it.
We just do it always.

But it may introducing breaking changes. If someone relies on the old behavior, their code might stop working after the upgrade.

And another concern is here

The languageChanged event no longer represents the real language changed event. To fix that, maybe here need to reject the outdated defer and pass an error to the callback.

The old behaviour is not reliable by itself... so this does not matter.

I still feel that it is a bit too hasty to change it directly, after all, this problem has existed for so long. Lots of project already adopted with i18next's old behaviour.

The old wrong behaviour occurs only if the changeLanguage is used in a wrong way. So this is a fix after all... But if you think this is breaking we will release a new major release... no problem. But I don't like to introduce a new option because of a "bug" or "wrong usage" behaviour.

But it may introducing breaking changes. If someone relies on the old behavior, their code might stop working after the upgrade.

And another concern is here

i18next/src/i18next.js

Lines 348 to 354 in 94e4e7b

	if (this.isLanguageChangingTo === lng) {
	setLngProps(l);
	this.translator.changeLanguage(l);
	this.isLanguageChangingTo = undefined;
	}
	this.emit('languageChanged', l);
	this.logger.log('languageChanged', l);

The languageChanged event no longer represents the real language changed event. To fix that, maybe here need to reject the outdated defer and pass an error to the callback.

feel free to optimize this... an alternative to a "reject" could be also an additional parameter that illustrates that a subsequent changeLanguage call has "overwritten" this one...

btw: this is even better in my opinion:

And since we can make a major release, we can just keep it like that (no reject, etc...) and document this new behaviour in the changelog and in the migration guide.

Make sense to me, I'll look into this a bit later.

I was thinking if we could optimize the changeLanguage function. It seems to involve three things: detect the language using a detector if language not provided, normalize the detected language, and load the language resources then set the related state. Maybe we can separate these steps to make the process clearer.

I created a new branch for this idea, if it looks good, I'll create a new PR for it.
https://github.com/waivital/i18next/commits/optimize-changelanguge-function/

I was thinking if we could optimize the changeLanguage function. It seems to involve three things: detect the language using a detector if language not provided, normalize the detected language, and load the language resources then set the related state. Maybe we can separate these steps to make the process clearer.

I created a new branch for this idea, if it looks good, I'll create a new PR for it. https://github.com/waivital/i18next/commits/optimize-changelanguge-function/

Not sure if I like the idea - changeLanguage does no detection with that change -> leads to a breaking version for no real benefit. Also adding detectLanguage and normalizeLng to public API seems to be unnecessary - at least for me it just adds more clutter.

I was thinking if we could optimize the changeLanguage function. It seems to involve three things: detect the language using a detector if language not provided, normalize the detected language, and load the language resources then set the related state. Maybe we can separate these steps to make the process clearer.
I created a new branch for this idea, if it looks good, I'll create a new PR for it. https://github.com/waivital/i18next/commits/optimize-changelanguge-function/

Not sure if I like the idea - changeLanguage does no detection with that change -> leads to a breaking version for no real benefit. Also adding detectLanguage and normalizeLng to public API seems to be unnecessary - at least for me it just adds more clutter.

It's ok if detectLanguage and normalizeLng are public API or private API for me, it just a quick demo for the idea. I think the benefit of this change is that changeLanguage now does just one thing—find the matched language and load the related resources. If the language isn't found, it informs the user that there’s an issue with the configuration.

I also don't like that change... For example, there are scenarios out there, where there is a lng passed via options but also a language detector...
And also that new thrown error there might be an issue "in the wild"...
So without these things, it's just splitting the content of the changeLanguage function into multiple functions... (no real benefit in userland)
So I would say we merge this PR only to fix the order of changeLanguage calls...

Sure, we can discuss more on that later. 😄

included in v25