CLIP Text Encode (Auto Translate)

This is the standard CLIP Text Encode node with one thing bolted on: before your text ever touches CLIP, it gets machine-translated to English. Same two inputs as the vanilla node, same CONDITIONING output, drop-in compatible with any workflow that already uses CLIP Text Encode. The only difference is you can type your prompt in whatever language you actually think in, and it just works.

Why that matters and isn't just a convenience gimmick: CLIP's text encoder was trained overwhelmingly on English image-caption pairs. Feed it prompts in Indonesian, French, whatever, and you're not getting a translation error - you're getting silently degraded conditioning, because the model is working with vocabulary it barely learned. This node fixes that at the source instead of leaving you to guess why your non-English prompts produce mushy or off-target results.

How it works

On execution it runs your text through langdetect to figure out what language it's in, sends it to Google Translate via deep_translator's GoogleTranslator targeting English, and then feeds the translated string into the same CLIPTextEncode machinery ComfyUI ships natively - tokenize with the model's own tokenizer, run it through the clip model you passed in, out comes conditioning. If the translation step errors out (bad connection, translation service hiccup), the pack's error handling logs it and falls back to encoding your original text rather than failing the whole node - so a network blip degrades gracefully to normal (English-only) CLIP Text Encode behavior instead of breaking your run.

It's genuinely just two nodes glued into one: this pack's Prompt Text (Auto Translate) translation step, then the ordinary CLIP Text Encode step. If you want to inspect the translated text before it hits CLIP, or route the same translated string somewhere else too, use that sibling node plus a regular CLIP Text Encode instead - this combo exists purely to save the extra hookup when you don't need the visibility.

The inputs and outputs that matter

Only two inputs, both required, exactly matching the stock node:

• text (STRING, multiline) - your prompt, in any language. This is the field you actually type into.

• clip (CLIP) - the CLIP model to encode with, same as you'd plug into any CLIP Text Encode. Comes from your checkpoint loader or CLIP loader, same as always.

• Output: CONDITIONING - wire it exactly where you'd wire a normal CLIP Text Encode's output: into your sampler's positive or negative conditioning slot.

Because this still routes through the real CLIP tokenizer underneath, the usual CLIP-era limits still apply after translation - most notably the 77-token cap that CLIP ViT-L/14 truncates at. Translation can change your prompt's length (some languages expand or compress noticeably when translated to English), so a prompt that fit comfortably in your own language can occasionally push past that limit once translated. If you're on a model with an LLM-based text encoder instead of classic CLIP, this node's node type won't match what that model expects - it outputs CLIPTextEncode-style conditioning, built for the CLIP family.

How to install it

Via ComfyUI Manager: search "ComfyUI-Translator", install, restart - this pulls in both nodes in the pack, this one and Prompt Text (Auto Translate), together.

Manual install, same as any custom node:

cd ComfyUI/custom_nodes
git clone https://github.com/adigayung/ComfyUI-Translator

Then install the requirements - deep_translator and langdetect - through your ComfyUI Python environment. On the portable Windows build, run pip through the embedded interpreter:

cd custom_nodes\ComfyUI-Translator
..\..\..\python_embeded\python.exe -m pip install -r requirements.txt

On a regular venv install it's just pip install -r requirements.txt with your ComfyUI environment active, then restart. Nothing else to download - no translation model gets pulled to disk, since the translating itself happens over the network via Google Translate.

Common issues & troubleshooting

Conditioning looks fine but the image doesn't match what you meant. Check what actually got translated. Machine translation of short, tag-style prompts ("cinematic, dramatic lighting, 8k") can come out stilted or slightly off from natural phrasing, because Google Translate is built for sentences, not comma-separated keyword lists. If results feel off, try writing your prompt in your language as a fuller sentence rather than a tag list - it tends to translate more faithfully.

No output, or the original untranslated text got encoded instead. That's the pack's built-in fallback after a failed translation call, not a crash - it logs the error and encodes your original text so the run still completes. Confirm you actually have network access; this node hits Google's translate service on every execution and has no offline mode.

Detected the wrong source language on a short prompt. Same landmine as its sibling node - langdetect needs enough text to be confident, and short or ambiguous phrases can get misidentified, feeding the wrong translation into CLIP. Longer phrasing fixes it.

You need this on a non-CLIP model (an LLM-encoded checkpoint). This node is built specifically around the classic CLIPTextEncode path - text in, clip.encode, conditioning out. Newer model families using an LLM as their text encoder don't take a clip input in the same shape, so this isn't the node to reach for there; it's aimed squarely at CLIP-based checkpoints (SD 1.5, SDXL, Flux's CLIP-L half, and similar).