404.html redirects to a different language

[mgriff88]

Some background: Our docs site is available in English and Japanese. Our URL pattern looks like this:
English: https://www.example.com/about/
Japanese: https://www.example.com/ja/about/
So, the English site does not use /en/ in the URL itself, as it is the default language.

For some reason, when accessing any broken link, the 404 page changes the entire site's language preference over to Japanese. See the attachment: it changes the Title, HTML Lang, etc.
Then, if you click Home or whatever from there, it brings you to the Japanese home. Even if you were reading the site in English from the start. This forces you to reset your language back to English. Same issue happens when using a custom override of the 404.html template.

Any idea why this might be happening and how to prevent it? Or better yet, any idea how to have separate English and Japanese 404 pages? Since it's not a Markdown file and it's just coming from 404.html, I'm not seeing how to do that.

Here is some of the relevant setup in my mkdocs.yml in case it helps:

theme:
  name: material
  custom_dir: overrides
...
  language: en
...
plugins:
  - i18n:
      docs_structure: folder
      languages:
        - locale: en
          default: true
          name: English
          build: true
        - locale: ja
          name: Japanese
          build: true
          site_name: "ドキュメント"
...
extra:
  alternate:
    - name: English
      link: / 
      lang: en
    - name: 日本語
      link: /ja/
      lang: ja

[kamilkrzyskow]

Thanks for reporting, upstream issue tracked here:

• [Bug?] 404 page not generated for selected language ultrabug/mkdocs-static-i18n#284

MkDocs generates static HTML files, so there is only one 404.html in the final build.
The hosting server like GitHub Pages, decides on the loaded file in case of the 404 status code, and it loads the /404.html
Like I mentioned in my comment upstream, custom logic JavaScript would need to be added to the 404.html to fix up the page after it has been loaded client-side.

Locking further discussion here.

EDIT:
To add another point, the i18n plugin tries to orchestrate the MkDocs build process and redo the event loop for every plugin.
This doesn't work well in all cases, and for example doesn't work well with the blog plugin, which has another tracked issue here:

• Incompatibility with Mkdocs Material Blog plugin? ultrabug/mkdocs-static-i18n#283

Therefore, if you need full compatibility with the mkdocs-material theme, it would be for the best to maintain separate MkDocs builds for each language.

• Setting up multi-language installations #2346
• There is also the projects plugin available for Insiders, which also does separate MkDocs builds and could allow for easier multi-language setup.