🦋 Changeset detected

Latest commit: 16cfb89

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

✅ Deploy Preview for astro-starlight ready!

Name	Link
🔨 Latest commit	16cfb89
🔍 Latest deploy log	https://app.netlify.com/sites/astro-starlight/deploys/671feff09b927200085ba895
😎 Deploy Preview	https://deploy-preview-2444--astro-starlight.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 100 (no change from production) Accessibility: 100 (no change from production) Best Practices: 100 (no change from production) SEO: 100 (no change from production) PWA: - View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify site configuration.

Lunaria Status Overview

🌕 This pull request will trigger status changes.

Tracked Files

I noticed that the file locals.ts is getting the wrong locale, this seems to solved the issue:

	const locale = context.url.pathname.split('/')[1] || context.preferredLocale || 'en';
	context.locals.t = useTranslations(locale);

I hope it helps!

Thanks for the feedback 🙌

I noticed that the file locals.ts is getting the wrong locale

This PR refactors useTranslations() to now accepts a lang instead of a locale. In Starlight, a locale usually represents the path used in i18n, e.g. zh-cn while lang is a BCP 47 language tag, e.g. zh-CN so this may be what you're seeing, which is a change from the previous behavior?

What I meant is that the UI translation problem is still happening when I use this current pull request.

I forked this repo and used as a local package to test on my own Astro project.
The problem seems to be that the locals.ts is incorrectly getting the locale "en" in place of "pt-br" for example.

However, that did not happen when I tried directly on the "docs" in the monorepo. When you log locals.ts in the monorepo it outputs the correct locale. In my case the output was "pt-BR", which is still not in the right format, but can be fixed just lowering the case.

I made a video so you can better understand. At the bottom left is this current pull request. At the right is my own project, you can see it is not logging the wright locale:

I see, I think there are 2 points here:

The problem seems to be that the locals.ts is incorrectly getting the locale "en" in place of "pt-br" for example.

Always getting en is definitely an issue. Altho, it should be at a different level, likely when we transform the Starligh i18n config to an Astro i18n config. This part of the code should not be impacted by the changes in this PR.

I tried reproducing the issue locally but I couldn't using the following config I assumed from your video:

defaultLocale: "en",
locales: {
  en: { label: "English", lang: "en" },
  "pt-br": { label: "Português do Brasil", lang: "pt-BR" },
},

Would you be able to share your Starlight config so I can investigate further?

In my case the output was "pt-BR", which is still not in the right format, but can be fixed just lowering the case.

This is expected with the current changes as Astro.currentLocale returns what is called a lang in Starlight (or a code in Astro i18n) and not a locale as I described in this comment.

I already tried different configs too. Using Astro's native i18n or with starlight. No luck so far.
I am about to start a new project and see if I manage to reproduce the error.

My current config:

// https://astro.build/config
export default defineConfig({
  site: getSite(),
  base: BASE_PATH,
  output: "server",
  adapter: cloudflare({
    platformProxy: {
      enabled: true,
    },
  }),
  experimental: {
    serverIslands: true,
  },
  integrations: [
    sitemap(),
    react(),
    icon(),
    tailwind(),
    starlight({
      title: "ArchCompute",
      defaultLocale: "en",
      locales: {
        en: { label: "English", lang: "en" },
        "pt-br": {
          label: "Português Brasileiro",
          lang: "pt-BR",
        },
      },
      disable404Route: true,
    }),
    mdx(),
  ],
});

Oh, that just hit me, which version of Astro are you using?

I had a similar issue a few days ago that was an issue in Astro which was fixed in Astro 4.16.4. Would you be able to test using the latest Astro version?

Oh man... that was it! Thanks a lot.
Shame on me for not think about updating Astro 😅 It was at 4.15.11

Also thanks for this PR!

Amazing to hear, thanks for the follow-up and checking it out 🙌 And no problem, I had the same problem and it took me a while to figure it out, it's a bit tricky to spot an upstream i18n issue while working on another i18n issue 😅