Add option to manually set a fixed transcription language (disable per-segment auto-detection)

[elkpvl-commits]

Feature Description

Add an option to manually set a fixed transcription language instead of relying on automatic per-segment language detection.

Problem Statement

I use Meetily v0.4.0 on Windows 10 for meetings that are conducted entirely in Russian. The transcription engine tries to auto-detect the language continuously, which causes serious problems:

• Most Russian phrases are not recognized correctly because the model attempts to interpret them as English.
• Sometimes the transcript contains random English text that has nothing to do with what was actually said — it is not a translation, just noise. The real speech at that moment is lost and never appears in the transcript.
• As a result, parts of the conversation are missing and are replaced by hallucinated English phrases.

(Recognition quality of Russian speech itself is sometimes imperfect too, but I assume that is more related to the underlying transcription model rather than to Meetily.)

Proposed Solution

Provide a setting where the user can explicitly select the transcription language (e.g. "Russian") and force the engine to use it for the entire session, disabling automatic language detection. This should stop the model from constantly switching languages and inserting unrelated content.

User Story

As a user who holds meetings in a single fixed language,
I want to manually lock the transcription language,
So that the engine stops auto-detecting per segment and produces accurate, complete transcripts.

Acceptance Criteria

• A setting exists to manually select a fixed transcription language.
• When set, automatic language detection is disabled for the whole session.
• Transcription no longer inserts unrelated foreign-language text or drops real speech.

Technical Considerations

If the underlying engine is Whisper-based, this could likely be implemented by passing a fixed language parameter and disabling auto-detection.

Additional Context

Environment: Meetily v0.4.0, Windows 10, Russian-language meetings only.

Checklist

• I have searched for similar feature requests
• I have provided all required information
• I have included any relevant screenshots/mockups
• I have described the problem and proposed solution clearly

[Hus-Mek]

I hit the same failure in Arabic and traced it. There are two separate causes behind your symptoms, and one of them you can work around today.

1. "Auto Detect (Translate to English)" translates to English by design

The transcription-language dropdown offers two auto entries that look almost identical:

• Auto Detect → auto
• Auto Detect (Translate to English) → auto-translate

The second one is not a detection mode. In whisper_engine.rs it maps to:

Some("auto-translate") => (None, true),   // (language_code, should_translate)
...
params.set_translate(should_translate);

set_translate(true) is Whisper's translate task — it outputs English on purpose. And LANGUAGE_PREFERENCE in lib.rs defaults to "auto-translate" on the Rust side, so it is what applies until the UI pushes your saved choice down.

That matches your report closely: "random English text… it is not a translation, just noise" — some of it likely is translation, mixed with cause 2 below.

Workaround right now: open the transcription-language selector and pick Russian (ru) explicitly, not either Auto entry. The explicit path already does what this issue asks — Some(lang) => (Some(lang), false) pins the language for the whole session and disables detection:

params.set_language(Some("ru"));
params.set_translate(false);

So the acceptance criteria here are largely already met by the existing selector; the problem is that the two Auto entries are easy to pick by accident and one of them silently translates.

2. Even with auto, per-segment detection is unreliable because the segments are tiny

This is the part that needs a code fix, and it explains "parts of the conversation are missing and are replaced by hallucinated phrases" precisely.

The live VAD closed a speech segment after only 400 ms of silence, and every segment becomes its own transcription request. Measured on a real 26-minute meeting:

requests	322
median request length	3.49 s
requests under 3 s	42 %
requests reaching 25 s	1 of 321

Whisper is a fixed 30-second-window model. Below that it zero-pads the window and falls back on its language-model prior, which was trained on web subtitles — so short clips come back as memorised boilerplate rather than speech, and language auto-detection on a 3-second clip is close to a coin flip. In my Arabic recording, 19 % of sub-2-second segments were pure hallucination versus 1 % of segments over 5 seconds — a 19× difference driven purely by clip length.

For a non-English language this is much worse than for English, because the English prior is what the model falls back to.

#679 raises the live redemption time from 400 ms to the 2000 ms the file-import and re-transcription paths already use (the repo even ships a test asserting 400 ms over-fragments). That lengthens segments substantially and should materially reduce both the misdetection and the hallucinated-filler-replacing-real-speech behaviour you are seeing. It does not require you to pin a language, though pinning is still strictly better.

Suggestion for this issue

Beyond the redemption fix, the remaining UI gap is small:

• rename or separate the two Auto entries so "translate to English" cannot be chosen by accident
• do not default the Rust-side preference to auto-translate; auto is the safer default
• optionally show the active language during recording, so a silent fallback is visible

Happy to put that together if it would help — it is independent of #679.