hugo/RuDS
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Localize the TUI: replace hardcoded English strings with fluent translations #43

New Issue
Closed
opened 2026-07-20 10:38:18 +00:00 by hugo · 1 comment
hugo commented 2026-07-20 10:38:18 +00:00
Owner
Copy Link

Context

crates/bds-server/src/tui.rs contains roughly 89 hardcoded English UI strings: settings form field labels ("Project name", "Online endpoint URL", "Data folder", …), ~43 status-line messages ("Tag created", "Project switched", "Commit message is required.", "Airplane mode: configure a local AI endpoint first.", …), prompt titles, and confirmations. Only 5 bds_core::i18n::translate calls exist (section nav labels). This violates the AGENTS rule "no untranslated string constants" and hollows out specs/tui.allium rule ServerSideLocale — when the server UI language changes, the TUI re-renders but most text stays English.

Task

  1. Move every user-visible string literal in tui.rs to fluent keys resolved through bds_core::i18n::translate(locale, key) with the TUI's current locale (self.locale). Group keys under a tui- prefix consistent with the existing keys (see tui.settingTheme naming already referenced in the section-label mapping).
  2. Add the keys to all five locales/ui/*.ftl files (en, de, es, fr, it) with proper translations. For parametrized messages (counts, paths, tag names) use fluent placeables, not format! concatenation of translated fragments.
  3. Strings that are data, not UI (git hashes, file paths, slugs, values echoed back) stay as-is.
  4. Verify ServerSideLocale end-to-end: changing ui.language in the settings panel re-renders the whole TUI in the new language, including form labels and subsequent status messages. Extend the existing TUI locale test to assert at least one settings field label and one status message change language.
  5. Keep the existing TUI tests green; update snapshot/renderer-buffer assertions that matched English literals to use the translation lookup.

Definition of done

  • grep for multi-word English literals in tui.rs finds no user-visible UI strings.
  • All five locales contain the new keys; cargo test --workspace passes.
## Context `crates/bds-server/src/tui.rs` contains roughly 89 hardcoded English UI strings: settings form field labels ("Project name", "Online endpoint URL", "Data folder", …), ~43 status-line messages ("Tag created", "Project switched", "Commit message is required.", "Airplane mode: configure a local AI endpoint first.", …), prompt titles, and confirmations. Only 5 `bds_core::i18n::translate` calls exist (section nav labels). This violates the AGENTS rule "no untranslated string constants" and hollows out `specs/tui.allium` rule `ServerSideLocale` — when the server UI language changes, the TUI re-renders but most text stays English. ## Task 1. Move every user-visible string literal in `tui.rs` to fluent keys resolved through `bds_core::i18n::translate(locale, key)` with the TUI's current locale (`self.locale`). Group keys under a `tui-` prefix consistent with the existing keys (see `tui.settingTheme` naming already referenced in the section-label mapping). 2. Add the keys to all five `locales/ui/*.ftl` files (en, de, es, fr, it) with proper translations. For parametrized messages (counts, paths, tag names) use fluent placeables, not `format!` concatenation of translated fragments. 3. Strings that are data, not UI (git hashes, file paths, slugs, values echoed back) stay as-is. 4. Verify `ServerSideLocale` end-to-end: changing `ui.language` in the settings panel re-renders the whole TUI in the new language, including form labels and subsequent status messages. Extend the existing TUI locale test to assert at least one settings field label and one status message change language. 5. Keep the existing TUI tests green; update snapshot/renderer-buffer assertions that matched English literals to use the translation lookup. ## Definition of done - `grep` for multi-word English literals in `tui.rs` finds no user-visible UI strings. - All five locales contain the new keys; `cargo test --workspace` passes.
hugo added the bug label 2026-07-20 10:40:14 +00:00
hugo commented 2026-07-20 13:12:26 +00:00
Author
Owner
Copy Link

Implemented in 49dc88c. Replaced the TUI user-visible English literals with 117 Fluent messages across all five UI locales, including sidebar headers, editor and settings labels, prompts and confirmations, task lifecycle text, Git and tag workflows, report bodies, image details, validation errors, and parameterized counts, paths, names, and output. Command-palette display names are localized while stable non-UI command IDs preserve dispatch behavior. A ui.language event now relocalizes existing sidebar data, open settings fields, command candidates, and open reports; the regression test proves an already-open field changes from English to German and the next status is German. Verified neutrally against the issue, bDS2 localization behavior, and the Allium ServerSideLocale rule with no completeness gaps found. Gates passed: allium check and analyse, five-locale catalog and variable completeness, untranslated-literal scan, changed-source rustfmt check, cargo machete --with-metadata, cargo outdated --workspace --root-deps-only --exit-code 1, cargo clippy --workspace --all-targets -- -D warnings, cargo build --workspace, cargo test --workspace, and git diff --check.

Implemented in 49dc88c. Replaced the TUI user-visible English literals with 117 Fluent messages across all five UI locales, including sidebar headers, editor and settings labels, prompts and confirmations, task lifecycle text, Git and tag workflows, report bodies, image details, validation errors, and parameterized counts, paths, names, and output. Command-palette display names are localized while stable non-UI command IDs preserve dispatch behavior. A ui.language event now relocalizes existing sidebar data, open settings fields, command candidates, and open reports; the regression test proves an already-open field changes from English to German and the next status is German. Verified neutrally against the issue, bDS2 localization behavior, and the Allium ServerSideLocale rule with no completeness gaps found. Gates passed: allium check and analyse, five-locale catalog and variable completeness, untranslated-literal scan, changed-source rustfmt check, cargo machete --with-metadata, cargo outdated --workspace --root-deps-only --exit-code 1, cargo clippy --workspace --all-targets -- -D warnings, cargo build --workspace, cargo test --workspace, and git diff --check.
hugo closed this issue 2026-07-20 13:12:38 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
hugo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: hugo/RuDS#43
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?