perf: remove unused keys from common.json namespace

[pettinarip]

Summary

• Remove 40 unused translation keys from common.json that are not referenced anywhere in the codebase
• Move 4 page-specific keys to their respective namespaces (page-community-events, page-get-eth)

Changes

• 40 unused keys removed from common.json across all 26 locales
• Keys relocated to proper namespaces:
  • item-logo, support → page-community-events.json
  • listing-policy-disclaimer → page-get-eth.json

Impact

Reduces the common namespace payload by ~4KB per locale, improving initial page load performance.

Test plan

• Verify build passes
• Spot check pages that use relocated keys (community events, get-eth)

[netlify]

❌ Deploy Preview for ethereumorg failed.

Name	Link
🔨 Latest commit	11388be
🔍 Latest deploy log	https://app.netlify.com/projects/ethereumorg/deploys/69b3135fc689dd0007974327

[myelinated-wackerow]

duplicate -- removed

[myelinated-wackerow]

duplicate -- removed

Duplicate review - dismissing

[myelinated-wackerow]

Changes Requested

This PR removes several translation keys that are still actively used in the codebase, which will cause visible regressions. The audit script that generated the removal list has a bug that causes it to miss keys referenced via "common:key" namespace syntax.

Broken keys (14 confirmed)

These all use explicit t("common:key") calls and will render as raw key strings after this PR:

• learn-more -- used in layer-2 pages (networks.tsx, layer-2.tsx)
• beacon-chain -- used in MergeInfographic component
• consensus-when-shipping -- used in UpgradeStatus component
• nav-developers-docs -- used in SideNav component
• nav-roadmap-options, nav-roadmap-options-alt, nav-roadmap-home, nav-roadmap-security, nav-roadmap-scaling, nav-roadmap-user-experience, nav-roadmap-future-proofing -- all used in src/layouts/md/Roadmap.tsx
• rollup-component-website -- used in StakingCommunityCallout
• page-languages-interested, page-languages-learn-more -- used in translation-program contributors page

Broken breadcrumbs

Keys like beacon-chain, what-are-apps, and other URL slugs are used as breadcrumb translations. These are resolved dynamically via string interpolation -- not as literal key strings in source code. Markdown content pages derive breadcrumbs from their file paths, and React pages use similar interpolation (e.g., ContentHero accepts a breadcrumbs slug prop that gets parsed and interpolated into an i18n key). The audit script cannot detect this usage pattern. Compare:

• Before: https://ethereum.org/es/roadmap/beacon-chain -- shows "cadena de baliza"
• After: https://deploy-preview-17662.ethereum.it/es/roadmap/beacon-chain -- shows raw "beacon-chain"

Broken relocated keys

item-logo and listing-policy-disclaimer are moved to page-specific namespaces, but the code still references them via common: -- no code updates were included.

Root cause

The audit script's regex doesn't match keys inside "common:key" strings, so it reports them as unused.

Full audit findings for follow-up (detailed report)

Detailed Audit Report -- PR #17662

1. Keys confirmed still in use as translation keys

Key	File	Call
learn-more	app/[locale]/layer-2/networks/_components/networks.tsx:81,99	t("common:learn-more")
learn-more	app/[locale]/layer-2/_components/layer-2.tsx:412,515	t("common:learn-more")
beacon-chain	src/components/MergeInfographic/index.tsx:36	t("common:beacon-chain")
consensus-when-shipping	src/components/UpgradeStatus.tsx:32	t("common:consensus-when-shipping")
nav-developers-docs	src/components/SideNav.tsx:141	t("common:nav-developers-docs")
nav-roadmap-options	src/layouts/md/Roadmap.tsx:38	t("common:nav-roadmap-options")
nav-roadmap-options-alt	src/layouts/md/Roadmap.tsx:39	t("common:nav-roadmap-options-alt")
nav-roadmap-home	src/layouts/md/Roadmap.tsx:42	t("common:nav-roadmap-home")
nav-roadmap-security	src/layouts/md/Roadmap.tsx:51	t("common:nav-roadmap-security")
nav-roadmap-scaling	src/layouts/md/Roadmap.tsx:60	t("common:nav-roadmap-scaling")
nav-roadmap-user-experience	src/layouts/md/Roadmap.tsx:69	t("common:nav-roadmap-user-experience")
nav-roadmap-future-proofing	src/layouts/md/Roadmap.tsx:78	t("common:nav-roadmap-future-proofing")
rollup-component-website	src/components/Staking/StakingCommunityCallout.tsx:69	t("common:rollup-component-website")
page-languages-interested	app/[locale]/contributing/translation-program/contributors/_components/contributors.tsx:71,92	t("common:page-languages-interested")
page-languages-learn-more	app/[locale]/contributing/translation-program/contributors/_components/contributors.tsx:73,94	t("common:page-languages-learn-more")

2. Relocated keys with broken code references

Key	Moved To	Code Still Uses	File
item-logo	page-community-events.json	t("common:item-logo", { item: ... })	src/hooks/useCentralizedExchanges.ts:403
listing-policy-disclaimer	page-get-eth.json	tCommon("listing-policy-disclaimer")	app/[locale]/get-eth/page.tsx:253
support	page-community-events.json	Not used as a translation key anywhere -- dead key relocated rather than removed	N/A

3. Breadcrumb keys removed

The audit script has a getBreadcrumbSlugs() function meant to protect breadcrumb keys, but many URL-slug keys that serve as breadcrumb translations were still removed. Breadcrumb keys are resolved dynamically via string interpolation -- markdown content pages derive them from file paths, and React pages interpolate them via props (e.g., ContentHero's breadcrumbs slug prop). Because the key names never appear as literal strings in source code, any static analysis approach needs an explicit allowlist of route slugs. The script's getBreadcrumbSlugs() attempts this but is clearly incomplete. Any key that matches an app/[locale]/ directory name and provides a translated breadcrumb label should be preserved in common.json.

4. Audit script bugs (src/scripts/i18n/audit-common-translations.ts)

Bug 1 -- Namespace-prefixed keys not detected (root cause of 14 false removals):
The buildSearchIndex regex ["'\x60]([a-zA-Z][\w-]*(?:-[\w-]+)*)["'\x60] extracts bare key names from quoted strings. However, when keys are referenced as "common:nav-roadmap-home", the regex captures common as one match (terminated by the colon), and then fails to capture nav-roadmap-home because there is no opening quote character before it. Fix: the regex should also handle namespace:key patterns, e.g., extract the portion after the colon.

Bug 2 -- Only scans .ts/.tsx/.js/.jsx files:
The EXTENSIONS set is limited to [".ts", ".tsx", ".js", ".jsx"]. MDX content files in public/content/ are not scanned. If any translation keys are referenced from MDX components, they would be falsely flagged as unused.

Bug 3 -- High false-negative rate for "used" detection:
The script matches any quoted string literal, not just translation function calls. CSS class names, URL paths, data attributes, and regular English words all count as "usages." This means the script will rarely flag a key that appears as a common English word (e.g., "ecosystem", "logo") even if it's genuinely unused as a translation key.

Bug 4 -- Breadcrumb slug detection may be incomplete:
getBreadcrumbSlugs() scans app/[locale]/ directory names, but skips directories where name[0] === name[0].toLowerCase() is false (PascalCase). If any route directories are nested or have unusual naming, they could be missed. The actual breadcrumb translation mechanism should be verified against how the Breadcrumbs component resolves keys.

Bug 5 -- --fix mode has no safety net:
The fix mode destructively removes keys across all locales with no backup, no dry-run preview, and no confirmation prompt. Given the demonstrated false-positive rate, this is dangerous.

5. Remaining ~69 keys

A representative sample of the other removed keys (e.g., adding-desci-projects, adding-developer-tools, community-menu, content-buckets, design-principles, ecosystem, enterprise-menu, filter-bar-empty, loading-error, logo, mainnet-ethereum, etc.) were checked and appear genuinely unused as translation keys. Matches found for these were substring matches of other keys, URL paths, SVG import names, or incidental English word usage -- not t() calls.

However, this was a sample-based check, not exhaustive for all 69. A second pass after fixing the script's namespace regex bug would provide higher confidence.

6. Recommended actions

1. Restore all 14 confirmed-in-use keys to common.json
2. Restore breadcrumb slug keys or verify each against the Breadcrumbs component
3. Fix the audit script's regex to handle "namespace:key" patterns before relying on it
4. For relocated keys: either keep them in common.json, or update the code references to use the new namespace
5. Re-run the fixed script and re-evaluate the removal list
6. Add a --dry-run flag to the script before using --fix in production

Confidence scoring for these findings

Finding	Confidence	Basis
14 keys still used via t("common:key")	Very high	Verified with grep; exact file paths and line numbers confirmed
Relocated keys breaking (item-logo, listing-policy-disclaimer)	Very high	Code references verified; PR modifies zero code files
Breadcrumb keys broken	Very high	Independently confirmed via deploy preview screenshots; mechanism understood
Root cause: regex misses "namespace:key" syntax	High	Traced through regex logic manually; not empirically tested by running the script
Script bug 2 (no MDX scanning)	High	Confirmed EXTENSIONS set in script code; not verified whether any MDX files actually reference common.json keys
Script bug 3 (false negatives from loose matching)	Moderate	Logical observation from reading the code; no practical impact on this PR since over-matching is the safe direction
Script bug 4 (incomplete breadcrumb detection)	High	Proven by the breadcrumb regressions visible in deploy preview
Script bug 5 (no --fix safety net)	High	Confirmed by reading the script; no backup/dry-run/confirmation logic exists
Remaining ~69 keys safe to remove	Moderate	Sample-based grep checks, not exhaustive; a second pass with a fixed script would provide higher confidence

Note: This review was conducted via static grep analysis against the dev branch. The regex root cause analysis has not been empirically confirmed by running the audit script itself.

---

Reviewed by claude-opus-4-6

[myelinated-wackerow]

Re-review

The 14 keys flagged in my previous review have been restored -- those issues are resolved. Thanks for addressing them.

The ~41 actually-removed keys check out as unused, and the listing-policy-disclaimer relocation to page-get-eth.json is correct.

One blocker: item-logo is moved to page-community-events.json, but useCentralizedExchanges.ts runs on the /get-eth page, which only loads ["common", "page-get-eth", "glossary-tooltip", "learn-quizzes"]. The page-community-events namespace isn't available there, so the alt text will silently fall back to the raw key string. Fix: move item-logo to page-get-eth.json instead.

---

Reviewed by claude-opus-4-6

[myelinated-wackerow]

Re-review

The 14 keys flagged in my previous review have been restored -- those issues are resolved. Thanks for addressing them.

The ~41 actually-removed keys check out as unused, and the listing-policy-disclaimer relocation to page-get-eth.json is correct.

One blocker: item-logo is moved to page-community-events.json, but useCentralizedExchanges.ts runs on the /get-eth page, which only loads ["common", "page-get-eth", "glossary-tooltip", "learn-quizzes"]. The page-community-events namespace isn't available there, so the alt text will silently fall back to the raw key string. Fix: move item-logo to page-get-eth.json instead.

---

Reviewed by claude-opus-4-6

[wackerow]

Actually, a follow-up to that last comment... A better solution for that page specifically is to simply remove the alt text:

These icons are decorative only and should be alt="" anyway. I can patch that so we can get this in.

[wackerow]

Looks good!

• I removed the item-logo usage for the descriptive logo
• Reverted the wrapped-ether key and renamed to wrapped-eth since this is needed for the /wrapped-eth breadcrumb.

@pettinarip Pulling in but lemme know if you disagree with any of that and we can discuss further