Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom 404 page - Cannot read properties of undefined (reading 'translations') #36

Closed
BuckyBuck135 opened this issue Sep 14, 2024 · 8 comments
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@BuckyBuck135
Copy link
Contributor

Hi Florian,
Hope you're well.
I have a project using your package: https://github.com/CodeStitchOfficial/Advanced-Astro-v4-i18n

1. The problem
While on dev mode, navigating to any page throws this error:

image

The line at 404 (eval at instantiateModule (file:///C:/Users/user/Documents/-=%20Web%20dev%20=-/CODE/-=%20Templates%20=-/Advanced-Astro-v4-i18n/node_modules/vite/dist/node/chunks/dep-BzOvws4Y.js:52861:24), <anonymous>:19:12) made me look into the custom 404 page.

Deleting this page gets rid of the error. Good, but I want a translated 404 page lol. Also note that this error does not happen on the deployed site, where the 404 pages work perfectly.

2. My setup
Following the docs, I've set up two 404 pages as I want fully static, under src/pages/404.astro and src/pages/fr/404.astro. I've also configured the rewrites for Netlify.

//404.astro

---
import BaseLayout from "@layouts/BaseLayout.astro";
import { getLocalePath, t } from "i18n:astro";

const title = t("notFound.pageNotFound");
---

<BaseLayout title={title} description={title}>
    <h1>{title}</h1>
    <a href={getLocalePath("/")}>{t("notFound.linkText")}</a>
</BaseLayout>

I tried to narrow it down by deleting all references to t() or getLocalePath(), but I still get an error, with a different problem (reading 'data')
image

(The repo currently shows one 404 page located in routes/, and I've tried the above setup in a branch)


Here's my Astro config:

```js
// astro.config.mjs
export default defineConfig({
  integrations: [
    i18n({
      defaultLocale: "en",
      locales: ["fr", "en"],
      client: {
        data: true,
      },
    })
  ]
});

I've tried setting all client keys to true (data, paths and translations), to no avail (I don't really understand what they do to be honest)

One thing I haven't tried is using SSR in hybrid mode.

While this error does not seem to impede the deployed site, it's a hassle to deal with in development. Do you have any idea where it comes from?

thank you for your time.

@BuckyBuck135
Copy link
Contributor Author

BuckyBuck135 commented Sep 16, 2024

After some more trying to figure it out, I've narrowed it down to the error originating somewhere from the BaseLayout.astro in the custom 404 pages.
Then, down to the use of getLocale to pass to the lang attribute in html

---
// import some other stuff
import { getLocale} from "i18n:astro";

const locale = getLocale();
---
<html lang={locale}>
 // markup
 </html>

It looks like getLocale() can't be accessed. I've started using Astro.currentLocale, which now gets rid of all errors when navigating! The original issue is now solved, in a way.

However, the 404 pages do not work as expected anymore:

  • in dev mode: they return an error Cannot read properties of undefined (reading 'translations') looks familiar~ :)
  • in preview mode: redirect does not seem to be working anymore: 404 defaults to EN, which is the default locale.

@florian-lefebvre
Copy link
Member

Thanks for opening an issue! Tbh I don't have time to debug this nor fix it, so feel free to use workarounds and/or submit a fix if you find one

@BuckyBuck135
Copy link
Contributor Author

Hi Florian,
Thanks for your candor. If you don't mind, I'll keep this issue open as i continue the investigation, and maybe someone might be able to chime in.
Good luck with what you're working on!

@florian-lefebvre
Copy link
Member

Sure let's keep it open! I'll label it correctly now

@florian-lefebvre florian-lefebvre added bug Something isn't working help wanted Extra attention is needed labels Sep 17, 2024
@BuckyBuck135
Copy link
Contributor Author

Hi,
I've narrowed it down and created some repros.

Hi everyone,
Posting here because I know that the maintainer Florian is busy at the moment.

Now I believe that the issue boils down to: is a custom 404 route supposed to return errors in dev mode (while working fine in production)?

There's also some chatter on this Starlight thread that could be related to this issue. To summarize, middleware is intentionally not run in dev mode on Astro

In the minimal repros below, I have followed the installation steps laid out in the integration's docs.

  1. npm create astro@latest
  2. npm run astro add @astrolicious/i18n
  3. updated astro.config.mjs with the i18n config fron the doc
import { defineConfig } from "astro/config"
import i18n from "@astrolicious/i18n"

export default defineConfig({
    integrations: [
        i18n({
            defaultLocale: "en",
            locales: ["en", "fr"],
            client: {
                data: true,
                // paths: true,
                // translations
            }
        })
    ]
})
  1. Use client usage utilities in Layout.astro
    import I18nClient from "@astrolicious/i18n/components/I18nClient.astro"
    <I18nClient />
  2. Placed index.html in routes/
  3. Created common.json files in locales/
  4. Created rewrites in public/_redirects
  5. Deployed

Now, when running npm run dev, hitting a 404 route throws errors:

  • in 404.astro, if not using any of the i18n imports, returns this error:
    [ERROR] Using requires adding thei18n integration to your Astro config.
  • in 404.astro, using them returns this error:
    [ERROR] Cannot read properties of undefined (reading 'data')

Here are the repros:

Thank you for your time!

@florian-lefebvre
Copy link
Member

It should probably work after withastro/astro#12034 is merged, and a patch released!

@BuckyBuck135
Copy link
Contributor Author

Fingers crossed :)

@BuckyBuck135
Copy link
Contributor Author

The issue is now fixed on my end with an update to Astro v4.15.9.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants