Skip to content

Add Spanish translation and language selector to website#128

Open
andyechc wants to merge 1 commit into
frankea:mainfrom
andyechc:website-i18n
Open

Add Spanish translation and language selector to website#128
andyechc wants to merge 1 commit into
frankea:mainfrom
andyechc:website-i18n

Conversation

@andyechc

@andyechc andyechc commented Jul 2, 2026

Copy link
Copy Markdown

Adds full Spanish (es) translation to the Whisky homepage at dist/pages/index.html with a client-side language selector.

Changes

  • Language selector — EN/ES toggle buttons in the top-right corner, persisted via localStorage
  • All text translated — tagline, descriptions, feature lists, graphics backend details, documentation links, footer
  • Localized metadata<title>, Open Graph and Twitter Card meta tags are language-aware
  • Localized image alt text — screenshot alt attributes switch with language
  • Implementation — simple data-en / data-es attributes on all translatable elements, JS swaps content and updates <html lang>

Preview

Open the file in any browser and click "ES" in the top-right corner to switch languages. The choice persists across visits.

@frankea frankea left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @andyechc — this is a clean, self-contained approach (no dependencies, localStorage persistence, easy to revert). A few things to fix before it can go in, plus one decision that's on me.

Bugs:

  1. Image alt localization never runs. switchLang iterates document.querySelectorAll('[data-en]'), but the <img> tags only carry data-en-alt / data-es-alt (no bare data-en), so they're never selected — the el.hasAttribute('alt') branch is effectively dead code and the alt text never switches languages.
  2. The first screenshot's English alt is Spanish. data-en-alt="Creando un nuevo Wine bottle en Whisky" — both alts on that image are Spanish; the data-en-alt needs the English string.

Worth tightening:

  1. Toggling to EN rewrites the visible English copy from data-en, which has drifted from the static markup — it drops <em>by design</em> and changes "Apple's D3DMetal" → "Apple D3DMetal". Keep each data-en byte-identical to the rendered fallback so clicking EN is a no-op.
  2. The JS-swapped <title> / OG / Twitter content won't help SEO or social cards — crawlers and link scrapers don't execute JS, so they'll always read the static English. It only changes the live browser tab, where those meta values aren't user-visible. Not harmful, just won't do what the description implies for metadata.

The decision that's on me: i18n on a hand-maintained page means every future copy edit has to be mirrored across data-en + data-es, and drift (see #3) creeps in fast. I want to think about whether that maintenance overhead is worth it before merging — I'll follow up here. Nothing for you to change on that front; just being transparent that it's part of the call.

Fixes 1 and 2 are the blockers. Thanks again for the contribution.

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.

2 participants