Next-intl path based routing fails for homepage when addition locales (supported) are selected

[UXmedic]

Localization issues on fresh storefront.

Steps to reproduce

1. create Bigcommerce store
2. create a Catalyst storefront with a couple of the additional optional languages enabled
3. within "Complete setup" step, under "Start development" accordion view, copy paste the code to terminal
4. cd into the repo and start the dev server, browse to localhost:3000
5. change the language from the dropdown selection on the header

Issue details

1. [ Server ] Failed to get page pathname slices {}
   lib/makeswift/client.ts (26:10) @ async getComponentSnapshot

Most of the site content succesfuly changes language for text sourced from the .json file locales in the repo.

However I believe some components like the header obtain their state from the BigCommerce servers and they flash errors with issue notifications after failing to do so when the locale changes.

The screenshot of the error is below. It is sourced from the "client.getComponentSnaphsot" function.

export const getComponentSnapshot = async (snapshotId: string) => {
  const locale = await getLocale();

  return await client.getComponentSnapshot(snapshotId, {
    siteVersion: await getSiteVersion(),
    locale: normalizeLocale(locale),
  });
};

I say some components because I cannot be sure if it's restricted to the header and footer.

getCompoundSnapshot is referenced in
/core/lib/makeswift/component.tsx
/core/lib/makeswift/components/site-header/site-header.tsx
/core/lib/makeswift/components/site-footer/site-footer.tsx

The error details below are logged in the console twice, I assume that's the header and the footer since the text remains in default language.

Server  Failed to get page pathname slices 
Object { statusCode: 404, message: "No site locale with siteId: e4a4eee3-xxxx-xxxx-xxxx-5c014e264551, and locale: fr" }
intercept-console-error.ts:40:25
    error intercept-console-error.ts:40
    async getComponentSnapshot client.ts:26
    async SiteHeader site-header.tsx:21
    frame react-server-dom-webpack-client.browser.development.js:2892
    resolveConsoleEntry react-server-dom-webpack-client.browser.development.js:2153
    processFullStringRow react-server-dom-webpack-client.browser.development.js:2460
    processFullBinaryRow react-server-dom-webpack-client.browser.development.js:2421
    progress react-server-dom-webpack-client.browser.development.js:2668
    (Async: promise callback)
    progress react-server-dom-webpack-client.browser.development.js:2688
    (Async: promise callback)

The mentioned locales are actually present. They were selected upon store creation, and are visible and "active" in the "Localizations" tab within BigCommerce web UI > Channel Manager > Storefront details.

• The same error flashes twice if you navigate from the default locale to any other
• The error doesn't flash if you from you navigate from the default locale again to the default locale
• The error flashes 4 additional times if you navigate from an different locale to the default locale

I believe the last one is related to the next issue.

2. I am familiar with the 'next-intl' package's handling the path based routes locales. When I set it up I also opt to omit the default locale being always visible on the URL, so for english often the root URL is '/' and for others its '/es' , '/fr' etc.

However I think this caused an issue in the homepage for the Catalyst demo store.

Once we navigate to the storefront, we are greeted with the plant-themed homepage with the carousel "fresh finds", and the path url doesn't have a trailing locale.

Click any other locale which is not the default from the dropdown menu on the header, and say now we are redirected to '/de' for german. Wir konnten diese Seite nicht finden, we see the translated not-found template.

I believe this could be an issue related to file based Next.js routing, folders underneath the 'app' subdirectory.

3. Other peculiarities about the issue

There are some details to the site behavior that I hope might help understand what's happening better.

Once we've arrived from the default locale to a non-default locale and flashed the error issues, the next language change behaves slightly different.

Now, if we switch from a non-default to another non-default the site translates succesfully (except the previously mentioned components like header and footer) i.e. after arriving at french from english (default) and then navigating to german from french, things work.

However, if we select back the default language from any other locale, again there is a slight reload but now the URL is 'localhost:3000/en' while both the language selection dropdown and the page displayed remains in the previous selection, german.

While in this state, if we repeat the same step, go ahead and pick english from the dropdown selection again, in the second attempt it successfully navigates to the default locale, and the home page with the carousel is displayed again.

I encountered multiple such issues not only on my local developments, but also while using the BigCommerce web platform to change store settings. Particularly the most recent one was while setting up currencies. When I wanted to add british pound and us dollar currencies, in my first few attempts the page flashed some error notices telling me to try again later, and the currencies weren't added. Each time I reloaded the page and repeated from scratch to the same result. Then mistakenly I clicked the submit button again after receiving the error and it worked. Some updates or button clicks register on the second attempt.

[UXmedic]

Moreover, if we change language while on a subpath, the URL isn't preserved.

Say we change to Spanish while we're on 'http://localhost:3000/fr/accessories', the url becomes 'http://localhost:3000/es', and as the i18n routing is not working it results in the not-found template.