i18n error when adding new languages

[samuelcastro]

There is an issue when adding new languages that I believe is related to react suspense. See i18next/react-i18next#977

Error:

Steps to reproduce:

1. Add a new language to Locize.
2. Make sure the new language is included in the supportedLanguages array. (i18nConfig.js)
3. Try to open the new added language
4. See console errors.

Are you able to reproduce it as well?

[Vadorequest]

How many languages do you use? I use "fr, en" and never ran into this so far. Haven't tried to reproduce it yet.

[samuelcastro]

@Vadorequest 20 languages, this started happening recently, it was not happening before.

[Vadorequest]

Suspense was disabled on the NRN Locize implementation, I don't think it's related.

Seems to be related to a misconfiguration of your Locize project somehow.

[samuelcastro]

Ok the problem is because I changed how locize fetch languages from:

const i18nTranslations: I18nextResources = await fetchTranslations(lang); // ie: fr

to:

const i18nTranslations: I18nextResources = await fetchTranslations(locale); // ie: fr-FR

The reason is because I need to fetch translations and their variations like: es-CO and es-ES, etc.

[Vadorequest]

Did you find a solution?

I didn't play around with i18n variations with Locize, I haven't much experience with those.
But, I'd say at first glance your design won't work, because your Locize account is configured with "en" language, instead of "en-CO"/etc. You might resolve your issue by creating two new languages on Locize, using "es-CO" and "es-ES". (and a "common" namespace within each)

But I'm advising against that design, because I believe Locize provide a much better way of dealing with language variations (which handles native fallback values), but I don't remember how. You should check their doc. 😄

[samuelcastro]

I already have es-CO and es-ES on locize, I don't have en-CO because this isn't even a valid locale.

It's not about design, it's about the languages I need to support.

I thought it would work without any problem considering that it's just a different language.

I will check the docs, thanks!

[Vadorequest]

Then the error message seems to point out those languages don't have a common namespace on Locize.

[Vadorequest]

Seems like I was wrong about two things:

• It's not about Locize, but about how i18next works
• You can use en-US as a valid language on i18next (and thus on Locize too)

You might want to check how the fallback works: https://www.i18next.com/principles/fallback

[samuelcastro]

Then the error message seems to point out those languages don't have a common namespace on Locize.

Which is weird because they're already have the common namespace:

[samuelcastro]

It's not about Locize, but about how i18next works

What do you mean? As far as I know i18next support variation as any other language.

[samuelcastro]

I can see that the translations are being fetched and returned properly from Locize, so in fact it's not a problem with Locize.

[samuelcastro]

I think the problem is a misconfig using lang rather than locale, but I didn't find it, if you could try to reproduce it including a language variation to see the results that would be great, at least I'll know whether or not it's something on my end.

And all others locales work just fine, just variations like (es-ES, es-CO, fr-FR) generates the problem.

[samuelcastro]

Any feedback here @Vadorequest ?

[Vadorequest]

What do you mean? As far as I know i18next support variation as any other language.

Yeah, yeah, I meant I was wrong about But, I'd say at first glance your design won't work, because your Locize account is configured with "en" language, instead of "en-CO"/etc., it seems to be properly configured.

I don't have the time to debug this at the moment, buried under many other things.

[samuelcastro]

Ok, could you label this issue as a bug to be fixed? I don't have time right now but if find any I can take a look. I think this is critical considering that language variations is very common.

[Vadorequest]

@samuelcastro I've found the root cause of this issue. It's simply because the lang is provided to Locize, instead of the locale.

const i18nTranslations: I18nextResources = await fetchTranslations(lang); - See

next-right-now/src/utils/nextjs/SSG.ts

Line 137 in 30d83e9

const i18nTranslations: I18nextResources = await fetchTranslations(lang); // Pre-fetches translations from Locize API

I guess my first implementation didn't consider providing a locale (e.g: fr-CA) but only a lang instead (e.g: fr).

I found out this by reviewing the documentation, I wasn't specifically working on this issue.
I believe providing the locale instead of the lang, from the SSG/SSR.ts file would solve your issue. Could you try and confirm?

I'll need to review this, and make sure it doesn't create non-backward compatible change. (it shouldn't)

[Vadorequest]

Maybe providing a locale instead of a lang wouldn't automatically fallback from the locale to the lang.

Meaning, if a translation isn't defined in fr-CA, then it might not automatically fallback to the translation defined in the fr Locize namespace. That might be why I hadn't implemented this at first, for the sake of simplicity.

If that's the case, then we should either:

• Find if an automated fallback is possible through the API
• Implement a fallback, by fetching both the variation endpoint (fr-CA) and language endpoint (fr) and merging them in proper order.

[samuelcastro]

Yeah I knew this was the issue, I just didn't have time to find where it was being misused, see: #200 (comment)

Glad you found it. :)

Could you try and confirm?

I'll try that today.

If that's the case, then we should either:

Find if an automated fallback is possible through the API
Implement a fallback, by fetching both the variation endpoint (fr-CA) and language endpoint (fr) and merging them in proper order.

It sounds like a reasonable approach.

[samuelcastro]

Actually it seems I tested this already see: #200 (comment)

[Vadorequest]

Alright, then I guess it didn't work because Locize wasn't called twice, but only once (with the variant) instead of variant + base. But that doesn't actually sound related to the original issue.

No more idea then, I'll have to take a look myself and see what's wrong. I think I'll implement a proper fallback for the language when doing that.