i18n: add language selector and locale support for the UI

[juliobrasa]

Problem

Paperclip UI is English-only. For teams operating in other languages, this creates friction — our team works in Spanish, and we ended up patching error messages, labels, and UI strings manually to feel at home. Those patches break on every upgrade.

This is not just about comfort. When agents post comments with status updates, and the board UI shows labels like "in_progress", "blocked", "done" — the human operators need to read these quickly. In a non-English team, localized labels reduce cognitive load.

Proposal

Add i18n support with a language selector in Instance Settings or user profile.

Suggested approach

1. Extract UI strings into a locale file structure (e.g., ui/src/locales/en.json, es.json, fr.json, etc.)
2. Use a lightweight i18n library — React already has well-established options like react-i18next or react-intl
3. Language selector in user profile settings (per-user preference) with instance-level default
4. Server-side messages — API error messages and agent-facing strings could stay in English (agents work fine in English), but board-facing UI should be translatable
5. Community translations — once the string extraction is done, the community can contribute locale files without touching core code

Scope suggestion (incremental)

• Phase 1: Extract all hardcoded UI strings to en.json + add react-i18next. No new languages yet, but the infrastructure is in place.
• Phase 2: Add 2-3 initial languages (Spanish, French, Portuguese — large developer communities). Community can contribute more.
• Phase 3: Server-side error messages + agent-facing strings (lower priority since agents handle English fine).

Why this matters for adoption

Paperclip targets "zero-human companies" — but the humans who set them up and supervise them speak 7,000+ languages. The control plane should meet them where they are.

We run a 14-agent deployment in production and would be happy to contribute the Spanish locale as a starting point.

Alternatives considered

• Browser auto-translate: Works poorly with technical UIs, breaks interactive elements, and doesn't handle dynamic content.
• Per-team fork with translations: What we did — it's painful and breaks on every upgrade.
• English only: Limits adoption outside English-speaking markets.

[miwifiqwer]

Cool

[beatther]

Good

[jvkabum]

#6237
eat(ui): stabilize native pt-BR i18n integration and resolve typescript build errors
#6237