Bilingual Content Production: zh Master Drafts, en Rewrites, and Consistency Checks

A bilingual knowledge base has a hidden cost structure: every article is really two -- a zh version and an en version that share facts but face entirely different readers and search engines. Treating the en version as a translation of the zh version is the most common and most expensive starting mistake. This article documents GPTMap's complete bilingual production workflow: which frontmatter fields are shared versus independent, why internal links must use the target language's actual titles, the systematic fix for over-length en fields, and the closing triple check. Every rule comes from the actual production of this site's 80 bilingual articles (verified 2026-09-04).

1. Positioning: en Is a Rewrite, Not a Translation

Translation thinking produces "English counterparts of zh sentences"; rewrite thinking produces "the same facts expressed for English readers". The difference concentrates in three places:

• SEO fields are rebuilt entirely: seoTitle, seoDescription, and keywords are written independently for English search terms and length habits, not decoded from the zh fields;
• Examples and references localize: the cases, comparison targets, and background cited for en readers may differ, as long as the factual numbers stay identical;
• Information density differs: the same fact runs longer in English (see section 4), so the structure must compress deliberately rather than map point for point.

The only invariant is the facts themselves: every number, date, version, and reference URL must be strictly identical across the two versions -- which is what the closing checks focus on.

2. The Field Split: Shared versus Independent

Using this site's frontmatter as the example, fields divide into two groups:

# Bilingual frontmatter example (the two language versions of one article)
slug:            mcp-oauth-2-1          <- shared
category:        mcp                    <- shared
publishedAt:     2026-09-03             <- shared
title (zh):      (the zh-language title)      <- independent
title (en):      MCP Authorization Explained: …   <- independent
tldr (zh/en):    same facts, each language at its own length
officialReferences: URL list identical   <- shared (title text may differ per language)

3. Internal Links: Verbatim Titles in the Target Language

Bilingual internal links follow two symmetric rules:

1. When a zh article links another article, the link text equals the target file's zh title, wrapped in book-title marks;
2. When an en article links another article, the link text equals the target file's en title, no marks.

The most dangerous trap for en links is translating the zh title as the link text -- the two titles are genuinely different (the zh and en titles genuinely differ in wording, structure, and punctuation), so any "translated link text" mismatches the target page's H1. The solution is a scripted verbatim comparison: extract each internal link's text and compare against the target file's title, flagging every mismatch. This rule is scripted on this site, run once for zh and once for en.

4. Language-Specific Traps

zh traps: unescaped English double quotes inside frontmatter values break YAML parsing (the error message is obscure -- see section 3's lesson); fullwidth quotes have no such problem and are safe in prose.

en traps: length overruns are systemic, not occasional -- the same information runs 30-100% more characters in English (empirical), and the seoTitle (at most 60) and tldr (at most 400) caps are hit almost every time. The systematic solution is candidate selection:

# en field tightening: descending candidates, assert-select the first that fits
candidates = [long_draft, trimmed_v2, trimmed_v3]
value = next(c for c in candidates if len(c) <= 400)

Plus two craft rules: the first tightening pass restructures (cut modifier clauses, merge parallels, drop lists), and only the second pass cuts substance; never start by deleting facts -- a deleted fact is gone.

Apostrophes: en drafts should standardize on straight (') or curly (') apostrophes; YAML accepts both, but straight apostrophes can conflict with code blocks in some rendering pipelines, so pick one convention.

5. The Closing Triple Check

After each pair, and before every batch seals, three checks run scripted:

1. Bilingual frontmatter parity: identity fields equal field-for-field; wording-field counts equal (the number of keyPoints / faqs / officialReferences matches zh = en);
2. Verbatim link-title comparison: the comparison script runs once for zh and once for en (section 3);
3. Closing statistics: the batch changes numbers like "this site has N articles" -- the command re-runs after the last file is written and the final value goes into the text (80 articles on this writing day).

# Verbatim link-title comparison (the scripted form of closing check 2)
python3 - <<'PYEOF'
import re, glob, os
titles = {f[:-6]: re.search(r'^title: "(.*)"', open(f, encoding='utf-8').read(), re.M).group(1)
          for f in glob.glob('*.md')}
# ...for each internal link: compare link text to the target title verbatim
PYEOF

6. Common Mistakes and Troubleshooting

• Direct-translating the zh title into the en seoTitle: produces titles English readers never search for, and desyncs from the en internal-link system.
• Fixing zh and forgetting en: a factual revision lands only in the zh version while the en version ships old numbers. Revisions must sync both versions, with the closing parity check as the backstop.
• Hand-counting en overruns: eyeballing character counts is always wrong; let the length assertion auto-select from candidates.
• Translating tags: a word-for-word zh tag does not necessarily map to the terms en users search -- tags are drafted per language.
• Adding a backlink only in zh: new links land in the zh version while the en version misses them -- include internal-link counts in the parity check.

7. Next Steps

• The fact-level verification workflow upstream of both languages: Source Verification and Review-Until-Clean: A Fact-Checking Workflow for AI Content.
• The consistency system this workflow pairs with: World-State Consistency for Multi-Author Knowledge Bases.
• The full checklist view of the bilingual workflow: The GPTMap editorial checklist: 12 steps to a publishable OpenAI article.