Non-existent i18n routes cause the entire domain to be erased when going back to base locale

[Josh-Cena]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I'm using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

If a route is created for the base locale but not for i18n ones, e.g. like the bug in #5553—well, not exactly a bug, just an inconsiderate move by the plugin author, going from the non-existent i18n route back to the base locale results in the full domain from being erased.

This is related to how we test what's a "fully qualified" domain:

docusaurus/packages/docusaurus-theme-common/src/utils/useAlternatePageUtils.ts

Lines 43 to 55 in 1e1df74

	function createUrl({
	locale,
	fullyQualified,
	}: {
	locale: string;
	// For hreflang SEO headers, we need it to be fully qualified (full protocol/domain/path...)
	// For locale dropdown, using a path is good enough
	fullyQualified: boolean;
	}) {
	return `${fullyQualified ? url : ''}${getLocalizedBaseUrl(
	locale,
	)}${pathnameSuffix}`;
	}

Steps to reproduce

1. Create a plugin, and add a route to only the base locale.

    async contentLoaded({actions}) {
      actions.addRoute({
        path: '/feature-requests',
        exact: false,
        component: '@site/src/featureRequests/FeatureRequestsPage',
      });
    },

2. Go to http://docusaurus.io/zh-CN/feature-requests, and see the 404.
3. Go back to the base locale through the locale dropdown.

Expected behavior

I'm taken to http://docusaurus.io/feature-requests, regardless if this page exists or not.

Actual behavior

I'm taken to http://feature-requests, an absolutely absurd URL to be in.

Your environment

• Public source code:
• Public site URL:
• Docusaurus version used:
• Environment name and version (e.g. Chrome 89, Node.js 16.4):
• Operating system and version (e.g. Ubuntu 20.04.2 LTS):

Reproducible demo

No response

Self-service

• I'd be willing to fix this bug myself.

[Josh-Cena]

This issue is hard to inspect because only one locale can be started in dev. Would be gladly accepting any community contribution.

[Josh-Cena]

Found the cause. It's because if the plugin doesn't prepend base URL when creating the route, the route is created without the locale, so on client-side, useLocation() returns the path without the locale (/feature-requests). However, when creating alternate URLs, the theme assumes that every page would have a localized base URL (which makes sense!) so it would not be able to replace the leading / because it's looking for /zh-Hans/, and naively directly prepends / (the default locale base URL), thus creating a link like //feature-requests, and that would mean a link with no host name.

Closing this as wontfix because it's quite niche and hard to fix. Plugin authors should just fix this mistake instead.

[zs7779]

Leaving a comment in case anybody is lucky enough to run into the same issue with i18n, while your locale name has upper case letters: (I tested in versions v3.5.2, v3.6.1, v3.6.3).
My case is that I put down locales: ["en", "zh-Hans", ...]. Things work fine except when on smaller screen the locale drop down moves into the side bar. The above described issue appears, but the URL exists. What happened is that you actually navigated to /zh-hans/ instead of /zh-Hans/ and somehow somewhere the i18n code believes to be a non-existing page (i.e. the issue above) The work around is to use all lowercase letters ["en", "zh-hans", ...].