Player UI chrome is hardcoded Turkish regardless of course language

[kemalyy]

Bug

The runtime player UI chrome (button labels, ARIA labels, review-panel strings) is hardcoded in
Turkish in components/renderer.py and components/templates.py, regardless of the course's
language field. For example, an English-language course ("language": "en") still renders a
"Kontrol Et" (Check) button and a "Geri bildirim" (Feedback) panel label.

Found while generating a screenshot for the README from examples/small.en.json — the quiz
screen content was in English but the "Check" button said "Kontrol Et".

Where

components/renderer.py:1085  btn-check ap-check → "Kontrol Et"
components/renderer.py:1111  btn-check → "Kontrol Et"
components/templates.py:57   review-btn → "Geri bildirim"
components/templates.py:58   review-panel aria-label → "Geri bildirim"

And more — search for non-ASCII (Turkish-diacritic) string literals across components/renderer.py
and components/templates.py, e.g. "Önceki", "Baştan oynat", "Sesi aç / kapat", "Altyazı",
"Bölüm menüsü", "İlerleme", "Kartı çevir", "Eşleştir", "Cevabını yaz", "Yukarı taşı",
"Aşağı taşı", "Tamamlandı", and the game-engine/adaptive-practice status strings in
components/templates.py (~1000-1950 range).

Suggested approach

1. Collect the hardcoded UI-chrome strings into a small lookup table keyed by string id, e.g.
   UI_STRINGS = {"en": {...}, "tr": {...}} (module-level dict, no external i18n lib needed —
   this project avoids heavy deps).
2. Add an English set first (this is the highest-value gap — English is the fallback/default
   for most SCORM authoring elsewhere in the codebase).
3. Wire the renderer/templates functions that currently emit literal Turkish strings to look up
   the course's language field (falls back to "tr" if the language isn't in the table, to
   preserve current behavior for existing courses).
4. Add a test asserting an "en"-language course's rendered HTML does not contain the Turkish
   strings (e.g. assert "Kontrol Et" not in html when language == "en").

Keep it additive: don't change the default (tr) behavior for existing Turkish-language courses.

Why this matters

The project targets a global audience (README is translated into 8 languages) — but the actual
rendered course UI silently reverts to Turkish for every course regardless of author intent. This
is the single most visible language-consistency issue in the runtime.

Good first issue: no architectural decisions needed, mechanical string extraction + one new
language table, existing test patterns to follow in tests/test_units.py.

[Pakvothe]

Hardcoded chrome strings are the classic first-i18n moment, the course content is multilingual but the player itself only speaks one language.

Since you're already running MCP: I built i1n (i1n.ai), a localization pipeline that's also an MCP server (it's in the official registry). Externalize the player strings to a locale JSON once, then i1n push --translate AI-translates to any language your courses ship in, with a CI check so nothing drifts. Given you already work agent-first, you could literally tell your agent "internationalize the player chrome" and let the MCP tools do the extraction. Free tier. Happy to answer setup questions here.

[kemalyy]

Thanks for flagging the MCP angle — appreciate you thinking about the workflow.
For this fix I'll go with the approach already in the issue: a static UI_STRINGS = {"en": {...}, "tr": {...}} dict, no external dependency. It's a fixed, finite set of ~20-30 chrome strings, not ongoing content that needs a translation pipeline, so this stays dependency-free by design for this project.
Thanks again for the offer — I'll close this one out with the approach above.