Issues on development environment in other languages

[rengert]

Great starter, but i got the error in frontend

Uncaught Error: invariant expected app router to be mounted at useRouter"

I set up it several time using the readme and video tutorial.

At the end of the story, the issue was, that the startup used the locale "de" but nothing was available.
Maybe the error message should be adapted or ensure the starter is working on all machines.

[PaulBratslavsky]

@rengert thank you for the comment. Will look into it, and update if locale is not set to throw a more appropriate error.

[mbieberstein]

Same for me. The middleware picks the preferred language from the 'Accept-Language' header. Which is German for me. You can easily modify the code to always use 'en' or remove 'de' from the i18n settings (there needs to be a match between preferred language and available languages). Anyway, there is a check, if page data is available in the requested language and if not, a language selector component should be displayed, avoiding any errors. But this is not working as expected, still don't found out why. But keep searching.

[PaulBratslavsky]

@mbieberstein I haven't had a chance to take a look in more detail into this issue yet, if you end up finding the issue first let us know or feel free to make a PR request.🙂

[eugene-beliaev]

I have same issue when trying to open a link with newly added locale

Uncaught Error: invariant expected app router to be mounted at useRouter

[mbieberstein]

@eugene-beliaev This is a next.js error. It complains about missing HTML and BODY tags in the response.
Look at my previous comment for an explanation.

The fallback mechanism for missing page data in a certain locale will never be reached, when the global configuration (navigation, etc.) is also not available in that locale. In that case the global layout.tsx returns null, which results in an empty layout. That's what next complains about.

in line 64 in frontend\src\app[lang]\layout.tsx you find this comment: // TODO: CREATE A CUSTOM ERROR PAGE
So, this seems to be work in progress. But I suggest to redirect to the default locale instead of treating this as an error.
Missing global configuration in a certain locale indicates, that there wont be any content available either.

@PaulBratslavsky In my opinion: The available locales should not be hard coded in the i18n configuration, but retrieved from the strapi localization api (needs to be public then).

At first, the preferred locale of the user is determined by the Accept-Language header: ok. If this preference does not match the available locales, a redirect to the (strapi) default locale takes place. But this fallback locale needs to be persisted in the user session (cookie), otherwise this roundtrip will happen on each subsequent request.

There should be a possibility for the user to select the locale (dropdown in navigation, etc.) to switch preferences. This selection should then update the cookie value, which functions as the 'master' locale.

Anyway, there needs to be content available in every supported locale, at least on the global level. If certain pages are not available in that locale, the fallback component should appear. But the link to the default locale needs to be dynamic, redirecting to the requested page, not home.

I am currently working on a POC for this mechanism and, as you suggested, will make a PR as soon as it works.