aaif-goose/goose

Feat: Add Spanish (es) locale support for Desktop UI

Open

Aperta il 26 mag 2026

Vedi su GitHub
 (0 commenti) (0 reazioni) (0 assegnatari)Rust (45.211 star) (4628 fork)batch import
good first issue

Descrizione

Problem Description

Goose has great i18n infrastructure with support for English and Chinese (zh-CN), but there's no Spanish locale — and Spanish is the second most spoken native language in the world with over 500 million speakers. Adding it would make Goose more accessible to a large community that currently has to use it in English or Chinese.

The project already documents the exact steps in I18N.md ("Adding a new language" section), so the path is clear.

Proposed Solution

Add es as a supported locale in the Goose Desktop UI by:

  1. Creating src/i18n/messages/es.json based on en.json with all defaultMessage values translated to Spanish (keeping ICU syntax intact).
  2. Adding "es" to SUPPORTED_LOCALES in src/i18n/index.ts.
  3. Optionally adding native Electron menu translations (File, Edit, View, etc.) in main.ts, mirroring the existing MENU_TRANSLATIONS_ZH_CN.

Since loadMessages() already handles dynamic catalog loading and falls back to English for missing keys, partial translations work out of the box — no risk of breaking anything.

Size consideration

I read CONTRIBUTING.md and understand the concern about large first PRs. en.json is ~4800 lines, so I want to align with maintainers on the best approach before writing code:

  • Option A: One PR with the full translation (bulk of the diff is JSON, trivial to review side-by-side with en.json)
  • Option B: Start with a smaller PR covering infrastructure + core UI strings (chat, navigation, menus, onboarding — ~300 lines), then follow up with incremental PRs for the remaining sections

Happy to go either way based on what the maintainers prefer.

Alternatives Considered

  • Using GOOSE_LOCALE env var with a partial translation — this already works today as a local workaround, but it requires the user to modify source code and rebuild. A proper PR makes it available to everyone.

Additional Context

  • The i18n setup (react-intl, ICU MessageFormat) already supports pluralization, select, and date/number formatting per locale — no infrastructure changes needed.

  • The I18N.md doc explicitly lists the steps for adding a new language (copy en.json, translate, add to SUPPORTED_LOCALES).

  • Happy to sign off commits with DCO (git commit -s) per the project requirements.

  • I have verified this does not duplicate an existing feature request

Guida contributor