Skip to content

fix(l10n): client-rendered strings always in en-US#1369

Merged
caugner merged 1 commit intomainfrom
fix-l10n-client-strings
Mar 12, 2026
Merged

fix(l10n): client-rendered strings always in en-US#1369
caugner merged 1 commit intomainfrom
fix-l10n-client-strings

Conversation

@LeoMcA
Copy link
Copy Markdown
Member

@LeoMcA LeoMcA commented Mar 12, 2026

Noticed in #1367.

Currently strings rendered on the client - so this is strings within custom elements which aren't SSRed - always render in en-US. This is because our entry-points race in an unexpected way, which we do need to fix, but has some drawbacks/considerations we need to make. I've got a draft PR for that I need to spend more time on tomorrow: #1368

For now, we can and should fix the worst of the issue for localised strings by not caching the miss. This PR does that.

An example of the issue can be seen on https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Global_Objects/Array/Array#compatibilit%C3%A9_des_navigateurs:

Before:

Screen Shot 2026-03-12 at 17 28 53

After:

Screen Shot 2026-03-12 at 17 29 02

@LeoMcA LeoMcA requested a review from a team as a code owner March 12, 2026 17:32
@LeoMcA LeoMcA requested a review from caugner March 12, 2026 17:32
@LeoMcA LeoMcA changed the title fix(l10n): client-rendered strings weren't loaded fix(l10n): client-rendered strings always in en-US Mar 12, 2026
@github-actions
Copy link
Copy Markdown
Contributor

e9334ac was deployed to: https://fred-pr1369.review.mdn.allizom.net/

@caugner caugner merged commit 47c72a6 into main Mar 12, 2026
12 checks passed
@caugner caugner deleted the fix-l10n-client-strings branch March 12, 2026 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants