Skip to content

UI: complete pt-BR control locale#61036

Closed
rubensfox20 wants to merge 1 commit into
openclaw:mainfrom
rubensfox20:feat/ptbr-control-ui-locale
Closed

UI: complete pt-BR control locale#61036
rubensfox20 wants to merge 1 commit into
openclaw:mainfrom
rubensfox20:feat/ptbr-control-ui-locale

Conversation

@rubensfox20

@rubensfox20 rubensfox20 commented Apr 4, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Problem: ui/src/i18n/locales/pt-BR.ts was missing large parts of the Control UI locale, so many strings still fell back to English.
  • Why it matters: Brazilian Portuguese users get an inconsistent localized experience across the web UI.
  • What changed: completed the pt-BR locale coverage for existing translated surfaces, including usage and cron sections, and aligned keys with the current English locale structure.
  • What did NOT change (scope boundary): no UI logic, routing, or hardcoded component strings outside the locale file.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #
  • Related #
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: the pt-BR locale had fallen behind ui/src/i18n/locales/en.ts as new UI sections and keys were added.
  • Missing detection / guardrail: no parity check currently prevents the locale file from drifting behind the English source.
  • Contributing context (if known): locale support already exists, but this translation file was incomplete.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file:
    • ui/src/i18n/locales/pt-BR.ts
  • Scenario the test should lock in:
    • pt-BR locale stays aligned with the currently translated Control UI surfaces.
  • Why this is the smallest reliable guardrail:
    • this change is translation-only and does not alter UI behavior.
  • Existing test that already covers this (if any):
    • build-time locale loading through the UI bundle.
  • If no new test is added, why not:
    • pnpm --dir ui build passed locally; the available browser test run was blocked by missing Playwright browser binaries in the local environment, not by a locale/runtime failure.

User-visible / Behavior Changes

  • More of the Control UI now renders in Brazilian Portuguese instead of falling back to English.

Diagram (if applicable)

N/A

Security Impact (required)

  • New permissions/capabilities? (Yes/No): No
  • Secrets/tokens handling changed? (Yes/No): No
  • New/changed network calls? (Yes/No): No
  • Command/tool execution surface changed? (Yes/No): No
  • Data access scope changed? (Yes/No): No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: Windows 10
  • Runtime/container: local Node/pnpm dev environment
  • Model/provider: N/A
  • Integration/channel (if any): Control UI web locale
  • Relevant config (redacted): N/A

Steps

  1. Switch the Control UI language to pt-BR.
  2. Navigate through translated Control UI surfaces.
  3. Compare rendered labels against the existing English locale structure.

Expected

  • Existing translated surfaces render in Brazilian Portuguese rather than falling back to English.

Actual

  • pt-BR now covers the translated usage and cron sections plus missing shared labels.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Build validation:

pnpm --dir ui build
✓ built in 2.65s

Human Verification (required)

  • Verified scenarios:
    • reviewed the locale diff against ui/src/i18n/locales/en.ts
    • validated the UI bundle builds successfully with the updated pt-BR locale
  • Edge cases checked:
    • preserved placeholders like {count}, {time}, {zone}, {rel}
    • kept the exported locale shape aligned with TranslationMap
  • What you did not verify:
    • full browser-driven UI walkthrough, because local Playwright browser binaries were not installed in this environment

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No): Yes
  • Config/env changes? (Yes/No): No
  • Migration needed? (Yes/No): No
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk: some Control UI strings are still hardcoded outside locale files, so the UI may remain partially untranslated.
    • Mitigation: this PR is intentionally scoped to the existing pt-BR.ts locale surface only.

@greptile-apps

greptile-apps Bot commented Apr 4, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR completes the Brazilian Portuguese (pt-BR) locale for the Control UI by filling in the previously missing usage.* and cron.* translation sub-trees, adding three new keys (common.theme, tabs.dreams, subtitles.dreams), and refining several existing translations for fluency.

The updated ui/src/i18n/locales/pt-BR.ts now mirrors the structure of en.ts exactly — both files are 614 lines with identical top-level keys and nested sub-sections. All interpolation placeholders ({count}, {time}, {zone}, {rel}, {command}, {url}, {config}, {title}, {shown}, {total}, {start}, {end}) are preserved across translated strings.

Notable highlights:

  • The cron.form.timezonePlaceholder is sensibly localized from "America/Los_Angeles" to "America/Sao_Paulo", which is a helpful UX choice for Brazilian users.
  • Portuguese grammatical gender is handled correctly — cron.jobList.enabled: "ativada" uses the feminine form to agree with tarefa (task).
  • Technical terms (gateway, webhook, cron, token, snapshot, heartbeat) are kept in English, which is standard practice for technical UIs in pt-BR.
  • The change is purely additive/corrective on the locale layer; no UI logic, routing, or component behavior is affected.

Confidence Score: 4/5

Safe to merge — translation-only change with no logic, routing, or API surface impact.

The PR is strictly additive on a single locale file. The pt-BR structure now fully matches en.ts (same 614 lines, identical key hierarchy). All interpolation placeholders are preserved, and the TypeScript type constraint (TranslationMap) means the build would fail on any key mismatch. The author confirmed pnpm --dir ui build passes. Score is 4 rather than 5 only because translation quality cannot be machine-verified with certainty, and the PR notes that a full browser-driven UI walkthrough was not performed.

No files require special attention.

Reviews (1): Last reviewed commit: "UI: complete pt-BR control locale" | Re-trigger Greptile

@rubensfox20

Copy link
Copy Markdown
Contributor Author

Validated locally after opening the PR:\n\n- pnpm check ✅\n- pnpm build ✅\n- pnpm test ui/src/i18n/test/translate.test.ts -- --project ui ✅\n\nThe change remains scoped to ui/src/i18n/locales/pt-BR.ts only. If any CI lane reports a translation-specific failure, I can follow up with a targeted fix.

@steipete

Copy link
Copy Markdown
Contributor

Closing this as implemented after Codex review.

Current main already contains the completed generated pt-BR Control UI locale, including the theme/dreams keys and the full usage and cron trees this PR was adding, and the same implementation was already shipped in v2026.4.23.

What I checked:

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review notes: reviewed against 59523e66da03; fix evidence: release v2026.4.23, commit a9797214338b.

@steipete steipete closed this Apr 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants