Token Counting for Translation Workflows in English and Chinese
An English–Chinese translation request is rarely just one sentence in and one sentence out. A production request may also carry system instructions, a terminology glossary, translation-memory examples, formatting rules, JSON fields, and a QA pass. Every component can consume tokens.
That is why translation teams should budget the complete workflow, not estimate cost from the visible source text alone.
The practical rule is simple:
Count the exact request for the exact model, reserve a separate output budget, and verify the endpoint's reported usage with production-like tests.
This guide shows how to do that for both English-to-Chinese and Chinese-to-English workflows, with examples you can paste into TokenTest when evaluating an OpenAI-compatible or Anthropic-style model endpoint.
Why translation token counts are not symmetrical
Suppose two passages communicate the same meaning in English and Chinese. They may have similar reading time, but they do not necessarily have similar token counts.
A tokenizer does not count ideas, words, or visible characters. It splits text according to a model-specific vocabulary and encoding process. The resulting count can change with:
- language and wording;
- model and tokenizer version;
- spaces, punctuation, and line breaks;
- uncommon names and technical terminology;
- JSON, XML, Markdown, or other wrappers;
- system and developer instructions;
- tool definitions, retrieved context, and examples.
The direction of translation also matters. English source text and Chinese output may produce one ratio, while Chinese source text and English output produce another. A longer English translation can still tokenize efficiently because common English sequences may be grouped together. A compact Chinese sentence can still split into multiple tokens depending on the tokenizer and characters used.
There is therefore no dependable rule such as “one Chinese character equals one token” or “Chinese always costs more than English.” Those shortcuts are too fragile for production budgeting.
For a deeper explanation of why visible length and model usage diverge, see Token Count vs Character Count and Why Chinese Prompts Can Use Different Token Budgets Than English Prompts.
The six parts of a translation token budget
A useful translation budget separates the request into parts instead of tracking one total.
| Budget component | What it includes | Why it changes |
|---|---|---|
| Instructions | System prompt, role, tone, locale, forbidden behavior | Often reused across every segment |
| Source text | The content to translate | Varies by language, length, names, and formatting |
| Reference context | Glossary, style guide, translation memory, examples | Can be larger than the source text |
| Request structure | Messages, JSON keys, tool schemas, delimiters | Adds overhead that a plain-text counter may miss |
| Translation output | The generated target-language text | Must be reserved before the request is sent |
| QA and retries | Critique, revision, back-translation, failed attempts | Multiplies total workflow usage |
For one-pass translation, a planning formula is:
planned tokens = instructions + source + reference context + request overhead + reserved output
For a translation plus review workflow, use:
workflow tokens = translation request + QA request + revision request + expected retry allowance
Do not treat these formulas as tokenizer replacements. They are accounting structures. Each input term should come from the target model's official counter or from measured endpoint usage.
A practical English-to-Chinese workflow
Consider this paste-ready source:
Translate the following product update into Simplified Chinese for enterprise software buyers. Preserve the product name, keep the tone concise, and return only the translation.
Source:
TokenTest checks whether a model endpoint reports plausible input, output, total, and cached token usage before a team relies on it in production.
A minimal test counts the full prompt above and reserves enough space for the Chinese answer. A production test may add a glossary:
Terminology:
model endpoint = 模型端点
cached token usage = 缓存 Token 用量
production = 生产环境
The glossary improves consistency, but it also increases input tokens on every request. If you translate 500 segments with the same glossary, repeatedly sending the entire glossary may become a larger cost driver than the text being translated.
Possible mitigations include:
- Send only terms relevant to the current segment.
- Group related segments so they share a smaller domain glossary.
- Use provider-supported prompt caching when its behavior and pricing fit the workflow.
- Track cached-token evidence separately from ordinary input usage.
TokenTest's D4 token-usage checks inspect whether input, output, total, truncation, and cache-token evidence are present and plausible. That makes it useful for verifying the endpoint that will run the translation—not merely estimating a string in isolation.
A practical Chinese-to-English workflow
Now reverse the direction:
请将以下产品说明翻译成适合企业软件采购人员阅读的英文。保留产品名，语气简洁，只输出译文。
原文：
TokenTest 会在团队将模型端点用于生产环境之前，检查其输入、输出、总量与缓存 Token 用量是否合理。
Do not reuse the English-to-Chinese output allowance automatically. English translations may expand in visible length, and the target model may tokenize that English differently from the Chinese source.
Run both directions independently and record at least:
- source characters;
- source input tokens;
- instruction and glossary tokens;
- generated output tokens;
- total tokens;
- cached tokens, if reported;
- truncation or stop reason;
- retry and revision count.
The result is a directional baseline rather than a universal language ratio.
Count the wrapper, not just the text
Translation applications often send structured requests like this:
{
"source_language": "en",
"target_language": "zh-CN",
"tone": "concise enterprise software",
"preserve_terms": ["TokenTest", "API", "JSON"],
"source_text": "Paste the source text here"
}
The keys, quotes, brackets, locale labels, and preserved-term list are part of the request. Tool schemas can add much more. Counting only source_text understates the actual input.
This difference becomes especially important when a workflow processes short strings. For a two-word button label, the wrapper may consume many times more tokens than the content itself.
Before launch, test at least three segment sizes:
| Segment class | Example | Main risk |
|---|---|---|
| Short UI string | Button, menu label, validation message | Fixed wrapper dominates cost |
| Medium segment | Help-center paragraph or product description | Glossary and examples materially affect input |
| Long document section | Policy, guide, or report section | Context and output limits become critical |
Budget QA, revision, and retries
High-quality translation often uses more than one model call.
A common workflow is:
- Translate the source.
- Ask a reviewer prompt to find omissions, mistranslations, and terminology violations.
- Ask the model to revise the translation using that critique.
- Retry calls that fail validation, time out, or return malformed JSON.
The QA call may include the original source, the first translation, the glossary, and the review rubric. The revision call may include all of that again plus the critique. As a result, a three-call workflow can consume far more than three times the source-text count.
Track translation, QA, and revision as separate request types. This reveals whether quality improvements come from a small review overhead or from an unexpectedly expensive context bundle.
Build a translation token budget from real samples
Use a sample set that reflects actual production content rather than one polished demo sentence.
Include:
- short and long segments;
- UI strings and prose;
- names, numbers, URLs, and placeholders;
- Markdown, HTML, and JSON;
- domain terminology;
- both translation directions;
- examples likely to trigger a retry or revision.
Then follow this workflow:
1. Freeze the request template
Save the exact system instructions, glossary format, message roles, JSON structure, and output rules. Small formatting changes can change tokenization.
2. Preflight the complete input
Use the official count method for the selected provider and model. OpenAI documents an input-token counting endpoint for Responses API inputs, Anthropic provides a token-counting endpoint for Messages inputs, and Gemini exposes token-counting methods for model inputs.
3. Reserve output by direction and content type
Do not use one universal output multiplier. Create separate percentiles for English-to-Chinese UI text, English-to-Chinese prose, Chinese-to-English UI text, and Chinese-to-English prose.
4. Run production-like endpoint tests
Use the real message structure, temperature, tools, and output limits. In TokenTest, evaluate the endpoint and inspect token-usage integrity alongside protocol and output behavior. Use a test-only API key; TokenTest states that it does not store the key.
5. Reconcile estimates with reported usage
Compare the preflight count with returned input usage. Investigate large differences before applying the budget to thousands of segments.
6. Add a safety margin from observed variance
Base the margin on real samples and failure cases. Recalculate it whenever the model, tokenizer, prompt, glossary, tool schema, or segmentation strategy changes.
Metrics worth keeping
For each translation job, store enough aggregate data to explain cost and failures without retaining sensitive source content unnecessarily.
| Metric | Use |
|---|---|
| Input tokens by component | Shows whether source, instructions, or glossary drives cost |
| Output tokens | Supports directional and content-type baselines |
| Total tokens | Reconciles request-level usage |
| Cached tokens | Measures whether repeated context is actually benefiting from caching |
| Tokens per source character | Useful within one stable model and content class |
| Tokens per translated character | Helps estimate output allowance for a specific direction |
| Revision rate | Connects translation quality to additional model calls |
| Truncation rate | Detects under-budgeted output or context pressure |
Ratios are monitoring tools, not universal constants. A ratio learned from software UI strings should not be applied blindly to legal prose, customer reviews, or code-heavy documentation.
Paste-ready tests for TokenTest
Run these as separate cases against the model endpoint you plan to use.
Test A: Same task, opposite direction
EN → ZH: Translate into Simplified Chinese: Our support team will review your request within two business days.
ZH → EN: 翻译成英文：我们的支持团队将在两个工作日内审核你的请求。
Inspect whether input and output usage differ by direction even though the meanings are aligned.
Test B: Glossary overhead
Translate into Simplified Chinese. Preserve these terms exactly: TokenTest, API, JSON, SLA, P95, TTFT.
The evaluation report compares protocol integrity, token usage, latency, and output stability.
Repeat with and without the preserved-term instruction. Compare the input-token change and translation consistency.
Test C: Structured output overhead
Translate into English and return valid JSON with keys translation, terminology_warnings, and needs_review.
原文：如果模型返回的总 Token 数与输入和输出之和不一致，请标记为需要复核。
Inspect total usage, JSON validity, and whether the output limit leaves enough room for every required field.
Common mistakes
- Counting only source characters. Character length does not determine model-specific token usage.
- Ignoring repeated context. Instructions, glossaries, and examples are paid again unless caching applies and is correctly reported.
- Using one ratio for both directions. English-to-Chinese and Chinese-to-English require separate baselines.
- Forgetting review calls. QA and revision can dominate the total workflow budget.
- Trusting a local estimate as the invoice. Preflight counts support planning; provider usage and billing records remain the operational source of truth.
- Keeping stale budgets after a model change. A model or tokenizer update can invalidate historical ratios.
Final checklist
Before scaling an English–Chinese translation workflow, confirm that you have:
- counted the complete model-specific request;
- separated instructions, source, reference context, and output;
- measured both translation directions;
- tested short, medium, and long production samples;
- budgeted QA, revisions, and retries;
- checked truncation and cache-token behavior;
- reconciled preflight estimates with endpoint-reported usage;
- rerun the baseline after every material model or prompt change.
Token counting for translation is not about finding one permanent English-to-Chinese conversion ratio. It is about building a repeatable measurement process. Count before the call, verify after the call, and base future budgets on the workflow you actually run.
Frequently asked questions
Does Chinese always use more tokens than English?
No. The result depends on the exact wording, model, tokenizer, request structure, and translation direction. Measure semantically comparable samples with the target model.
Should I count the glossary on every request?
Yes, if it is included in every request. If the provider supports prompt caching, track whether cached-token evidence appears and whether the economics justify the design.
How much output should I reserve for translation?
Use measured output percentiles for each language direction and content class. Add room for required JSON fields or explanations, then monitor truncation.
Can TokenTest replace the provider's official tokenizer?
No. Use the provider's official counting method for preflight planning. Use TokenTest to evaluate the live endpoint and check whether returned token usage and related behavior look plausible.
What should trigger a new token baseline?
Recount after changing the model, tokenizer, prompt template, glossary, tools, output schema, segmentation rules, or translation quality workflow.