中文-CLIP文本编码器

First, clear up the obvious confusion before it wastes your afternoon: despite the name, this node does not load a "Chinese CLIP" model. No checkpoint downloads, no special weights. It's a thin wrapper around ComfyUI's built-in CLIP text encoder with one added step - if your prompt contains Chinese characters, it translates them to English first, then encodes the result exactly like a normal CLIP Text Encode node. "Chinese-CLIP" here means "CLIP for people who type Chinese," not a model from the Chinese-CLIP project. You still feed it whatever CLIP your checkpoint loader gives you.

If you've been copy-pasting your prompts into Google Translate and pasting the English back, this is the node that does that dance for you. Type 一只戴墨镜的柴犬, hit queue, and what actually gets encoded is the English translation - which the node prints to the ComfyUI console so you can verify it didn't mangle your intent.

How it works

The whole thing is ~50 lines (read nodes.py in the repo; it's refreshingly honest code). When the text box has any character in the CJK range (\u4e00–\u9fff), it does two things:

1. Normalizes Chinese punctuation to ASCII - 中文逗号句号引号 to , . " ' etc. This is the fork's own addition (the original by yuan199696 didn't do it).
2. Calls the translate PyPI library to turn the Chinese into English.

Then it runs the stock ComfyUI path - clip.tokenize(text), clip.encode_from_tokens(...), and returns the CONDITIONING with pooled output. Pure-English text skips the translation entirely and passes straight through, so the node doubles as a plain CLIP encoder when you don't need it.

Here's the part most people miss: the translation is a network call to Google Translate's free endpoint via that translate library. No API key, but it needs internet, it re-runs on every queue, and it's the single source of your failure modes.

The inputs that matter

There are exactly two, and you'll set one of them:

• clip - the CLIP object from your checkpoint/CLIP loader. Nothing special, and it's the thing to check if nothing happens: wire this or the node errors.
• text - the multiline prompt box. Chinese, English, or a mix; the node handles all three.

The single output is CONDITIONING, which wires into KSampler's positive or negative input. Two copies of the node - one for each - and you have a full pipeline.

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/leeneo/ComfyUI-Chinese-CLIP

or just search "Chinese" in ComfyUI Manager's node list and install from there. Then restart ComfyUI. The only Python dependency is translate (requirements.txt is literally that one word), which the Manager installs automatically - if the node throws ModuleNotFoundError: No module named 'translate', run pip install translate in your ComfyUI environment and restart. It shows up in the node menu under 中文-Clip-节点, searchable as "中文" or "Chinese".

Where people get burned

The README says it in so many words: translation may be slow or fail, and if it fails, retry or translate by hand. That's not a bug report, that's the nature of the free Google endpoint - rate limits are real, and each queue run is a fresh request. If a run comes back with obviously wrong conditioning, check the console output for the translation line before blaming your sampler.

Second trap: your translated English is what the model actually sees, so you're bounded by the encoder's token limit (~77 tokens on SD 1.5/SDXL-class CLIP). A long, flowery Chinese paragraph can truncate after translation - keep prompts short and it won't bite.

Third: this is 2023-era plumbing. The community has largely moved on to local-LLM prompt enhancers that do the rewriting and structuring in one shot, and on models whose encoder is itself a language model (Qwen3-class), translating to English is a pointless round-trip. But for classic SDXL/Illustrious workflows where the encoder genuinely wants English, this is the smallest thing that works - zero extra VRAM, zero model downloads, one dependency.