Internationalisation scaffolding: German and English #51

Open
opened 2026-08-31 17:25:16 +02:00 by robert · 0 comments
robert commented 2026-08-31 17:25:16 +02:00 (Migrated from git.butzei.de)

Goal

Ship German and English from the start. Retrofitting i18n touches every file that renders text, so the scaffolding belongs in Phase 1 before there are many strings.

Acceptance criteria

  • Companion strings in values/strings.xml with a complete values-de/strings.xml
  • No hard-coded user-visible strings in Kotlin - enforced by a lint rule
  • Watchapp string table in src/c/i18n.h, since C has no resource system
  • Locale read from the phone and pushed to the watch, so both sides agree
  • Number and date formatting locale-aware, including the decimal separator
  • Units independent of language: a German UI with imperial units must work
  • Both languages checked for text overflow in the 200x228 layouts - German strings run long

Files

  • companion/src/main/res/values/strings.xml
  • companion/src/main/res/values-de/strings.xml
  • watchapp/src/c/i18n.h

Notes

Street names come from OpenStreetMap and stay in the local language regardless of UI setting - that is correct, not a bug. See docs/DECISIONS.md D17.

Update — 2026-09-01: moved to Phase 1b

Phase 1 had grown to twelve issues of framework before the first useful ride. Internationalisation
moves to Phase 1b — Generalise the display, with HERO1, GRID6 and round support (D32).

Nothing is cancelled and the reasoning in D17 stands: retrofitting i18n is tedious and touches every
file that renders text. The mitigation is that Phase 1 ships only three default pages with a handful
of labels, so the retrofit is small and bounded — and label overflow in German is far easier to design
against once there are real layouts to overflow.

  • Phase 1 labels kept in one table from the start, even before the i18n machinery exists, so this
    issue is a mechanical change rather than a hunt
## Goal Ship German and English from the start. Retrofitting i18n touches every file that renders text, so the scaffolding belongs in Phase 1 before there are many strings. ## Acceptance criteria - [ ] Companion strings in `values/strings.xml` with a complete `values-de/strings.xml` - [ ] No hard-coded user-visible strings in Kotlin - enforced by a lint rule - [ ] Watchapp string table in `src/c/i18n.h`, since C has no resource system - [ ] Locale read from the phone and pushed to the watch, so both sides agree - [ ] Number and date formatting locale-aware, including the decimal separator - [ ] Units independent of language: a German UI with imperial units must work - [ ] Both languages checked for text overflow in the 200x228 layouts - German strings run long ## Files - `companion/src/main/res/values/strings.xml` - `companion/src/main/res/values-de/strings.xml` - `watchapp/src/c/i18n.h` ## Notes Street names come from OpenStreetMap and stay in the local language regardless of UI setting - that is correct, not a bug. See docs/DECISIONS.md D17. ## Update — 2026-09-01: moved to Phase 1b Phase 1 had grown to twelve issues of framework before the first useful ride. Internationalisation moves to **Phase 1b — Generalise the display**, with `HERO1`, `GRID6` and round support (D32). Nothing is cancelled and the reasoning in D17 stands: retrofitting i18n is tedious and touches every file that renders text. The mitigation is that Phase 1 ships only three default pages with a handful of labels, so the retrofit is small and bounded — and label overflow in German is far easier to design against once there are real layouts to overflow. - [ ] Phase 1 labels kept in one table from the start, even before the i18n machinery exists, so this issue is a mechanical change rather than a hunt
Sign in to join this conversation.
No description provided.