hermes - 💡(How to fix) Fix [Feature]: Add Portuguese (pt-BR) language support to the desktop app (i18n / localization)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
RAW_BUFFERClick to expand / collapse

Feature Description

Add Portuguese (pt-BR) as a fully supported and selectable language option in the Hermes Desktop app UI.

Motivation

Hermes Agent already ships strong backend and TUI i18n for Portuguese:

  • locales/pt.yaml (357+ lines of translated approval prompts, gateway messages, model switcher, etc.)
  • agent/i18n.py explicitly lists "pt" in SUPPORTED_LANGUAGES and includes comprehensive aliases:
    • "pt-br", "pt-pt", "portuguese", "português", "brasileiro", "brazilian"

However, the desktop application (apps/desktop/, the Electron-based rich UI) maintains a completely separate i18n layer under apps/desktop/src/i18n/.

Currently only two languages are exposed:

  • English (en)
  • Simplified Chinese (zh)

This is visible in:

  • apps/desktop/src/app/settings/appearance-settings.tsx (the Language section in Settings → Appearance)
  • apps/desktop/src/i18n/languages.ts (LOCALE_OPTIONS and LOCALE_META only contain en + zh)
  • apps/desktop/src/i18n/catalog.ts and types.ts (Locale union is 'en' | 'zh')
  • apps/desktop/src/i18n/en.ts (source of truth, ~28k lines)

Brazilian users (and Portuguese speakers in general) therefore cannot set the full desktop experience — command center, settings panels, notifications, profiles, artifacts, messaging, sidebar, boot screens, etc. — to Portuguese, even though the underlying agent already speaks it for approvals and slash replies.

As a daily user in Rio de Janeiro working with Brazilian labor law (bancário cases), having the entire interface in my native language significantly improves usability and reduces cognitive load.

Proposed Solution

  1. Desktop frontend i18n:

    • Create apps/desktop/src/i18n/pt.ts implementing the full Translations interface (start by copying en.ts and translating).
    • Update apps/desktop/src/i18n/languages.ts:
      • Add entry to LOCALE_OPTIONS (e.g. { id: 'pt', name: 'Português', configValue: 'pt' })
      • Extend LOCALE_META
      • Expand LOCALE_ALIASES with Brazilian and European variants + natural names
    • Update apps/desktop/src/i18n/catalog.ts to import { pt } from './pt' and include it in TRANSLATIONS
    • Update apps/desktop/src/i18n/types.ts: change type Locale = 'en' | 'zh' | 'pt'
    • Update tests (languages.test.ts, context.test.tsx, runtime.test.ts) to cover the new locale
  2. Integration:

    • The existing setLocale / withConfigDisplayLanguage already writes to the shared display.language in ~/.hermes/config.yaml. This will automatically benefit the TUI/agent once the desktop choice is made.
    • Respect pt-BR / pt-PT system locales for auto-detection / initial suggestion (see normalizeLocale and Electron app.getLocale usage in apps/desktop/electron/main.cjs).
  3. Documentation & consistency:

    • Update the outdated supported language list in hermes_cli/config.py (DEFAULT_CONFIG comment) and the docstring in agent/i18n.py.
    • Consider adding a /language pt convenience in TUI if not present.

Alternatives Considered

  • Relying solely on backend display.language: pt — only covers a small subset of strings (approvals + a few gateway replies). The majority of the polished desktop surfaces remain in English.
  • On-the-fly machine translation of UI strings — bad for accuracy, performance, and maintenance.
  • Waiting for community PRs per language — the Japanese request (#40219) shows demand; we should make adding new locales straightforward and document the process.

Scope / Effort Estimate

Medium (mostly translation effort).

  • Wiring changes: small (4-5 files in apps/desktop/src/i18n/).
  • Translation: the bulk of the work (the en.ts catalog is comprehensive but well-structured with clear keys).
  • Once the pt.ts skeleton + wiring is done, machine-assisted translation + human review (by native speakers) is very feasible.
  • No backend changes required — Portuguese support is already there.

Additional Context

  • Current desktop language selector screenshot/description: Settings → Appearance shows a clean grid of language pills powered by LOCALE_META.
  • Backend catalog already has Portuguese: locales/pt.yaml (see first ~50 lines for approval and gateway sections).
  • Related: Japanese desktop + TUI support is also being requested (#40219).
  • The desktop i18n system was clearly designed to scale (strict Translations interface guarantees completeness via TypeScript).
  • Environment: macOS (user), but should work cross-platform.

I am happy to help with the PR if maintainers guide the translation process or provide a script to extract strings.


Labels suggestion: type/feature, area/i18n, comp/desktop, P3 (or higher if many Brazilian/Portuguese-speaking users appear)

Contribution

  • I'd like to help translate or review Portuguese strings

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING