Astro.currentLocale doesn't work correctly in SSR with fallback

[mtwilliams-code]

Astro Info

Astro                    v5.0.9
Node                     v20.11.0
System                   macOS (arm64)
Package Manager          npm
Output                   server
Adapter                  astro-sst
Integrations             @astrojs/react
                         @astrojs/tailwind

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

No response

Describe the Bug

When using i18n and fetching the current locale with Astro.currentLocale, it returns the rendered locale, rather then the one it is falling back from in SSR mode. It works correctly in Dev and SSG. That is, with a configuration like:

i18n: {
    locales: ['es', 'en'],
    defaultLocale: 'en',
    fallback: {
      es: 'en',
    },
    routing: {
    prefixDefaultLocale: false,
    fallbackType: 'rewrite',
    },
  },

if you navigate to a page that does not have a localized version for es (eg. http://localhost:4444/es/ in the repro), it will render the en default version as expected, but in SSR it renders it with Astro.currentLocale==='en', whereas in dev and SSG it renders it as Astro.currentLocale==='es'.

What's the expected result?

I expect Astro.currentLocale to have consistent behavior across SSR/SSG/Dev - namely it should return the requested locale even if it falling back to another locale.

You can reproduce with the repo linked below, which is a slightly modified version of the Astro SSR template. I have trouble with stackblitz and testing SSR/SSG/Dev differences, but if you clone the repo, npm install, and npm run dev you can see the header includes a - en. Navigate to /es or click the "Toggle Language" button, and see that the header now displays - es.
If you run npm run build && npm run preview, then run the same procedure to check the pages, you will see that the header does not show - es as expected when on the /es route.

Link to Minimal Reproducible Example

https://github.com/mtwilliams-code/astro-sir-i18n-params-repro/tree/master

Participation

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