[tchellow]

Follow-up to #1550. That issue was closed because there was no i18n layer and no one to own a locale. This PR adds the layer, translates every page to Brazilian Portuguese (pt-BR), and I'm volunteering to maintain the pt-BR locale.

English users see no change: English stays the source text, and any missing translation falls back to it.

How it works

• No build step, no dependencies. public/i18n.js defines window.I18n, tr(text, params) and trn(count, singular, plural, params).
• The English text is the key. Developers keep writing English inline and wrap it in tr('…'). Nothing is extracted into IDs, so an English-only contributor's workflow barely changes.
• Dictionaries live in public/locales/<code>.json (flat "English": "translation"). Plural forms are { "one": …, "other": … } objects, resolved with Intl.PluralRules.
• Fallback is English, per string. A partly translated locale still works, and a string added tomorrow shows in English until someone translates it.
• Static markup uses data-i18n, data-i18n-title, data-i18n-aria-label and data-i18n-placeholder, applied when the dictionary loads. app.js waits for the dictionary (max 3 s) before the first route renders, so there is no flash of English.
• Language picker: Customizer → Display → "Language". The choice is stored per browser in localStorage["meshcore-lang"]; auto follows the browser. Changing it reloads the page.
• Markup never enters a translation. Links, <strong>, codes and node names go in through {placeholders}. Values from nodes or MQTT are escaped by the caller before they are passed in, as before.

What is deliberately not translated

Following the triage notes in #1550:

• Protocol tokens and firmware enums: ADVERT, GRP_TXT, TXT_MSG, TRACE, FLOOD, TRANSPORT_FLOOD, …
• Packet-filter syntax, field names and config keys (hashRegions, pathTrust.minHashBytesForMapping, …)
• Units and technical terms: SNR, RSSI, dBm, Hz, MIDI, BPM; on the Perf page, Go/SQLite runtime terms (Goroutines, Heap, RSS, WAL, …)
• Operator-written content: home steps, FAQ, footer links. Only the built-in defaults are translated, and only when the operator has not changed them.

Safety rails

• tests/unit/test-i18n.js (in test-all.sh) checks that every listed language has a dictionary and vice versa. For every entry it checks that the translation keeps the English key's {placeholders} and links and adds no HTML tags. It also covers language detection, the English fallback (missing entry, failed fetch, 404), plural rules, the DOM attributes and the language switch.
• node scripts/i18n-report.js pt-BR lists strings in the code with no translation and dictionary keys no longer used. pt-BR is at 2005/2005.
• English output is unchanged. Source-reading tests that looked for English literals were extended to accept the tr('…') form, not loosened. One visible difference: a counter that showed "0 hop" now reads "0 hops".
• A few places that put unescaped e.message into innerHTML are now escaped, since they were touched anyway.

Adding a language

1. Copy public/locales/pt-BR.json to public/locales/<code>.json and translate the values. Keys must stay exactly as they are.
2. Add one entry to LANGUAGES in public/i18n.js, for example { code: 'de', name: 'Deutsch' }.
3. Run node tests/unit/test-i18n.js and node scripts/i18n-report.js <code>.

The flat JSON format can be loaded directly into Weblate or Crowdin later, as suggested in #1550.

Commits

One commit per page, each with its own dictionary entries and test updates, so it can be reviewed page by page:

1. Runtime layer + pt-BR pilot (nav, home, Customizer language picker, test-i18n.js, i18n-report.js)
2. Default home texts
3. Packets
4. Map
5. Live
6. Nodes
7. Node Analytics / Reach
8. Channels
9. Tools
10. Observers (incl. observer detail, compare, MQTT panel)
11. Analytics (all 17 tabs)
12. Scope Audit
13. Perf
14. Audio Lab
15. Customizer
16. RX Coverage

Testing

• Every suite in test-all.sh passes, except test-preflight-xss-gate.js, which needs Python; my dev machine doesn't have it, so please let CI confirm that one.
• ESLint: no new warnings in any touched file.
• Browser: every page was reviewed in pt-BR and in English on a test instance fed by live MQTT data.
• Perf: tr() is a single dictionary lookup plus placeholder substitution, called while HTML strings are built. It adds no requests and no loops; the dictionary is one ~190 KB JSON (before gzip), fetched once with the usual cache buster. In English nothing is fetched at all.

Not in this PR

• Syncing the language choice across devices: the settings-sync allowlist is server-side (cmd/server/settings_allowlist.go).
• An operator-level default language in config.json.
• A lint gate that flags new untranslated literals in changed files. i18n-report.js is the basis for one; happy to add it as a follow-up if wanted.
• Note: two leaderboard column tooltips on the RX Coverage page are Dutch in the original source. They are left as they are and translated for pt-BR.

🤖 Generated with Claude Code

[efiten]

Thank you for this, and for doing the pt-BR translation itself, not only the plumbing.

We are keeping the UI English-only for now, so I am closing this PR. The reason is maintenance, not the quality of the work. Once a translation layer is in, every new feature, popup and tooltip needs a key and a translation before the language stays complete. Today the frontend changes in most merged PRs, and nobody is set up to keep a second language in step with that. A partially translated UI is harder to use than an English one.

When we closed #1550 we said we would reopen if a translator volunteered. You did, so to be clear about what changed: the blocker is the per-feature cost for every contributor, not a missing translator.

Things that would change this decision, for later:

• the frontend settles down enough that new strings are rare;
• a lint gate that fails CI on an untranslated string, plus a fallback rule everyone agrees on;
• more than one person committing to maintain a language.

Your branch stays available. If those conditions are met, it is the starting point.