Interest in i18n/localization support (starting with German)?

[unLieb]

Hi, thanks for adsb-3d — really nice project.

I'd like to translate the UI (starting with German), and wanted to check
in before putting time into it.

From a quick look at the frontend, there's currently no i18n layer —
strings are inline (textContent = '...', setAttribute('aria-label', ...))
across the ui/*.ts files and main.ts. The SETTINGS_SCHEMA in
ui/settings-panel.ts already centralizes its labels/descriptions, which
would translate cleanly, but the rest is scattered.

Before I start, I'd like your take on:

1. Is localization something you'd want in the project at all, or would
   you rather keep it out of scope?
2. If yes — preference on approach? E.g. a small custom string-table
   (strings.ts with per-locale dictionaries + a t() helper) vs. pulling
   in a library like i18next. Given the "no framework, DOM + Three.js
   directly" style described in CLAUDE.md, I'd lean toward the lightweight
   custom approach, but wanted to check first.
3. Any preference on how the language is selected — browser locale
   auto-detect, a setting in the existing settings panel, or a URL param?

Happy to do the string extraction + a German translation as a first PR
if this fits, or to hold off if it doesn't add value for you.

[hook-365]

Hi, thanks for the thoughtful writeup, and sorry for the slow reply. Localization is absolutely in scope, and your read of the codebase was spot on.

To your three questions:

1. Yes, definitely wanted.
2. Lightweight custom, exactly as you suggested. i18next would be the only runtime dependency in the whole frontend and we don't need what it charges for. The implementation follows the subscribe-singleton pattern the rest of core/ uses.
3. A setting in the settings panel, defaulting to auto (resolves navigator.language, falls back to English). Changing it reloads the page, which keeps every panel honest for the cost of one reload on a setting people touch about once.

Since you offered to start with the extraction, fair warning: I went ahead and did that part on the feat/i18n branch, because it touched nearly every file under ui/ and I wanted to set the key conventions in one pass rather than review them across a long PR. What's there now:

• core/i18n.ts with a t() helper, {param} interpolation, and English fallback
• 272 keys extracted into per-namespace tables under core/strings/en/
• static index.html markup translated via data-i18n attributes at boot
• a drift test (tests-unit/i18n.test.ts) that fails if any locale is missing a key, has an extra one, or mismatches a {placeholder}, so translations can't silently rot
• complete machine-drafted de/ and es/ tables, clearly marked as drafts

Which brings me to the ask: rather than translating from scratch, would you be up for reviewing and correcting the German draft in core/strings/de/? You'd be the first native speaker to see it, and I'd credit you as the German localization author. Things I'd particularly value a native eye on: the terse VR wrist-menu strings in de/misc.ts (they draw on a small canvas and must stay short), whether the aviation vocabulary reads naturally (Steigrate, Rufzeichen, etc.), and any layout overflow you spot, since German runs longer than English and some panels are tight.

The "Adding a locale" recipe is documented in CLAUDE.md if you'd rather also bring up another language later. Thanks again for asking before diving in, and for the nudge to finally do this properly.

[hook-365]

Also, if you have any other ideas, feel free to just submit as a pull request without asking!

[hook-365]

Quick update: the i18n work described above is merged to master now (the feat/i18n branch is gone), so the German tables to review live at frontend/src/core/strings/de/ on master. Everything else in the comment above still applies.