feat(i18n): add Brazilian Portuguese (pt-BR) locale

[DavidgFernandes]

Summary

• Adds full Brazilian Portuguese translation (820/820 UI strings) as a third supported locale next to en and zh-CN.
• Auto-detects pt-* system locales; users can also switch manually from the topbar toggle or Settings → Appearance → Language.
• Default locale (DEFAULT_LOCALE) stays en; no behavior change for existing users.

What's inside

• packages/i18n/src/locales/pt-BR.json — 820 UI strings, full parity with en.json
• packages/templates/src/locales/pt-BR.ts — 4 built-in demos (title, description, prompt)
• packages/templates/src/examples/locales/pt-BR.ts — 21 hub examples (title, description)
• packages/i18n/src/index.ts — register pt-BR in availableLocales, resources, normalizeLocale (accepts pt, pt-BR, pt_br, pt-*)
• Templates registries pointed to the new pt-BR files (no en fallback)
• Settings.tsx dropdown + LanguageToggle.tsx cycle now include pt-BR
• langPtBR label added to en.json and zh-CN.json so the dropdown works across all locales

Translation quality notes

• Terminology glossary applied consistently (tweaks → Ajustes, design system → design system, snapshot → snapshot, etc.)
• {{interpolations}} and _one/_other plural suffixes preserved
• 32 strings kept identical to EN (product names, file paths, unit suffixes, tech jargon) — no mistranslations
• Reviewed end-to-end for tone, grammar, and accuracy (standardized novamente, fixed redacted → redigido bug, Nota fiscal → Fatura for semantic accuracy, etc.)

Test plan

• `pnpm lint && pnpm typecheck && pnpm test` all pass locally (pre-push hook confirms)
• App boots with zero `missing translation` / `unsupported locale` warnings
• Settings → Appearance → Language shows `Português (BR)`; selection persists across restart
• Topbar globe toggle cycles `EN → ZH → PT → EN`
• System locale `pt-BR` auto-selects pt-BR on first launch
• Hub Examples gallery and built-in demos render in PT
• No UI clipping from longer PT strings (sidebar, settings, onboarding)

[github-actions]

Findings

• [Major] pt-BR locale is incomplete after being added as a selectable/apply-able locale, causing raw i18n keys to surface in provider-import/save-error UI paths instead of user-facing text. Evidence: packages/i18n/src/index.ts:22 enables pt-BR, keys are consumed at apps/desktop/src/renderer/src/components/Settings.tsx:1027, apps/desktop/src/renderer/src/components/Settings.tsx:1032, apps/desktop/src/renderer/src/components/Settings.tsx:2234, apps/desktop/src/renderer/src/components/Settings.tsx:2235, but missing in packages/i18n/src/locales/pt-BR.json:223 and packages/i18n/src/locales/pt-BR.json:285.
  Suggested fix:

  {
    "settings": {
      "providers": {
        "import": {
          "ollamaMenu": "Ollama (local)",
          "ollamaMenuDesc": "Adicionar provedor local localhost:11434",
          "ollamaDone": "Provedor Ollama adicionado"
        },
        "toast": {
          "saveFailed": "Não foi possível salvar as alterações"
        }
      }
    }
  }

Questions

• None.

Summary

• Review mode: initial
• 1 issue found (major): incomplete pt-BR keyset introduces visible i18n regressions in changed locale behavior.
• docs/VISION.md and docs/PRINCIPLES.md: Not found in repo/docs in this checkout.

Testing

• Not run (automation). Suggested: add a Vitest parity check asserting pt-BR contains all keys from en, and a renderer test for provider import menu/toast strings under pt-BR.

open-codesign Bot

[github-actions]

[Major] Missing pt-BR keys used by Settings provider flows: settings.providers.import.ollamaMenu, settings.providers.import.ollamaMenuDesc, settings.providers.import.ollamaDone, and settings.providers.toast.saveFailed.

These keys are now reachable because pt-BR is enabled globally; missing keys will render fallback key text in UI.

Suggested fix:

"import": {
  "ollamaMenu": "Ollama (local)",
  "ollamaMenuDesc": "Adicionar provedor local localhost:11434",
  "ollamaDone": "Provedor Ollama adicionado"
},
"toast": {
  "saveFailed": "Não foi possível salvar as alterações"
}

[Sun-sunshine06]

Hey @DavidgFernandes! Thanks for this great work adding Brazilian Portuguese locale 🇧🇷

I've fixed the failing DCO check by adding to all commits (rebase done while preserving your original authorship for every commit). The DCO check should pass now.

Review:

This is a really high-quality contribution:

• ✅ Full 820/820 UI strings translated
• ✅ Correct locale normalization for , , , all handled properly
• ✅ All template/examples translations are included and correctly registered in the registries
• ✅ Language toggle cycle updated correctly
• ✅ Language label added to all existing locale files so it shows up properly in the dropdown regardless of current language
• ✅ Your translation quality notes show great attention to detail — consistent terminology, preserved interpolations/plurals, kept technical terms in English where appropriate
• ✅ All existing CI checks (lint/typecheck/test) pass

Everything looks ready to go! Welcome to the project contributor list 🎉

[Sun-sunshine06]

Hey @DavidgFernandes! Thanks for this great work adding Brazilian Portuguese locale 🇧🇷

I've fixed the failing DCO check by adding Signed-off-by to all commits (rebase done while preserving your original authorship for every commit). The DCO check should pass now.

Review:

This is a really high-quality contribution:

• ✅ Full 820/820 UI strings translated
• ✅ Correct locale normalization for pt, pt-BR, pt_br, pt-* all handled properly
• ✅ All template/examples translations are included and correctly registered in the registries
• ✅ Language toggle cycle updated correctly
• ✅ Language label added to all existing locale files so it shows up properly in the dropdown regardless of current language
• ✅ Your translation quality notes show great attention to detail — consistent terminology, preserved interpolations/plurals, kept technical terms in English where appropriate
• ✅ All existing CI checks (lint/typecheck/test) pass

Everything looks ready to go! Welcome to the project contributor list 🎉

[github-actions]

Findings

• [Major] Auto-discovery can apply stale results from an older request after the user has already changed baseUrl / apiKey / wire, which can populate the dropdown with wrong models and auto-select the wrong default model. Evidence: apps/desktop/src/renderer/src/components/AddCustomProviderModal.tsx:123, apps/desktop/src/renderer/src/components/AddCustomProviderModal.tsx:127, apps/desktop/src/renderer/src/components/AddCustomProviderModal.tsx:133.
  Suggested fix:

  const discoveryReqId = useRef(0);
  
  async function runDiscovery(currentBaseUrl: string, currentApiKey: string, currentWire: WireApi) {
    if (!window.codesign?.config) return;
    const reqId = ++discoveryReqId.current;
    setDiscovery({ kind: 'discovering' });
    try {
      const res = await window.codesign.config.testEndpoint({
        wire: currentWire,
        baseUrl: currentBaseUrl.trim(),
        apiKey: currentApiKey.trim(),
      });
      if (reqId !== discoveryReqId.current) return; // ignore stale response
      if (res.ok && res.models.length > 0) {
        setDiscovery({ kind: 'found', models: res.models });
        if (!userPickedModel.current) setDefaultModel(pickBestModel(res.models));
      } else {
        setDiscovery({ kind: 'failed' });
      }
    } catch {
      if (reqId === discoveryReqId.current) setDiscovery({ kind: 'failed' });
    }
  }

Questions

• None.

Summary

• Review mode: follow-up after new commits
• 1 issue found (major): async discovery race can surface stale model lists/defaults in the custom provider modal.
• docs/VISION.md and docs/PRINCIPLES.md: Not found in repo/docs.

Testing

• Not run (automation). Suggested: add a Vitest/RTL test that simulates two overlapping discovery calls and asserts only the latest response updates discovery and defaultModel.

open-codesign Bot

[github-actions]

[Major] This async discovery path has no stale-response guard. If request A starts, user edits endpoint, then request B starts and finishes first, request A can still finish later and overwrite discovery/defaultModel with outdated models.

Suggested fix:

const discoveryReqId = useRef(0);

async function runDiscovery(currentBaseUrl: string, currentApiKey: string, currentWire: WireApi) {
  const reqId = ++discoveryReqId.current;
  // ... fetch
  if (reqId !== discoveryReqId.current) return;
  // apply state
}

[DavidgFernandes]

Thanks for the quick review and the DCO fix, @Sun-sunshine06! Really appreciate the welcome 🙏

One small thing to flag: I had pushed a 6th commit translating the 4 new Ollama strings from upstream #170 (ollamaMenu, ollamaMenuDesc, ollamaDone, saveFailed), but it looks like our two rebases overlapped and my commit got dropped when you force-pushed the DCO fix.

I'll re-push that commit now on top of your work, with Signed-off-by this time so DCO stays green. No changes to any of your existing signed commits.

[github-actions]

Findings

• None.

Summary

• Review mode: follow-up after new commits
• No new issues found in the current diff.
• docs/VISION.md and docs/PRINCIPLES.md: Not found in repo/docs.

Testing

• Not run (automation). Residual risk: no added Vitest/Playwright coverage for pt-BR locale selection/cycling and localized templates/examples rendering paths.

open-codesign Bot