Interface localization (i18n) with a first pt-BR translation

[allisonbrl]

Summary

The V2 interface has its user-facing strings hardcoded in English. I'd like to add localization support to @sd/interface and contribute a Brazilian Portuguese (pt-BR) translation as the first locale. The work is done on a branch in my fork, and I'd like to agree on the approach before opening a PR:

https://github.com/allisonbrl/spacedrive/tree/feat/pt-br-translation

What the branch does

Core (Rust): config.app.update only accepts 2-letter ISO 639-1 codes, so pt-BR is rejected today. The change also accepts language-REGION tags (en, pt-BR, zh-CN) and still rejects malformed input such as pt_BR or pt-BRA, with a unit test. The comment on Preferences.language now says BCP 47.

Interface (TypeScript): an I18nProvider in packages/interface/src/i18n/. It is about 225 lines and adds no dependencies.

• t(key, variables) is typed against the keys of en.json, so a misspelled static key fails tsc. Keys built at runtime (content kinds, volume types, keybinds) go through translateOr(t, key, fallback), which checks the key and falls back to the raw value. No new any casts are added. The only as any in the diff is an existing line in MediaView.tsx that prettier reformatted.
• {{variable}} interpolation, and plural keys (_one / _other) chosen with Intl.PluralRules.
• Locale-aware formatDate, formatTime, formatDateTime, formatNumber and formatBytes, built on Intl. formatBytes replaces seven duplicated helpers in the overview, analyzer, redundancy and file copy views.
• Missing keys fall back to English.
• The provider listens for ConfigChanged, so a language change applies without restarting the app.

Locales: en.json and pt-BR.json, 1,541 keys each. A bun test suite (src/i18n/locales.test.ts) fails if a locale is missing a key, has an extra key, has an empty value, or changes a {{placeholder}}, so new English strings can't go untranslated without anyone noticing.

Why not i18next?

V1 used i18next. For V2 I chose a provider with no dependencies because the needs are small: flat keys, interpolation, two plural forms and Intl formatting. Typed keys also come for free from the JSON import. If you'd rather keep the V1 stack, I'm happy to switch to i18next / react-i18next.

What is not translated

• Text produced by the daemon: validation findings, operation errors, job names sent from Rust. These reach the UI as finished English sentences, so translating them needs a backend change (for example, returning codes plus parameters). That is out of scope here.
• The native macOS menu bar built in apps/tauri (File, Edit, View, …).
• Prototype placeholder content: the sample chat and activity in the file inspector, and the sample conversations in the Knowledge view.
• Data and names: library, folder, device and file system names. Language names in the picker stay in their own language on purpose.

How it was tested

• bun test src passes (47 tests), and tsc -b reports no new errors.
• The config.app.update unit test passes.
• I ran sd-server with the web UI and switched between en and pt-BR through config.app.update (the same call the Appearance setting makes). I checked the sidebar, Home, Activity, Trash, the file context menu and the volume cards in both languages, and the switch applied without a reload.
• Not tested: the Tauri desktop app. I couldn't build it locally on macOS 27 with Swift 6.4. swift-rs 1.0.7 looks for the static library under arm64-apple-macosx/release, but the new Swift build system writes it to out/Products/Release. This is unrelated to this change, but it means the desktop-only windows haven't been checked on screen.

Things a reviewer should know

• Large diff: 139 files and about 7.7k changed lines, mostly mechanical string extraction. About 19% of the changed TypeScript lines are formatting only, because the touched files were run through the repo's own .prettierrc (single quotes, no bracket spacing). I can strip that formatting if you'd rather review only the semantic changes.
• English output changes slightly: byte sizes now get a thousands separator (1,000.0 GB instead of 1000.0 GB), and sizes under 1 KB show no decimal (512 B). The volume type badge shows User Data instead of UserData.
• AI assistance: I wrote this with help from an AI coding assistant (Claude), which shows up as a co-author on the commits. I reviewed the changes and tested them as described above.

Questions for maintainers

1. Is a provider with no dependencies acceptable, or should this use i18next?
2. Would you prefer one PR, or a split: core and provider first, then string extraction and pt-BR?
3. Is packages/interface/src/i18n/locales/ the right home for translation files, or should they live somewhere shared with mobile?

[allisonbrl]

A follow-up on question 2, after looking at how fast the interface is moving.

Main touched 63 interface files in the last 30 days, and 26 of them are files this branch also changes. A single 139-file PR would keep conflicting with your work, and the original parity test would have made every new English string wait on a Portuguese translation. That's a cost you shouldn't have to carry.

So I'd suggest splitting it:

1. Mechanism first, small: the config.app.update tag validation, the I18nProvider with typed keys and translateOr, the Intl formatting helpers, docs/react/ui/i18n.mdx, and pt-BR.json. I've already relaxed the locale test (pushed to the branch). It still fails on extra keys, empty values and changed {{placeholders}}, but a key missing from a translation now just falls back to English. Adding an English string never needs a translation in the same PR.
2. String extraction later, by area: context menus, settings, explorer and so on, as separate small PRs, timed around your own work on those screens.

If you'd rather take the full extraction in one go, the branch already has it. Just let me know which shape works for you.