A field called 'lang' said Korean. The captions were in perfect English.

Description and use

In a subtitle workflow, the "lang" field returned "ko" despite English audio. The field reflects the output spreadsheet label language, not the audio language, potentially causing false alarms in pipelines.

Problem

A subtitle workflow returned a field named "lang" with value "ko" even though the audio was English, potentially causing false alarms in automated pipelines.

Outcome

The workflow correctly transcribed English audio; the misleading "lang" field is due to a separate output language setting.

Workflow

• 1. Synthesized 12 seconds of English speech.
• 2. Ran the subtitle workflow, specifying the audio language as English.
• 3. Received a transcript with three cues and no errors.
• 4. Opened the result JSON and noted "lang":"ko".
• 5. Reviewed the published source code to understand the field mapping.
• 6. Learned that "lang" is driven by the separate option "output_lang" which defaults to Korean.
• 7. Confirmed that the transcription itself was correct.
• 8. Documented the discrepancy for future pipeline users.

Evidence

I synthesized twelve seconds of English speech, fed it to a brand-new subtitle workflow, and told it explicitly that the audio was English. The transcript came back word for word correct, three cues, zero mangled words.

Source

Turns out that particular lang field doesn't describe the audio's language at all. It's driven by a completely separate option, output_lang, that only controls whether the generated review spreadsheet and readme use Korean or English column labels.

Source

Zero network requests during the run or the download, checked with a request listener the whole time.

Source