Korean 'Jump to' menu shows Chinese

[picxenk]

Most appropriate sections of the p5.js website?

Other (specify if possible)

What is your operating system?

Mac OS

Web browser and version

145.0.7632.109 (Official Build) (arm64)

Actual Behavior

Although the webpage language is set to Korean, the "Jump to" menu on all pages is displayed in Chinese characters.

Expected Behavior

If the language is set to Korean, the text in the "Jump to" menu should also be displayed in Korean.

Steps to reproduce

No response

Would you like to work on the issue?

No

[lirenjie95]

It also happens when using Spanish (the jump to menu shows some Hindi links). The “Jump to” menu is driven by a module-level global (jumpToState) that is mutated during page rendering, which is unsafe under Astro’s concurrent SSR/static generation. When multiple locales build in parallel, one page can overwrite jumpToState while another page’s Nav reads it, causing cross-locale leakage (e.g., Korean pages showing Chinese labels). This is why it doesn’t reliably fall back to English—it's not a translation fallback, but a race condition from shared mutable state.

[ksen0]

@lirenjie95 Thanks for the analysis! I've marked it as open for work (unless you want to claim it?)

[lirenjie95]

@ksen0 please keep it open to everyone. I haven't figured out the solution yet.

[abhi-2028]

@ksen0 Hey,

I cloned the repository and tested the issue locally. On the deployed website, the “Jump to” menu shows Hindi/Chinese text even when the language is set to Spanish or Korean .

However, when I run the project locally after cloning the repo, the “Jump to” menu appears correctly in the selected language, and I cannot reproduce the cross-locale text issue.

Because of this difference between the production site and the local environment, I’m wondering:

Could this be related to Astro’s concurrent static generation during the production build rather than the dev environment?

Is there a specific build command or environment configuration used for the official site that might trigger the race condition mentioned earlier (jumpToState global mutation)?

Is there a recommended way to reproduce the production build locally so contributors can properly debug the issue?

Happy to investigate further once I can reproduce the problem reliably. Thanks!

[star11293]

Hey took a look at this. The problem is that ko.yaml was missing most of its referenceCategories entries so only 6 out of 17 modules were translated. Opened a fix in #1267.

[lirenjie95]

Hi @star11293, if the problem is that most entries are missing in ko.yaml, those entries should fallback to default (English). However, it shows Chinese. Thank you for looking into this issue but I’m afraid that your PR doesn’t resolve it.

[riya-saharan]

Hi @ksen0, I'd like to take a stab at this!

After reading through the thread, I agree with @lirenjie95's analysis — the root cause appears to be the shared mutable jumpToState module-level global being overwritten during Astro's concurrent static generation, causing cross-locale label leakage (e.g. Korean pages picking up Chinese labels).

My plan:

1. Reproduce the race condition locally by running a production build (astro build) with multiple locales in parallel.
2. Refactor jumpToState to be request/page-scoped rather than a module-level singleton — for example, passing locale context through as a parameter or using Astro's locals instead of shared state.
3. Add a test or build-time assertion to catch cross-locale leakage before it reaches production.

Happy to open a PR once I've confirmed the fix holds across all affected locales. Could you assign this to me? Thanks!

[star11293]

@riya-saharan That makes sense, thanks for the deeper analysis. I was focused on the missing entries side but the jumpToState race condition during parallel builds explains why it shows Chinese specifically instead of just falling back to English. My PR at least fills in the gaps in ko.yaml but yeah the core bug needs the fix you're describing. Good luck with it

[riya-saharan]

Hi @[ModeratorName], I've just submitted a PR (#1271 ) that refactors the jumpToState management to use Astro.locals. This moves the state from a global scope to a request-scoped architecture, effectively resolving the race condition where translations were leaking between different locale builds. The build is now thread-safe and verified. Looking forward to your feedback!