Meetily Language Preference System: How Auto-Translate Works During Transcription

Meetily stores user language preferences in a global thread-safe Mutex<String> accessed by both the Tauri frontend and Rust transcription pipeline, enabling automatic detection, explicit BCP-47 codes, and an "auto-translate" mode that returns English transcripts directly from the Whisper engine.

Meetily is an open-source meeting transcription application that coordinates language settings across its entire stack. The language preference system bridges the JavaScript frontend and Rust backend through thread-safe global state, allowing users to control whether transcriptions use automatic language detection, target a specific language, or automatically translate speech to English in real-time.

Global State and Thread Safety

The language preference system relies on a global static variable protected by a mutex to ensure thread-safe access across asynchronous transcription workers.

In frontend/src-tauri/src/lib.rs, the system declares a Mutex<String> called LANGUAGE_PREFERENCE that stores the user's selected mode. This global state is accessible throughout the Rust codebase, allowing both the parallel processor and individual transcription workers to read the current setting before processing audio chunks.

Setting Language Preferences from the Frontend

Users configure their preference through a Tauri command that writes directly to the global mutex.

The set_language_preference command defined at lines 75-82 in frontend/src-tauri/src/lib.rs accepts a string parameter and locks the mutex to update the stored value:

// Frontend: Configure auto-detection with translation to English
await invoke('set_language_preference', { language: 'auto-translate' });

// Or set explicit language
await invoke('set_language_preference', { language: 'es' });

Valid string values include:

• "auto" – Automatic language detection without translation
• "auto-translate" – Detect spoken language and translate output to English
• BCP-47 codes (e.g., "es", "fr", "de") – Force transcription in a specific language

Retrieving Preferences in the Rust Backend

Any Rust module can access the current preference through an internal getter function that handles mutex locking safely.

The get_language_preference_internal() function at lines 85-88 in frontend/src-tauri/src/lib.rs locks the LANGUAGE_PREFERENCE mutex and returns a cloned Option<String>:

// Rust: Retrieve current language before processing audio
let language = crate::get_language_preference_internal();
engine.transcribe_audio(chunk_data, language).await?;

This function is called at critical integration points including line 344 of frontend/src-tauri/src/whisper_engine/parallel_processor.rs and line 449 of frontend/src-tauri/src/audio/transcription/worker.rs, ensuring every audio chunk respects the user's current setting.

How Auto-Translate Works in the Whisper Engine

The core transcription logic handles three distinct language modes through pattern matching against the preference string.

Inside frontend/src-tauri/src/whisper_engine/whisper_engine.rs (lines 516-535), the transcribe_audio and transcribe_audio_with_confidence functions extract a language_code and a boolean should_translate flag:

// Whisper Engine: Language handling logic (lines 516-535)
let (language_code, should_translate) = match language.as_deref() {
    Some("auto-translate") => (None, true),          // Detect + translate to English
    Some("auto") | None => (None, false),           // Detect only, no translation
    Some(code) => (Some(code), false),               // Use explicit BCP-47 code
};

params.set_language(language_code);
if should_translate {
    params.set_translate_to_english(true);
}

When "auto-translate" is selected, the system passes None to Whisper's language parameter (triggering auto-detection) but sets should_translate to true. This instructs Whisper to return the English translation directly, eliminating the need for separate post-processing.

Integration with Transcription Workers

The preference system integrates at the entry points of both parallel and serial transcription pipelines.

Parallel Processor: At line 344 of frontend/src-tauri/src/whisper_engine/parallel_processor.rs, the code fetches the preference before dispatching chunks to worker threads.

Transcription Worker: At line 449 of frontend/src-tauri/src/audio/transcription/worker.rs, each worker retrieves the current language setting before calling the Whisper engine, ensuring dynamic updates take effect immediately without restarting the transcription session.

This design allows users to change language settings mid-meeting, with subsequent audio chunks automatically respecting the new preference.

Summary

• Global Thread-Safe Storage: Language preferences live in a Mutex<String> at frontend/src-tauri/src/lib.rs, accessible across all Rust modules.
• Three Operating Modes: The system supports "auto" (detection only), "auto-translate" (detection + English translation), and explicit BCP-47 codes.
• Translation at Source: When using "auto-translate", Whisper handles translation internally via params.set_translate_to_english(true), delivering English text directly to the UI.
• Real-Time Updates: Both parallel and worker transcription threads call get_language_preference_internal() before processing each chunk, enabling dynamic preference changes.

Frequently Asked Questions

What is the difference between "auto" and "auto-translate" in Meetily?

"auto" tells Whisper to automatically detect the spoken language and return the transcript in that same language. "auto-translate" also triggers automatic detection, but additionally sets the should_translate flag to request English output regardless of the source language. Both modes detect the language, but only "auto-translate" converts the output to English.

How does Meetily ensure thread safety when multiple transcription workers read the language preference?

Meetily uses a Mutex<String> called LANGUAGE_PREFERENCE wrapped in a lazy static. The get_language_preference_internal() function locks this mutex, clones the string value, and releases the lock immediately, ensuring that multiple parallel processors and transcription workers can safely read the current setting without race conditions.

Can I force transcription in a specific language like Spanish or French?

Yes. Pass any valid BCP-47 language code (such as "es" for Spanish or "fr" for French) to set_language_preference. When the Whisper engine receives a specific code, it skips auto-detection and uses that language parameter directly via params.set_language(Some(code)), improving accuracy for known language contexts.

Where does the translation happen when using "auto-translate" mode?

Translation occurs inside the Whisper engine itself. When the code detects "auto-translate" at lines 516-535 of whisper_engine.rs, it calls params.set_translate_to_english(true) before sending the request. Whisper then returns the English translation as the primary transcript, so the UI receives translated text without requiring separate post-processing or external translation APIs.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}