Next-i18next: setting defaultLanguage to something other than 'en' breaks page after Update to 0.23.0

[johnrackles]

Hi, after updating to Version 0.23.0 I had to disable serverLanguageDetection. If it is enabled, you get the following error when visiting the page:

TypeError: this.language.toLowerCase is not a function at I18n.loadResources (xxx/node_modules/i18next/dist/commonjs/i18next.js:209:42)

[isaachinman]

Hi @johnrackles, serverLanguageDetection is enabled by default in the config and is working just fine (our e2e tests would have caught any critical failures).

I just pulled up the simple example and switched serverLanguageDetection to false, and it also appears to be working just fine.

Please provide a reproducible example if possible. Thanks!

[johnrackles]

Firtst of all, you are right, it's not the server language detection. I was able to reproduce the Issue by setting the "defaultLanguage" to 'de' instead of 'en'.

Note, that all works when developing, but when I run npm run build, start the server and try to visit the website, I get the error above.

server/server.js

const nextI18NextMiddleware = require('next-i18next/middleware');
...
const nextI18next = require('../i18n');
server.use(nextI18NextMiddleware(nextI18next));
...

i18n.js

const NextI18Next = require('next-i18next');

module.exports = new NextI18Next({
  defaultLanguage: 'de',
});

pages/_app.js

import { appWithTranslation } from '../i18n';
...
export default appWithTranslation(App);

That should be the relevant parts, right?

[isaachinman]

@capellini This is a critical breaking error that arose between v0.22.0 and v0.23.0 - the new middleware approach.

You said you'd like to fix bugs rather than revert, so I'll leave this open for about 24 hours. Otherwise we'll need to revert as this appears to be affecting all non-English deployments.

We'll also need either unit or e2e tests to cover at least one non-English language after this.

[isaachinman]

@johnrackles Thank you for raising this issue, and please bear with us. In the meantime, you should be able to pin to v0.22.0 and get things working. I apologise for the inconvenience.

[johnrackles]

No worries, thank you for your work on this. Let me know if I can help with anything

[capellini]

@isaachinman @johnrackles apologies for the inconvenience...I'm on it and will get back to you both soon.

[capellini]

@isaachinman The first problem I see is setting fallbackLng in a production environment. If the user sets defaultLanguage to something other than 'en' and does not specify 'en' in otherLanguages, the fallbackLng is still set to 'en'.

@johnrackles Thank you for your patience as I work through this. Would you mind temporarily installing this branch to see if it fixes your problem?

# or 'yarn add'
npm i git://github.com/capellini/next-i18next.git#fix-non-en-default-lang-bug

[isaachinman]

@capellini That makes sense. Does #139 fix this issue?

[capellini]

@isaachinman I can say that #139 fixes the issue for me with the simple example. But I probably would feel more comfortable saying that it fixes this issue in its entirety once @johnrackles confirms that it now works in his code. There may be some edge case that I'm missing because the simple example is, by design, simple (I'm still working on figuring out more comprehensive e2e tests).

We may also want to put in a check and warn or throw an error if !allLanguages.includes(fallbackLng) while we are creating our config. For some reason, when you include a fallbackLng that is not a supported language (for example, { defaultLanguage: 'de', otherLanguages: [], fallbankLng: 'en' }), i18n.language suddenly becomes and array (in this case ['en']) which causes the original error that this issue that started this in the first place. I haven't had the time yet to really trace through the code to determine if that's our bug, or if it's react-i18next, i18next, etc.

But since (after we merge #139) when we run into this, it will be an issue with the user-defined configuration, it's probably best to throw and error as soon as we recognize it and just stop all-together until the user fixes the custom configuration, right?

[isaachinman]

So to clarify - this an edge case in that it only occurs when you do not provide config.otherLanguages.

@johnrackles You can fix this issue by simply providing the _required_ config option called otherLanguages.

It's not so much an "edge" case as the package is not functional without this option in the first place.

@capellini Would be great if you can confirm those findings, but if true, the priority on this issue drops to "very low".

[capellini]

So to clarify - this an edge case in that it only occurs when you do not provide config.otherLanguages.

@isaachinman Sorry for the confusion. No, #139 deals with an existing bug that config.fallbackLng is improperly set to 'en', even if the user does not have that as a valid language. This is currently set in our default config here.

[isaachinman]

Okay, then #139 will be evaluated and handled separately. As far as this issue is concerned, I've shuffled the error flow around a bit with cf30e9d. That's all that is necessary here.

@johnrackles Let me know if you have any questions - this appears to be a case of user error. If you have any suggestions for improving the documentation please just let me know.

[capellini]

@isaachinman Again, sorry for the confusion, but I believe that what @johnrackles is experiencing is due to what #139 will fix. I just didn't know, once we merged #139, if another bug would surface. I don't think that @johnrackles is doing anything wrong, so it's not a case of user error.

[isaachinman]

I don't think that @johnrackles is doing anything wrong

They are not setting otherLanguages. If you set otherLanguages = ['en'], for example, the "bug" disappears.

Please correct me if I'm wrong on that.

[johnrackles]

Sorry for the confusion, let me clarify:

The i18n.js that throws the error:

const NextI18Next = require('next-i18next');

module.exports = new NextI18Next({
  defaultLanguage: 'de',
  otherLanguages: ['it', 'hu', 'cz',],
  serverLanguageDetection: true,
});

What works:

const NextI18Next = require('next-i18next');

module.exports = new NextI18Next({
  defaultLanguage: 'en',
  otherLanguages: ['it', 'hu', 'cz', 'de'],
  serverLanguageDetection: true,
});

But the page is not supposed to use the english language. So I can make it work, but I still think it's a bug that defaultLanguage can only be 'en'.
I removed the otherLanguages key from my first example, that was a mistake. Sorry for that

[isaachinman]

I'm aware that i18n.js is throwing the error.

I removed the otherLanguages key from my first example, that was a mistake.

This is why we ask for full reproducible examples. That wasted a bit of time. In the future please provide full examples if you are able to.

I've just released v0.23.2 with #139 in there. Please test on that and let us know if your issues are resolved.

[johnrackles]

Yes, #139 does fix the issue! Thank you very much. Again, sorry for the confusion. But to be fair, the error happened all the same, wether I was setting otherLanguages or not, so I tried to provide the most minimal example.

I think the docs should mention that otherLanguages is a required field, I will make a PR for that when I geht the chance tomorrow.

Thanks again for the quick fix!

[isaachinman]

7be2b97

[capellini]

If you set otherLanguages = ['en'], for example, the "bug" disappears.

The reason why this specific case works is that you are setting otherLanguages to ['en']. If you set it to any other language (e.g. otherLanguages = ['zh']), the bug will resurface, because (in production) by default, our fallbackLng is set to 'en', regardless of whether or not 'en' is a valid language.

[isaachinman]

Ah okay, got it. Regardless, this should be fixed by #139. If it's not, let me know and we can reopen.