Add Portuguese language support to Vibe-Kanban

[pedrotecinf]

Note

Low Risk
Mostly additive i18n changes (new locale bundles and language mappings) with minimal impact beyond language selection and fallback behavior.

Overview
Adds Portuguese as a supported UI language end-to-end.

Updates the config schema (UiLanguage in v6) and the web i18n setup to recognize pt, load Portuguese translation resources, and map regional browser locales (pt-BR, pt-PT) back to pt via fallbacks and supportedLngs.

^{Reviewed by Cursor Bugbot for commit 7fd9281. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pedrotecinf]

"Correções aplicadas conforme sugestão do bot: filterDialogDescription, remove-parent-issue e run-archive-script foram ajustadas para português correto."

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is kicking off a free cloud agent to fix this issue. This run is complimentary, but you can enable autofix for all future PRs in the Cursor dashboard.}

[Juanlucasbg]

Aggressive review summary — PR #3096

1833-line addition of Portuguese (pt) language support across 8 locale files. Verdict: maintainer policy decision — recommend bundle into a "language packs" decision with #3212 (Russian), #3288 (Hebrew), #2785 / #2434 (Turkish), and any other queued locale PRs.

Why this is a policy decision, not a code-quality decision

The 1833-line diff is almost entirely translation values in JSON: "setting.title": "Configurações" and similar. Reviewing the translation quality requires native Portuguese speakers, which automated review can't substitute for. Mechanically the file structure mirrors en/common.json, en/tasks.json, etc. — if all 8 namespace files cover the same key set as English, the integration is correct.

Sunsetting context

The repo's README banner states the product is winding down. A new locale costs translator effort and signals long-term support to that language community. The maintainer faces three options for this PR plus the queued language-pack PRs (#3212 Russian, #3288 Hebrew, #2785 / #2434 Turkish, possibly more):

1. Close all language-pack PRs: Sunset means no new locales. Announce on README.
2. Merge all queued language packs in one batch: Goodwill to contributors who already did the work; users on those languages get a usable product through the wind-down. Risks setting an expectation that more will be accepted.
3. Merge selectively: Pick the highest-quality / highest-coverage submissions. Most contentious — implies subjective judgment about which contributors to favor.

The shape of this PR (purely additive, no runtime impact, no new dep) means option 2 is operationally cheap.

Findings (technical)

• Structural — PASS (assuming key parity): If pt JSON files cover every key in en files, the i18n system falls back to en for missing keys gracefully. Drift = visual fallback, not crash.
• Adversarial — LOW: The risk is bad translations, not broken code. A native-speaker review by the maintainer (or outsourced) is the real quality gate.
• Security: N/A.
• Conventions — PASS: Locale dir / file naming matches the existing en, es, fr, ja, ko, zh-Hans, zh-Hant set.

Verdict

Defer — bundle this PR with the other queued language packs (#3212, #3288, #2785, #2434) for a single batched decision. If the maintainer accepts language packs in the sunset window, merge. If not, close all in one statement.

— Reviewed by automated single-pass review (i18n batch policy decision; technical review skipped because translation quality is the dominant concern and requires human review).