[Feature Request]: Multi-language integration

[Christian-B-Koller]

Do you need to file a feature request?

• I have searched the existing feature request and this feature request is not already filed.
• I believe this is a legitimate feature request, not just a question or bug.

Feature Request Description

Multi-language integration to add the German language and change the whole UI into German, all messages and LLM prompts.
I prepared an integration of the German language on a fork of DeepTutor.
How will you handle multi-language integration in the future, is there a change on your roadmap how DeepTutor handles language integration?

Related Module

Other

Use Case

This feature would allow for a broader audience and encourage people from Germany, Austria and Switzerland to use DeepTutor.

Additional Context

No response

[takeshi-o]

+1 — same situation here, but for Japanese (ja). Adding some code-level detail that I hope is useful for the roadmap question, since it suggests the blocker is smaller than a full per-language localization effort.

There are currently two separate language resolution paths in the backend, and only one of them is multi-language ready:

Path	Behavior
deeptutor/services/prompt/language.py	✅ Already maps ja, ko, es, fr, de, ru, pt, it and emits a per-language directive
deeptutor/services/config/loader.py → parse_language()	❌ Binary zh/en; everything else falls through to return "zh"

So German is already half-supported: language_label("de") correctly returns Deutsch, but parse_language("de") returns "zh". Verified by running it directly:

parse_language('de') -> 'zh'
parse_language('ja') -> 'zh'
parse_language('fr') -> 'zh'
parse_language('en') -> 'en'

That second path feeds Quiz generation, Deep Research, Mastery Path and the prompt manager. The practical symptom is mixed-language output: my Japanese book had Japanese chapter prose but Chinese quizzes. I've filed that specific defect separately as #712.

Beyond that, Book overview/scaffolding strings are written as binary if zh else branches rather than i18n lookups — around 17 occurrences across 8 files (book/engine.py plus book/blocks/{section,callout,flash_cards,code,timeline,deep_dive}.py and book/agents/page_planner.py), e.g.:

overview_title = "本书导览" if book.language == "zh" else "How to read this book"

For any third language these silently render in English even when everything else is localized.

Re: the roadmap question — one thing worth flagging is that #33 (refactor fragmented prompt loading and hardcoded language logic) raised this exact architectural point, explicitly including "forcing a fallback to zh", and was closed as addressed in v0.3.0. The parse_language() fallback survived that refactor, so it may be worth treating this as unfinished work from #33 rather than a fresh request.

A useful distinction for prioritization: model-facing language support and UI-facing language support are separable. The former needs no translation files at all — the LLM writes the text, so correctly propagating the language code is sufficient, and the label table already exists. That part is a small, translation-free fix that would immediately unblock German, Japanese, Korean and others for Book/Quiz/Research output, independently of whether full UI locale files are merged.

(Mentioning this because I notice several full UI locale PRs — #291 Korean, #343 Russian, #545/#546/#547 German — were closed unmerged due to interface churn, which is completely understandable. The propagation fix doesn't carry that maintenance burden, since it adds no files that can drift out of sync.)

Happy to help with the backend propagation piece if that's a direction the maintainers want to go.

[Christian-B-Koller]

Sounds interesting, let's develop the concept and implementation together?

[ting-hong-shieh]

I'd like to contribute canonical zh-TW support as a focused follow-up to this proposal.

The current dev branch supports en and zh in the Web UI and settings API, while the prompt-language parser already recognizes zh-tw. I'm preparing a local implementation on a fresh branch based on d7cf75d with this scope:

• add zh-TW to the interface and model-output selectors, with independent persistence;
• add a Taiwan Traditional Chinese catalog for the first-party Web UI and translations for Web-visible backend status, errors, and tool hints;
• centralize canonicalization and aliases across the Web and backend;
• add file, key, value-type, interpolation-placeholder, and source-key coverage checks.

For compatibility, zh would continue to mean Simplified Chinese, the default would remain en, and the canonical stored/API value would be zh-TW.

This first slice would not translate the README (#822), the full CLI, vendor MCP/CLI catalogs, or every internal prompt. I also noticed that #728 adds Spanish and shared language registries on the same dev base, with overlap in several core files. Would you prefer this as a follow-up after #728 lands, or is a separate PR targeting the current dev branch acceptable?

[Christian-B-Koller]

I have done a German language translation with every text on an older version of DeepTutor. I I'll wait until #728 lands and then move my translation over to the architecture and code that is prepared there.