🌐 Translate Subtitle

Translating a subtitle file with a generic LLM prompt is how you get translations that don't line up with the original - the model merges two lines, skips one, and suddenly your subtitles are showing the wrong text at the wrong time. MF_TranslateSubtitle exists to keep the numbering honest. It takes SRT text in, sends it to an LLM in numbered batches, and either returns a translation with every line accounted for or refuses to run at all.

You reach for it right after MF_WhisperTranscribe, which is exactly how the pack's demo chain goes: transcribe → translate → burn. Feed srt_text in, get translated_srt out with the timestamps preserved, and wire that straight into MF_BurnSubtitle. That's a fully automated localization pipeline in three nodes - no video editor, no manual retiming.

How it works

The node parses the SRT, then sends lines to the LLM as numbered batches - [1] ..., [2] ... - through the standard /v1/chat/completions endpoint. It parses the response by the same numbering pattern. Here's the design decision worth appreciating: if the line count drifts (the model merged or dropped a line), the node raises an error rather than quietly emitting misaligned subtitles. A silent off-by-one in subtitle alignment is a broken video; a loud failure is a retry. That's the right trade.

The backend is always openai_compatible. That's not a limitation, it just means you can point base_url anywhere that speaks the OpenAI chat API - OpenAI, Groq, or a local Ollama / LM Studio / llama.cpp server for a fully local chain.

The inputs that matter

• ai_config (required) - wire from MF_AIConfig, and it must be provider=openai_compatible. The faster_whisper_local provider raises here; that's an STT-only mode.
• srt_text - the SRT as a string, wired from MF_WhisperTranscribe or pasted by hand.
• target_lang - free-form, e.g. English, 日本語, Español. Default is 繁體中文 (the author's home turf).
• batch_size - lines per LLM call, default 20. Smaller is more reliable; larger is faster until small models drift.

Output: translated_srt (STRING) - SRT with original timestamps, ready for MF_BurnSubtitle.srt_text or MF_ConvertChinese if you want it normalized (say, simplified → traditional with Taiwan vocabulary) before burning.

Install

Ships in the MediaForge pack. ComfyUI Manager → search "MediaForge", or:

cd ComfyUI/custom_nodes
git clone https://github.com/leon80148/comfyui_MediaForge.git

Restart, and you'll find it under MediaForge/AI. The pack's requirements.txt already includes requests, which is all a hosted translation needs. For a local LLM you'll want Ollama or LM Studio running on your own box - see below.

Common issues

• Line count drifts on big batches. The README's own guidance: gpt-4o-mini is fine up to batch ~30; for long-form or specialized vocabulary switch to gpt-4o or Groq's llama-3.3-70b-versatile and you can push batch 50+. Or just drop batch_size and retry.
• Fully offline pipeline? Ollama / LM Studio don't expose Whisper, so they work for translate only. Pair openai_compatible pointed at http://localhost:11434/v1 with faster_whisper_local on the transcribe side, and nothing leaves your machine.
• Empty srt_text raises - you'll get a message telling you to wire the transcribe output or paste an actual SRT. It's a guard, not a bug.

One takeaway: treat this node as the translation layer of a bigger assembly, not a standalone toy. Its whole job is producing SRT that's structurally identical to what went in - and refusing loudly when the LLM gets sloppy. That stubbornness is what makes the chain downstream (burn, upload, publish) trustworthy.