Background
Multilingual transcription support is already implemented in backend/docker/docs via WHISPER_LANGUAGE (including optional auto-detect and continued .en compatibility).
This issue should build on that work by making language selection user-accessible in the UI, instead of env-only configuration.
Objective
Let users choose transcription language from the app UI and route that value through the existing transcription pipeline without changing current defaults.
Scope
- Add a transcription language selector in UI settings (or recording/transcription panel).
- Include
Auto (default) option.
- Include a small set of common language options first (e.g., English, Spanish, French, etc.).
- Wire selected value into existing transcription request/config path.
- Reuse current backend support for
WHISPER_LANGUAGE.
- No model/engine changes required.
- Persist user selection.
- Keep it across reload/restart (existing settings store/local persistence).
- Keep current behavior unchanged when not set.
- Default remains auto/English-compatible existing flow.
Out of Scope
- New model integrations.
- Full locale/i18n for all UI text.
- Advanced language auto-routing heuristics.
- Major backend refactors.
Detailed Success Criteria
- Functional
- User can select transcription language from UI.
- Selection is applied to new transcription runs.
Auto option works and maps to existing optional language behavior.
- Backward compatibility
- English transcription remains unchanged when user keeps default.
- Existing
.en model workflows still work.
- Docker/SAM/local workflows continue functioning.
- Reliability
- Invalid/unsupported UI value is safely rejected or falls back to default.
- Clear UI/console error path for bad language config.
- Persistence
- Selected language persists across app restart/reload.
- Test coverage
- Add tests for:
- default (
Auto) behavior
- explicit language selection (at least one non-English case path)
- persistence and restore
- fallback on invalid value
- Documentation
- Add a short docs section:
- how UI selection relates to
WHISPER_LANGUAGE
- precedence rules (UI override vs env default)
Suggested Acceptance Checklist
Rationale
- Builds directly on the completed multilingual backend/env work.
- Small, high-impact UX improvement.
- Keeps implementation low-risk by reusing existing
WHISPER_LANGUAGE support.
Background
Multilingual transcription support is already implemented in backend/docker/docs via
WHISPER_LANGUAGE(including optional auto-detect and continued.encompatibility).This issue should build on that work by making language selection user-accessible in the UI, instead of env-only configuration.
Objective
Let users choose transcription language from the app UI and route that value through the existing transcription pipeline without changing current defaults.
Scope
Auto (default)option.WHISPER_LANGUAGE.Out of Scope
Detailed Success Criteria
Autooption works and maps to existing optional language behavior..enmodel workflows still work.Auto) behaviorWHISPER_LANGUAGESuggested Acceptance Checklist
Auto+ language optionsRationale
WHISPER_LANGUAGEsupport.