vibed internationalisation take 1

[jarjk]

based on #26, will need to rebase

experimenting with #7

TODO: backend is shitty, if something's not returned to the client, it should be set via env-var (runtime probably)

frontend doesn't exist yet...

keep in mind: dioxus-community/dioxus-i18n#28

created roughly like this, with codex-cli

---

Apollo I18n Integration with dioxus-i18n v0.5.1

Summary

Implement end-to-end internationalization (backend responses + frontend UI) using dioxus-i18n 0.5.1, migrate assets/translations.yml into Fluent (.ftl)
files, and make Fluent the single source of truth.
Locale selection will use Accept-Language for API responses, and the UI will support auto-detection plus an EN/HU switcher.

Implementation Changes

1. Dependencies and assets

• Add dioxus-i18n = "0.5.1" to Cargo.toml.
• Replace assets/translations.yml with Fluent files:
  • assets/i18n/en-US.ftl
  • assets/i18n/hu-HU.ftl
• Remove assets/translations.yml.

2. Translation catalog migration and cleanup

• Port all existing YAML entries into Fluent messages/terms, preserving placeholders.
• Reconcile drift between YAML and source code by aligning with actual strings currently used in:
  • src/backend/endpoints.rs
  • src/backend/logic.rs
  • src/app.rs
• Add missing keys found in source (currently hardcoded but absent from YAML), including admin-password state errors, state-path warnings, “no progress
  bound to team”, and current landing-page text.
• Normalize obvious typos during migration (e.g. malformed English text in YAML) so Fluent content is production-ready.

3. Backend i18n wiring

• Introduce a backend localization helper module (e.g. src/backend/i18n.rs) that:
  • Parses Accept-Language from HeaderMap.
  • Resolves to supported locales (hu-HU, en-US) with fallback to hu-HU.
  • Creates request-scoped dioxus_i18n::prelude::I18n using embedded Fluent strings (include_str!).
  • Exposes helpers for translating keys with/without args.
• Update server functions in src/backend/endpoints.rs to accept headers: HeaderMap extractor alongside existing cookie extractors and replace hardcoded
  response/error strings with translation keys.
• Update src/backend/logic.rs string-producing error/log paths to use the same translation helpers (defaulting to fallback locale when no request headers
  are available).

4. Frontend i18n wiring

• Initialize i18n provider in App with use_init_i18n and both locale files (static include_str!).
• Add a lightweight language toggle (EN/HU) in the current page UI.
• Apply translation macros (t!) to visible UI strings in src/app.rs.
• Auto-detect locale on web client startup (browser language) and switch if supported; keep fallback hu-HU.

Test Plan

• Static verification:
  • dx check
  • cargo check --all-targets
• Functional checks:
  • UI renders translated strings and language switch toggles text immediately.
  • API endpoints return localized messages according to Accept-Language (e.g. en-US vs hu-HU) for success and error paths.
  • Unsupported/missing Accept-Language falls back to hu-HU.
• Regression checks:
  • Existing auth/join/logout/submit flows still behave identically except localized message text.

Assumptions and Defaults

• Fluent extension is standard .ftl (not .flt).
• Supported locales in this implementation are exactly hu-HU and en-US.
• assets/translations.yml is removed after migration to prevent dual-source drift.
• Fallback/default locale is hu-HU.