Page 404.html is not built when using internationalization

[luciano-schirmer]

Astro Info

Astro                    v4.8.2
Node                     v22.0.0
System                   macOS (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

build

Describe the Bug

Custom 404.html page is not built to dist folder when using internationalization.

This is my astro.config.mjs:

import { defineConfig } from 'astro/config';

// https://astro.build/config
export default defineConfig({
  i18n: {
    defaultLocale: "en",
    locales: ["en", "es", "pt-br"],
    routing: {
      prefixDefaultLocale: true,
      redirectToDefaultLocale: true,
    },
  },
});

And this is the relevant file structure:

Steps to reproduce the error:

npm run build

The 404.html is not produced in the dist folder.

What's the expected result?

404.html file should be present in dist folder.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-plpmkk?file=astro.config.mjs

Participation

• [ ] I am willing to submit a pull request for this issue.

[devacame]

I have the same problem but it's not just the 404 page but any top level pages in page/ however, in the build log, it does say that the 404.html page was generated

[luciano-schirmer]

My workaround:

Create a postbuild.js file in the root of the project (along with package.json) with the following content:

// postbuild.js
const fs = require("fs").promises;

async function moveFiles() {
  try {
    await fs.rename("dist/en/404/index.html", "dist/404.html");
    console.log("Files moved successfully!");
  } catch (err) {
    console.error("Error moving files:", err);
  }
  try {
    await fs.rmdir("dist/en/404");
    console.log("Directory removed successfully!");
  } catch (err) {
    console.error("Error removing directory:", err);
  }
}

moveFiles();

Then add the following line to package.json under scripts section:

  "scripts": {
    "postbuild": "node postbuild.js",
  }

Works for me.

[devacame]

My workaround:

Create a postbuild.js file in the root of the project (along with package.json) with the following content:

actually my files are like below

so I don't think that approach would work for me (I can't delete the dist folder :( ) and the dist folder doesn't have the 404.html although the build message clearly says it built it

[luciano-schirmer]

Looks to me that it actually works. You can try to put the 404.astro inside the [lang] folder, then use the postbuild.js script to move the built 404/index.html to the root of the dist folder. Pretty like I did, but I preferred to use separate language folders instead of [lang] because I think it results in simpler getStaticPaths() functions (but this is just my personal choice).

Removing the 404 folder from the dist/[lang] folder is optional. Note: I don't remove the complete dist folder! ;-)

Though, this is a workaround. As the issue was labeled as important, we should probably wait for a fix soon. Astro is a very active project with frequent releases. Cudos for the Astro Team 🎉.

[devacame]

I found an additional workaround that might be useful to some people. The main problem seems to be the prefixDefaultLocale in the astro config file. By setting it to false, the site runs and builds as expected. This doesn't concern me because I don't use any relativeUrl provided by astro but may cause problems for you.

[luciano-schirmer]

Nice that it works for you! For me it doesn't work because I want to prefix all locales, including the default "en" locale.

[devacame]

@luciano-schirmer i prefix both en and ko (which is all of them) and it works fine

[devacame]

@ematipico I don't think the problem is fixed. Not only does my project have the same issue when prefixDefaultLocale is set to true but the reproduction example by @luciano-schirmer still has the problem as well

[luciano-schirmer]

I inform that the problem was not fixed to me neither. I tried today and the problem persists. Had to rollback to my workaround using a postbuild script.