hermes - ✅(Solved) Fix Clarify dashboard i18n scope for hardcoded UI and dynamic metadata [1 pull requests, 1 comments, 1 participants]

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…
GitHub stats
NousResearch/hermes-agent#28645Fetched 2026-05-20 04:02:58
View on GitHub
Comments
1
Participants
1
Timeline
6
Reactions
0
Participants
Timeline (top)
labeled ×4commented ×1cross-referenced ×1

Root Cause

  1. Should purely frontend hardcoded dashboard UI strings be moved into web/src/i18n/en.ts / types.ts as the native English source of truth?
  2. Should raw backend enum/status values be displayed through localized frontend maps?
  3. Should config schema and env-var descriptions be localizable in the dashboard, or intentionally stay English because they are developer/operator metadata?
  4. Should skill and plugin manifest descriptions stay in their source language, or should the dashboard support locale-specific display metadata/overrides?

Fix Action

Fixed

PR fix notes

PR #28853: fix(web-dashboard): localize dashboard i18n metadata surfaces

Description (problem / solution / changelog)

What does this PR do?

Expands the dashboard i18n contract so visible web dashboard strings and backend metadata fallbacks route through locale catalogs instead of hardcoded English or mixed dynamic text.

This covers static dashboard UI strings, config/env/skills/plugins metadata overlays, cron interval display text, and Turkish translations for the newly exposed surfaces.

Related Issue

Fixes #28645

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update
  • Refactor / cleanup

Changes Made

  • Added translation keys and typed metadata maps in web/src/i18n/types.ts, en.ts, and tr.ts.
  • Added empty metadata map placeholders for other locales so they can continue falling back cleanly to English.
  • Routed dashboard components/pages through i18n for hardcoded strings in models, chat sidebar, analytics, sessions, profiles, config, env, cron, skills, and plugins surfaces.
  • Added localized metadata overlays for skill descriptions, toolset descriptions, plugin descriptions/status/source labels, env descriptions, and config field labels/descriptions.
  • Localized cron interval schedule display while leaving runtime job names and log output verbatim.

How to Test

  1. cd web && npx tsc -b --force --pretty false
  2. cd web && npm run build
  3. Start the dashboard, switch the UI to Turkish, and inspect Models, Skills, Plugins, Config, Keys/Env, and Cron.

Checklist

Code

  • I've read the contributing guidelines
  • My commit messages follow Conventional Commits
  • I searched existing PRs and did not find a duplicate
  • My PR contains only related changes
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes where appropriate
  • I've tested on my platform: Linux

Documentation & Housekeeping

  • Documentation update not required for this dashboard-only change
  • Config example update not required
  • CONTRIBUTING / AGENTS update not required
  • Cross-platform impact reviewed: web/i18n only
  • Tool descriptions/schemas not affected

Screenshots / Logs

Validation completed:

  • cd web && npx tsc -b --force --pretty false
  • cd web && npm run build
  • git diff --check

scripts/run_tests.sh was attempted after creating a local .venv, but the final result was not captured because the long-running pytest process outlived the tool timeout. Existing .pytest_cache/v/cache/lastfailed entries are in unrelated non-dashboard areas, so this PR does not claim a full-suite pytest pass.

Changed files

  • web/src/App.tsx (modified, +10/-15)
  • web/src/components/AutoField.tsx (modified, +48/-13)
  • web/src/components/BottomPickSheet.tsx (modified, +4/-2)
  • web/src/components/ChatSidebar.tsx (modified, +25/-18)
  • web/src/components/ModelInfoCard.tsx (modified, +16/-11)
  • web/src/components/ModelPickerDialog.tsx (modified, +28/-18)
  • web/src/components/OAuthLoginModal.tsx (modified, +1/-1)
  • web/src/components/OAuthProvidersCard.tsx (modified, +5/-2)
  • web/src/components/PlatformsCard.tsx (modified, +1/-1)
  • web/src/components/ThemeSwitcher.tsx (modified, +12/-7)
  • web/src/components/ToolCall.tsx (modified, +10/-8)
  • web/src/i18n/af.ts (modified, +239/-5)
  • web/src/i18n/de.ts (modified, +239/-5)
  • web/src/i18n/en.ts (modified, +1249/-5)
  • web/src/i18n/es.ts (modified, +239/-5)
  • web/src/i18n/fr.ts (modified, +239/-5)
  • web/src/i18n/ga.ts (modified, +239/-5)
  • web/src/i18n/hu.ts (modified, +239/-5)
  • web/src/i18n/it.ts (modified, +239/-5)
  • web/src/i18n/ja.ts (modified, +239/-5)
  • web/src/i18n/ko.ts (modified, +239/-5)
  • web/src/i18n/pt.ts (modified, +239/-5)
  • web/src/i18n/ru.ts (modified, +239/-5)
  • web/src/i18n/tr.ts (modified, +1251/-7)
  • web/src/i18n/types.ts (modified, +195/-0)
  • web/src/i18n/uk.ts (modified, +239/-5)
  • web/src/i18n/zh-hant.ts (modified, +239/-5)
  • web/src/i18n/zh.ts (modified, +238/-3)
  • web/src/lib/utils.ts (modified, +42/-13)
  • web/src/pages/AnalyticsPage.tsx (modified, +12/-20)
  • web/src/pages/ChatPage.tsx (modified, +8/-8)
  • web/src/pages/ConfigPage.tsx (modified, +4/-3)
  • web/src/pages/CronPage.tsx (modified, +68/-18)
  • web/src/pages/EnvPage.tsx (modified, +28/-14)
  • web/src/pages/ModelsPage.tsx (modified, +116/-73)
  • web/src/pages/PluginsPage.tsx (modified, +34/-12)
  • web/src/pages/ProfilesPage.tsx (modified, +1/-1)
  • web/src/pages/SessionsPage.tsx (modified, +3/-3)
  • web/src/pages/SkillsPage.tsx (modified, +19/-6)
RAW_BUFFERClick to expand / collapse

Problem

While reviewing the Turkish dashboard locale, I found that the remaining English text is not just a Turkish translation gap. Several visible dashboard surfaces bypass the web i18n catalog entirely or are sourced from backend/plugin/skill metadata.

The Turkish catalog currently has key parity with the English catalog, but users still see English in places such as Models, Keys, Config, Plugins, and Skills.

Examples of surfaces outside the current web i18n contract

  • Frontend hardcoded UI strings:
    • web/src/pages/ModelsPage.tsx: Model Settings, applies to new sessions, Main model, Auxiliary tasks, Use as, token/cost hidden notice, auxiliary task labels, capability badges.
    • web/src/pages/EnvPage.tsx: jump-nav labels such as OAuth, Providers, Tools, Messaging, Settings.
    • web/src/components/AutoField.tsx: generated labels and placeholder text such as comma-separated values.
    • web/src/components/ModelPickerDialog.tsx, ModelInfoCard.tsx, and web/src/lib/utils.ts: modal labels and time-ago strings.
  • Backend-generated dashboard metadata:
    • hermes_cli/web_server.py config schema descriptions and fallback generated labels.
    • hermes_cli/config.py env var descriptions/prompts shown in the Keys page.
  • Dynamic content/metadata:
    • Skill descriptions from SKILL.md frontmatter.
    • Plugin descriptions from plugin manifests.
    • Raw enum/status values such as bundled, inactive, enabled, disabled.

Why I am asking before opening a broad PR

There is precedent for a deliberately limited i18n scope in agent/i18n.py and the configuration docs: display.language intentionally translates only a thin slice of static Hermes messages and leaves generated/tool/log output in English. However, the web dashboard has its own i18n catalog, and it is not obvious whether dashboard metadata such as config/env/plugin/skill descriptions should be localized or intentionally remain English.

Related context I found:

  • #9301 and #9626 requested web dashboard i18n for hardcoded English strings.
  • #9453 added the initial web dashboard i18n layer.
  • #23574 discusses limited display.language coverage.
  • #23243 proposes broader Dashboard + embedded TUI localization, including config fields.
  • #28578 mentions avoiding a forced multi-locale translation pass for every new dashboard key.

Questions

  1. Should purely frontend hardcoded dashboard UI strings be moved into web/src/i18n/en.ts / types.ts as the native English source of truth?
  2. Should raw backend enum/status values be displayed through localized frontend maps?
  3. Should config schema and env-var descriptions be localizable in the dashboard, or intentionally stay English because they are developer/operator metadata?
  4. Should skill and plugin manifest descriptions stay in their source language, or should the dashboard support locale-specific display metadata/overrides?

Proposed first step if maintainers agree

I can prepare a small PR that only handles the safe/static frontend slice first: move hardcoded UI strings into the English web i18n catalog and wire components to the existing useI18n() contract. That PR would not translate dynamic skill/plugin/env metadata unless maintainers want that scope included.

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

hermes - ✅(Solved) Fix Clarify dashboard i18n scope for hardcoded UI and dynamic metadata [1 pull requests, 1 comments, 1 participants]