Generate Japanese and English in One Structured Call to Stop Term Drift

Pair the two languages in responseSchema

This is the heart of the switch. Before, I called twice — once for Japanese, once for English. After, one responseSchema holds both languages side by side and returns them in a single call.

Before (two independent calls):

from google import genai
 
client = genai.Client()
 
def gen_one(lang: str, topic: str) -> str:
    prompt = f"Write an article in {lang} on: {topic}"
    res = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=prompt,
    )
    return res.text
 
ja = gen_one("Japanese", "Gemini structured output")
en = gen_one("English", "Gemini structured output")
# ja and en never see each other's wording, so the translation drifts

After (the pair in one call):

from google import genai
from pydantic import BaseModel
 
class Section(BaseModel):
    heading_ja: str
    heading_en: str
    body_ja: str
    body_en: str
 
class Article(BaseModel):
    title_ja: str
    title_en: str
    sections: list[Section]
 
client = genai.Client()
 
def gen_pair(topic_ja: str, topic_en: str, glossary_text: str) -> Article:
    prompt = (
        "Write the Japanese and English versions of the same topic at once.\n"
        "Pair heading and body across languages in each section.\n"
        f"Japanese topic: {topic_ja}\n"
        f"English topic: {topic_en}\n"
    )
    res = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=prompt,
        config={
            "system_instruction": glossary_text,
            "response_mime_type": "application/json",
            "response_schema": Article,
        },
    )
    return Article.model_validate_json(res.text)

The key is that Section keeps both languages at the same level. Because the model writes each section's Japanese and English together, heading granularity and word choice get decided inside one train of thought. The structural mismatch from earlier essentially disappeared just from this shape.

Pin the glossary in the system instruction

The schema alone does not lock the wording. Pass the glossary as a system instruction every time and state plainly: "do not deviate from these pairs." It goes on the system side rather than in the prompt body because I want to swap the body freely while the term agreement stays put.

def build_glossary_instruction(glossary: list[dict]) -> str:
    lines = [
        "You are a bilingual (Japanese/English) technical writer.",
        "Honor the following pairs strictly and never let them wobble.",
    ]
    for g in glossary:
        note = f" ({g['note']})" if g.get("note") else ""
        lines.append(f'- "{g["ja"]}" = "{g["en"]}"{note}')
    lines.append("For terms not in the list, show the original on first mention.")
    return "\n".join(lines)

Passing this instruction into gen_pair is enough to fix the terms you care about. In my experience this mattered most. The schema handles "structural agreement"; the glossary pin handles "lexical agreement." Only with both does the reader's snag go away.

Detect drift mechanically

The model honors most of it, but not 100%. Before shipping, add a thin verification that checks the output against the glossary. Two checks were enough.

The first is term presence: for any paragraph where the Japanese body shows a glossary ja term, confirm the matching English body shows the en term. The second is length ratio: any section whose Japanese/English length ratio falls far outside a band is suspected of compressing one side.

def check_terms(article: "Article", glossary: list[dict]) -> list[str]:
    issues = []
    for i, sec in enumerate(article.sections):
        for g in glossary:
            ja_hit = g["ja"] in sec.body_ja
            en_hit = g["en"].lower() in sec.body_en.lower()
            if ja_hit and not en_hit:
                issues.append(f'section {i}: has "{g["ja"]}" / missing "{g["en"]}"')
        if sec.body_ja and sec.body_en:
            ratio = len(sec.body_en) / max(len(sec.body_ja), 1)
            if ratio < 0.6 or ratio > 3.0:
                issues.append(f"section {i}: length ratio {ratio:.2f} out of band")
    return issues

This verification spends no tokens — it runs instantly, locally. The pitfall is the threshold. English tends to run longer in character count, so a too-strict lower bound flags healthy sections. I run a 0.6 lower and 3.0 upper bound, and false positives nearly vanished.

Fallback: partial regeneration

When verification flags something, rebuilding the whole article is wasteful. Regenerate only the offending section, with the glossary and the surrounding context attached.

JSON parse failures happen occasionally — that comes with structured output. In that case I retry once under the same conditions, and if it still collapses, I temporarily fall back to the old two-call method so the day's publishing does not stop. In production, "do not stop" comes first, and quality is held by the verification side.

Measured: tokens, latency, cost

Here is what actually changed, pulled from my own generation logs. The comparison uses Gemini 3.5 Flash on articles of roughly 6–8 sections per language. The numbers are averages from my workflow and move with the topic.

Input tokens drop because the two-call method sent the glossary and shared premises twice. One call sends the shared part once. Latency roughly halves because two serial waits become one. On cost, the input-token savings lower the per-generation price — and that compounds the more articles you publish.

When to stop using one call

Finally, this method is not always optimal, so here is when I revert to two calls:

1. When an article is very long and pairing both languages hits the output-token ceiling
2. When I deliberately want different structures per language (swapping examples for an English audience)
3. When a workflow swaps only one language often, making it wasteful to regenerate the other every time

Conversely, for short-to-mid articles where translation consistency is the core of quality, I recommend one call plus a pinned glossary. I made it the default for Dolice's paired bilingual posts. The deciding axis is whether you want the model to settle the translation consistency simultaneously, or to optimize each language independently. Answer that first, and the choice gets easier.

Translation drift is small one at a time, but it quietly erodes a reader's trust as it stacks up. Pair the structure in the schema, fix the vocabulary with a glossary, and close the escape hatches with verification. With those three in place, multilingual operation gets a lot lighter. I hope this helps anyone running Japanese and English side by side.