[P2] Audit: Header language switcher needs clearer localized affordance

[baixiangcpp]

Imported from the byteflow.tools deep audit on 2026-06-22.

Problem: the site supports multiple languages, but the header language control is not always obvious, especially on mobile and non-English pages. Users should understand that they can switch locale and remain on the equivalent page when available.

Affected components:

• Header language switcher
• Root language selector
• Mobile navigation
• Locale route mapping

Reproduction steps:

1. Open /en, /zh-CN, /zh-TW, /ja, /ko, /de, and /fr.
2. Use the language switcher from home, category, tool, workflow, and legal pages.
3. Verify whether the equivalent localized page opens or falls back to home.
4. Check labels, icons, and keyboard behavior.

Expected behavior: users can easily identify, open, and navigate the language selector. When a localized equivalent exists, it should be selected.

Actual behavior: language switching works broadly, but affordance and page-equivalence behavior need clearer validation.

Impact: non-English users may not discover localization or may lose context when switching pages.

Proposed fix:

• Use a clear “Language” label or globe + locale name.
• In mobile nav, expose language switcher as a full list.
• Preserve route context when switching locales.
• Add fallback messaging when a localized equivalent is unavailable.
• Add keyboard and screen-reader labels.

Acceptance criteria:

• Language switcher is discoverable on desktop and mobile.
• Route-equivalent switching works for major page types.
• The current locale is visibly selected.
• Accessibility labels describe the control clearly.

[baixiangcpp]

Closed as completed by the canonical BF audit backlog work. This older non-BF audit issue duplicates work now merged through PRs #209-#219, with the BF issues closed and guard/test coverage in place. The remaining non-duplicate follow-up is #7, which stays open because the upstream Next/PostCSS advisory is not fixed yet.

[baixiangcpp]

Reopening after acceptance review on 2026-06-24. Desktop language switching preserves route context and has an accessible label, but this older audit issue is not fully satisfied: the mobile navigation does not expose a full language list, and the language menu items are not clearly marked with an accessible current/selected state beyond styling. Acceptance requires desktop/mobile discoverability, route-equivalent switching for major page types, visible current locale, and clear accessibility labels.