docs(09): capture phase context

Phase 09: Internationalization
- Implementation decisions documented
- Phase boundary established

.planning/phases/09-i18n/09-CONTEXT.md

@@ -0,0 +1,71 @@
+# Phase 9: Internationalization - Context
+
+**Gathered:** 2026-02-06
+**Status:** Ready for planning
+
+<domain>
+## Phase Boundary
+
+Wrap all user-facing strings in gettext functions, create .pot/.po/.mo translation files, load text domain, provide German and English translations. Covers PHP strings, JavaScript messages, admin settings, form UI, validation messages, and furniture/room data arrays. Email content is explicitly excluded from translation — it always stays in German.
+
+</domain>
+
+<decisions>
+## Implementation Decisions
+
+### Default language
+- English is the source language in code (WordPress convention)
+- English strings are direct translations of the existing German text
+- German .po/.mo files ship with the plugin
+- Fallback behavior: when locale is not English and no translation exists, fall back to German (not English)
+- Plugin follows WordPress site locale automatically — no separate plugin language setting
+
+### String scope
+- All PHP user-facing strings wrapped in gettext (`__()`, `_e()`, `esc_html__()`, etc.)
+- JavaScript validation messages translated via `wp_localize_script()`
+- Admin settings page strings translated
+- Success/error messages after form submission translated
+- Email content (HTML table body, subject line) always in German — never translated
+- Email generation must force German strings regardless of current site locale
+
+### Translation workflow
+- Text domain: `siegel-umzugsliste`
+- Translation files live in `languages/` folder within plugin root
+- Ship a .pot template file for Loco Translate compatibility
+- Loco Translate is the intended translation management tool
+- Standard naming: `siegel-umzugsliste-de_DE.po`, `siegel-umzugsliste-de_DE.mo`
+
+### Furniture data handling
+- Room names and furniture items in PHP data arrays wrapped in `__()` gettext calls
+- Additional work section labels and field names also wrapped in gettext
+- Email always uses original German furniture/room names, not translated versions
+- Need a mechanism to force German locale when generating email content (e.g., temporarily switch locale or use a separate untranslated lookup)
+
+### Claude's Discretion
+- Whether to ship pre-made German .po/.mo files or only the .pot template (leaning toward shipping both for out-of-box German support)
+- Exact approach for forcing German in email generation (locale switching vs. maintaining separate German string map)
+- How to handle gettext extraction for strings in data arrays (inline `__()` vs. separate string registration)
+- JavaScript localization structure and variable naming
+
+</decisions>
+
+<specifics>
+## Specific Ideas
+
+- Loco Translate is the preferred translation management plugin — .pot file must be compatible with its discovery mechanism
+- German fallback is critical: this is a German moving company tool, so German should always be available even for unsupported locales
+- Email format is sacred — the "always German" email rule preserves the legacy workflow that office staff depend on
+
+</specifics>
+
+<deferred>
+## Deferred Ideas
+
+None — discussion stayed within phase scope
+
+</deferred>
+
+---
+
+*Phase: 09-i18n*
+*Context gathered: 2026-02-06*