← Back to PRs

#22165: feat(i18n): translate hardcoded button labels to all 4 locales

by NikolaVujovic1988 open 2026-02-20 20:21 View on GitHub →
app: web-ui size: M
Summary - Problem: ~15 view files have hardcoded English button labels ("Save", "Refresh", "Loading…", etc.) that bypass the existing i18n system. - Why it matters: Non-English users (zh-CN, zh-TW, pt-BR) see a mix of translated and untranslated UI, breaking the localization experience. - What changed: Added common.actions section (28 keys) to all 4 locale files and replaced hardcoded strings with t() calls across 18 files. - What did NOT change: No logic, styling, or behavior changes. Only string literals were swapped for i18n lookups. Change Type - Feature Scope - UI / DX Linked Issue/PR None User-visible / Behavior Changes - Button labels (Save, Refresh, Cancel, Delete, etc.) now render in the user's selected locale instead of always English. - English users see no difference — the English translations match the previous hardcoded strings exactly. Security Impact - New permissions/capabilities? No - Secrets/tokens handling changed? No - New/changed network calls? No - Command/tool execution surface changed? No - Data access scope changed? No Repro + Verification Environment - OS: macOS Darwin 24.6.0 - Runtime/container: Browser (Lit-based SPA) Steps 1. Set dashboard language to zh-CN, zh-TW, or pt-BR via the overview settings. 2. Navigate to any tab (Agents, Config, Nodes, Sessions, etc.). 3. Check that buttons like Refresh, Save, Cancel, Delete render in the selected language. Expected - All common button labels appear translated. Actual - Previously showed English regardless of locale. Now translated. Evidence - Trace/log snippets # Zero remaining hardcoded labels after change: $ grep -rE '"Loading…"|"Refreshing…"|"Saving…"|"Applying…"|"Updating…"' ui/src/ui/ (no results) # All 4 locales have identical 28-key structure: en.ts:28 zh-CN.ts:28 zh-TW.ts:28 pt-BR.ts:28 Human Verification - Verified scenarios: Grepped entire ui/src/ui/ for remaining hardcoded common button labels — none found. Confirmed all 4 locale files have matching 28-key actions structure. - Edge cases checked: Files that didn't previously import t got the correct relative import path (../../i18n/index.ts). - What I did not verify: Visual rendering in each locale in a running browser. Compatibility / Migration - Backward compatible? Yes - Config/env changes? No - Migration needed? No Failure Recovery - How to revert: Revert this single commit — all changes are additive locale keys + mechanical string replacements. - Known bad symptoms: If a translation key is mistyped, t() returns the key path as fallback text (e.g. common.actions.save), which is immediately obvious. Risks and Mitigations - Risk: Translation quality for zh-CN/zh-TW/pt-BR may not be perfect. - Mitigation: Translations follow conventions already established in the existing locale files. Native speakers can refine in follow-up PRs. <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds comprehensive i18n support for common button labels across the UI by introducing 28 new translation keys under `common.actions` in all 4 supported locales (en, zh-CN, zh-TW, pt-BR) and updating 18 UI component files to use these translations instead of hardcoded English strings. - All locale files maintain identical key structures - Import paths are correctly calculated relative to file locations - No breaking changes - existing `common.refresh` key preserved for backward compatibility alongside new `common.actions.refresh` - Changes are purely presentational - no logic, styling, or behavior modifications - Successfully eliminates hardcoded English button labels ("Save", "Refresh", "Loading…", etc.) throughout the UI components <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The changes are mechanical string replacements with no logic modifications. All 4 locale files have identical, well-structured keys. Import paths are correct. The existing i18n system is already in place and working. Backward compatibility is maintained by preserving existing keys. - No files require special attention <sub>Last reviewed commit: 36d9ef1</sub> <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> <!-- /greptile_comment -->

Most Similar PRs