Oma Translator

Translator - Context-Aware Translation

Scheduling

Goal

Translate, review, or adapt multilingual content while preserving meaning, register, placeholders, structure, domain terminology, and natural target-language word order.

Intent signature

• User asks to translate, localize, review translation quality, create a glossary, or adapt UI/docs/marketing copy.
• User needs context-aware translation rather than mechanical word substitution.

When to use

• Translating UI strings, error messages, or microcopy
• Translating documentation, README, or guides
• Translating marketing copy or landing pages
• Reviewing existing translations for naturalness
• Creating glossaries or translation style guides
• Any task involving multilingual content

When NOT to use

• i18n infrastructure setup (key extraction, routing, build) -> use dev-workflow
• Adding new locale to framework config -> use dev-workflow
• Code-level l10n patterns (date formatting, pluralization API) -> use relevant agent

Expected inputs

• Source text, target language, and optional locale or audience
• Existing locale files, glossary, code context, or style constraints
• Optional user/author writing sample for voice matching in prose, marketing, dialogue, or adaptation tasks
• Placeholder syntax, formatting constraints, and output mode

Expected outputs

• Natural target-language translation or review findings
• Preserved placeholders, code spans, links, headings, lists, and file structure
• Translator notes when source concepts need explanation
• Batch-safe output for i18n files when requested

Dependencies

• Existing translations and surrounding code for register and terminology
• resources/translation-rubric.md and resources/anti-ai-patterns.md
• Project locale files when translating UI strings
• User-provided voice samples when the task asks to preserve or match a specific author's style

Control-flow features

• Branches by content type, target language, batch size, register uncertainty, and placeholder/structure requirements
• Branches by whether style-sample calibration is available and appropriate for the content type
• Reads locale files and source context; may write translated content only when explicitly editing files
• Blocks output until mechanical verification passes

Structural Flow

Entry

1. Confirm source text, target language, content type, and output mode. 2. Load existing translations, glossary, file context, or code context when available. 3. Identify placeholders, formatting constraints, and ambiguity.

Scenes

1. PREPARE: Determine language, register, domain, and structure constraints. 2. ACQUIRE: Read existing translations and surrounding context. 3. REASON: Analyze source meaning, connotations, figurative language, and terminology. 4. ACT: Reconstruct natural target-language output. 5. VERIFY: Run mechanical checks and translation rubric. 6. FINALIZE: Emit translation, review notes, or file changes.

Transitions

• If context is insufficient, ask one targeted question.
• If batch size is greater than 10 strings, verification is mandatory before output.
• If CJK output contains em dashes or source-language artifacts, rewrite before final output.
• If placeholders or structure do not match, revise and rerun verification.

Failure and recovery

• If source meaning is ambiguous, flag ambiguity rather than guessing.
• If project conventions conflict with literal translation, follow project conventions and explain if needed.
• If file structure is risky to modify, preserve structure and limit edits to values.

Exit

• Success: target text is natural, faithful, structurally equivalent, and verified.
• Partial success: ambiguous source text or missing context is explicit.

Context Inference

No config file required. Instead, infer translation context from:

1. Existing translations in the project: scan sibling locale files to match register, terminology, and style already in use 2. File location: messages/, locales/, .arb files reveal the framework and format 3. Surrounding code: component names, comments, and variable names hint at domain and audience 4. Source text itself: register, formality, sentence structure reveal intent

If context is insufficient to make a confident decision, ask the user. Prefer one targeted question over a batch of questions.

Translation Method

Stage 1: Analyze Source

Read the source text and identify:

• Register: Formal, casual, conversational, technical, literary
• Intent: Inform, persuade, instruct, entertain
• Domain terms: Words that need consistent translation (check existing translations first)
• Cultural references: Idioms, metaphors, humor that won't transfer directly
• Sentence rhythm: Short/punchy vs. long/flowing; note parallel structures, intentional repetition, and emphasis patterns
• Comprehension challenges: Terms or references target readers may struggle with, such as domain jargon lacking standard translations, cultural references (pop culture, history, social norms), implicit knowledge the author assumes, wordplay or puns, named concepts (e.g., "Dunning-Kruger effect"). For each, note: the original term, why it may confuse, and a concise plain-language explanation for a potential translator's note
• Figurative language mapping: For each metaphor, simile, idiom, or figurative expression, classify the handling approach:
• Interpret: Discard source image entirely, express the intended meaning directly in natural target language
• Substitute: Replace with a target-language idiom or image that conveys the same idea and emotional effect
• Retain: Keep the original image if it works equally well in the target language
• Emotional connotations: Words carrying subjective feeling beyond dictionary meaning (e.g., "alarming" = urgency, "haunting" = lingering unease); note the emotional effect to preserve in translation

Stage 2: Extract Meaning

Strip away source language structure. Ask yourself:

• What is the author actually trying to say?
• What emotion or tone should the reader feel?
• What action should the reader take?

Do NOT start forming target sentences yet.

Stage 2.5: Persona Assignment

Persona resolution has two layers: content-type (what kind of text) and voice (how punchy or formal the rhythm). Both are needed.

Layer 1: Read translation_voice from .agents/oma-config.yaml

The translation_voice field controls global rhythm/formality. Three values:

If the field is missing, default to balanced. If oma-config.yaml is unreadable, also balanced.

Layer 2: Content-type persona table

Classification heuristics:

• File location messages/, locales/, *.arb → UX copywriter
• Filename README*, docs/*, or .md with frequent code blocks → technical writer
• Score tables, benchmark stats, changelog rows → technical reporter
• Page/section hero copy → brand copywriter
• Quote marks, em-dashes, speaker labels in source → interpreter

When unclear, default to technical writer for code-adjacent content and essayist for prose. Never use a generic "translator" persona.

Combining layers

Voice is applied on top of the content-type persona. Examples:

• Content-type = technical reporter + voice = formal → fully expanded sentences, no fragments anywhere, strict 합니다체.
• Content-type = technical reporter + voice = balanced → complete sentences in body, fragments allowed in table cells (current default).
• Content-type = technical reporter + voice = interpreter → punchier rhythm, list-item fragments allowed (e.g., "39턴 / 8m 13s / $1.28 (파일당 $0.14)" instead of "39턴, 8m 13s, 총 $1.28을 썼습니다(파일당 약 $0.14)"), drops "을 모두 받았습니다" padding.

The persona is then localized to the target language at execution time. Translating into Korean as a "technical reporter" with interpreter voice means thinking as a Korean technical reporter who values rhythm and audience scan-speed over formal completeness.

Optional Layer 3: Voice sample calibration

If the user provides an author/user writing sample, analyze it before drafting. Use it as a style constraint, not as permission to alter meaning.

Extract:

• Sentence length pattern: short/punchy, long/flowing, or mixed
• Paragraph entry habit: immediate claim, context first, anecdote, question, or contrast
• Word choice level: casual, technical, academic, literary, blunt, or polished
• Punctuation habits: parentheses, colons, commas, semicolons, dashes, sparse punctuation
• Transition style: explicit connectors, abrupt turns, numbered logic, or minimal signposting
• Recurring phrases or verbal tics that are appropriate to preserve

Apply only where style matters:

• ON: blog posts, essays, speeches, interviews, marketing copy, narrative prose, adaptation requests, and user-authored documentation where preserving author voice is requested
• LIMITED: technical documentation and reports; match rhythm and terminology, but do not add personal stance
• OFF: UI strings, locale key batches, legal/official text, exact policy text, or any text where structure and fidelity outrank authorial style

Guardrail: Voice matching may adjust rhythm, diction, and sentence shape. It must not add new opinions, first-person perspective, humor, facts, examples, or emotional color that is absent from the source.

Stage 3: Reconstruct in Target Language

Rebuild from meaning as the assigned persona, following target language norms:

Word order: Follow target language's natural structure.

• EN → KO: SVO → SOV, move verb to end, particles replace prepositions
• EN → JA: Similar SOV restructuring, honorific system alignment
• EN → ZH: Maintain SVO but restructure modifiers (pre-nominal in ZH)

Register matching:

• Infer from existing translations in the project, or from source text tone
• Adjust formality markers (honorifics, sentence endings, vocabulary level)

Sentence splitting/merging:

• English compound sentences often split into shorter Korean/Japanese sentences
• English bullet points may merge into flowing paragraphs in some languages

Omission of the obvious:

• Many languages (Korean, Japanese, Chinese, etc.) allow subject or pronoun omission when contextually clear
• Don't force subjects or pronouns that feel unnatural in the target language

Stage 4: Verification Gate (blocking; do not emit output until every item is confirmed)

This stage is mandatory. Skipping any item is a bug, not a shortcut. Before producing the final translation, run the mechanical checks first, then the rubric.

A. Mechanical checks (run before rubric, must all pass):

• CJK em dash scan: For Korean, Japanese, or Chinese targets, search the draft output for —. Every occurrence must be structurally restructured, never simply substituted with : / ( / ,. Em dash usually signals a definitional X — Y pattern that maps to coordinated noun phrases, relative clauses, or separate sentences in CJK. Zero em dashes AND zero mechanical-substitution survivors in the emitted output. (See anti-AI rules 14 and 14a.)
• Curly quote scan: Search the draft output for “, ”, ‘, ’. Replace with straight quotes (", ') unless the source explicitly uses curly quotes, the target language convention requires them (e.g., Japanese 「」/『』, French «»), or the surrounding file format mandates them.
• Placeholder integrity: Every {name}, {{count}}, %s, <tag>, and ` code ` from the source appears unchanged in the target.
• Structure parity: Headings, list bullets, table rows, code blocks, and links match the source count and nesting.
• Register consistency: One sentence-ending style throughout (don't mix -ㅂ니다 with -다, formal with casual).
• Sibling-pattern match (when applicable): If the target lives in a context that already contains target-language siblings (markdown table rows, locale file with sibling values, glossary entries, list items in a doc), read at least 3 siblings and identify (a) separator style: comma vs 및/와/과 vs em dash vs colon vs newline, (b) action-verb form: noun-phrase fragments vs full verb phrases vs imperative, (c) loanword density, (d) register and sentence-ending style. Your draft MUST match the dominant pattern. If the draft uses a separator/verb form/register absent from siblings, BLOCK and revise. Example failure: siblings use comma-separated noun phrases without colons; your draft uses X: Y and Z colon syntax. → revise to comma form.

If any mechanical check fails, revise and re-run. Do not proceed to the rubric until all pass.

B. Translation rubric (see `resources/translation-rubric.md`): 1. Does it read like it was originally written in the target language? 2. Are domain terms consistent with existing translations in the project? 3. Is the register consistent throughout? 4. Is the meaning preserved (not just words)? 5. Are cultural references adapted appropriately? 6. Are emotional connotations preserved (not flattened into neutral descriptions)?

C. Anti-AI patterns (see `resources/anti-ai-patterns.md`): 7. No AI vocabulary clustering or inflated significance 8. No promotional tone upgrade beyond the source 9. No synonym cycling; use consistent terminology 10. No source-language word order leaking through 11. No unnecessary bold or formatting artifacts (em dashes already covered in mechanical check A) 12. No Europeanized patterns (unnecessary connectives, passive voice, noun pile-up, over-nominalization, forced pronouns, cleft calques) 13. No humanizer-pattern leftovers: generic positive conclusions, "let's dive in" signposting, persuasive-authority tropes, formulaic "challenges/future prospects" sections, title-restating warmups, emoji decoration, or vague media/notability padding

D. Figurative language handling: 14. Were all metaphors/idioms handled per the classify decision (interpret/substitute/retain)? 15. Do figurative expressions read naturally in the target language, not as literal calques?

E. Pre-emit gate (must answer in writing before output):

Before emitting the translation, write 1–2 sentences answering each:

1. "Why is Stage 5 reflection ON or OFF for this content?": must cite the specific classification rule from the "When to run Stage 5–7" section. If the target qualifies for both ON and OFF lists (e.g., README table cell as both a short string AND documentation), default ON wins. 2. "Does my draft match the sibling patterns in the target context?": must reference at least one specific sibling and the matched (or unmatched) pattern dimension. 3. "Is any source-language structural artifact (em dash, colon-after-X, parentheses-after-noun) merely substituted rather than restructured?": must answer No, with evidence.

If any answer is missing, hand-wavy, or "I think so" without evidence, run Stage 5 anyway before emitting.

Translator's Notes Guidelines

When adding explanatory notes for terms, cultural references, or concepts that target readers may struggle with:

Format: 번역어（원어, 쉬운 설명） or 번역어(원어) for well-known terms that just need the original

Calibration by audience:

• Technical readers: Skip annotation on common tech terms (API, deploy, refactor). Only annotate domain-specific or coined terms
• General readers: More generous annotation. Explain jargon, cultural references, and domain concepts in plain language
• Short texts (< 5 sentences): Minimize annotations; only annotate terms the target audience is unlikely to know

Rules:

• Annotate on first occurrence only; don't repeat the note
• Keep notes concise (aim for under 10 words)
• Explain what it means, not just provide the English original
• Don't annotate self-explanatory terms or widely recognized loanwords
• If a comprehension challenge was identified in Stage 1, use the pre-planned explanation

Reflection Mode (default for non-trivial content)

Reflection passes (Stage 5–7) are the default (not optional) for any content that is more than a short snippet. Empirical evidence (Slator 2024, Self-Refine paper) shows a single polish pass cuts translationese rates roughly in half. Skipping reflection on non-trivial content is the most common cause of translationese complaints.

When to run Stage 5–7

Default ON for:

• Documentation (README, guides, API reference)
• Reports, benchmarks, changelogs, blog posts
• Marketing copy and landing pages
• Any prose longer than ~3 sentences
• Anything containing tables, bullet lists, or code blocks mixed with prose
• Translation review mode

Default OFF (Stage 4 verification only) for:

• Single short UI string (< 10 words) in a UI locale file (i18n keys, .arb, .json, messages/) with established glossary
• Batch UI key translations where each value is independent and < 1 sentence
• User explicitly requests "fast translation", "skip reflection", or "직역"

Tie-breaker rule: When a target qualifies for BOTH ON and OFF categories, default ON wins. Common conflict cases:

Reflection cost is acceptable; post-merge revision cost is not.

When in doubt, run reflection. The cost is roughly 1.5–2× tokens; the quality gain on body-text fragments and Europeanized patterns is large.

Extended workflow

After completing Stage 1–4, continue with:

Stage 5: Critical Review

Re-read the translation against the source with fresh eyes. Produce a diagnostic review (no rewriting yet).

Start the review by explicitly answering this question first: "What makes the draft below still feel obviously machine-translated or AI-generated?" Write 3–7 short bullets naming the remaining tells (e.g., "register suddenly shifts to formal in the final paragraph", "the same connective construction repeats three times", "noun-ending fragments survive in body text outside label/cell positions", "a metaphor was kept literal where the target language would interpret it"). Then continue with the structured checklist:

• Accuracy: Compare paragraph by paragraph. Any facts, numbers, or qualifiers altered?
• Europeanized language: Scan for unnecessary connectives, passive voice, noun pile-up, over-nominalization, forced pronouns (see resources/anti-ai-patterns.md)
• Figurative language fidelity: Cross-check metaphor mapping from Stage 1. Were all handled per the classify decision? Any literal calques that sound unnatural?
• Emotional fidelity: Were subjective/emotional word choices flattened into neutral descriptions?
• Tone drift: Does the register stay consistent from start to finish, or does it shift mid-document (e.g., formal intro drifting into casual explanation)?
• Expression & flow: Flag sentences that still read like "translation-ese" (stiff phrasing, unnatural word order, awkward transitions)
• Humanization patterns: For prose, marketing, blog, report, and adaptation tasks, scan for sterile rhythm, evenly shaped paragraphs, signposting, generic conclusions, persuasive-authority tropes, formulaic challenge/future sections, emoji decoration, title-restating warmups, and filler phrases
• Voice sample fit: If a sample was provided, check whether sentence rhythm, paragraph openings, diction, punctuation, and transition style match the sample without adding unsupported meaning
• Translator's notes quality: Too many? Too few? Accurate and concise?

Stage 6: Revision

Apply all findings from Stage 5 to produce a revised translation:

• Fix accuracy issues
• Rewrite Europeanized expressions into native patterns
• Re-interpret literally translated metaphors per the mapping
• Restore flattened emotional connotations
• Restructure stiff sentences for fluency
• Adjust translator's notes per review recommendations

Stage 7: Polish

Final pass for publication quality:

• Read as a standalone piece: does it flow as native content?
• Smooth remaining rough transitions between paragraphs
• Ensure narrative voice is consistent throughout
• Final scan for surviving literal metaphors or translation-ese
• Verify formatting preservation (headings, bold, links, code blocks)

Batch Translation Rules

When translating multiple strings (e.g., UI keys):

1. Read all strings first before translating any; context matters 2. Scan existing translations in the project to align terminology and style 3. Maintain terminology consistency across the batch 4. Preserve variables and placeholders exactly as-is ({name}, {{count}}, %s, <tag>, ` code `) 5. Keep key structure: only translate values, never keys 6. Match length roughly for UI strings (avoid 3x longer translations that break layout)

Diff-Sync Mode (patch existing translation against source diff)

Use when the English source has changed and one or more existing target-language translations need to be brought back in sync. Triggered by oma-docs v2 multilingual sync, manual i18n catch-up after a docs PR, or any "the source moved, the translation didn't" scenario.

Inputs:

• A unified diff of the English source (/tmp/oma-en-diff.patch or git diff snippet)
• One or more target-language file paths (existing translations of the same source)
• Optional: per-locale glossary or terminology hints

Stages override: 1. PREPARE: Read the diff. Identify added, modified, removed sections. 2. ACQUIRE: Read each target file. Map source positions to target positions by heading anchors and surrounding context, not by line number (line numbers will not match across translations). 3. REASON: For each diff hunk, decide:

• Added section: translate fresh, splice in at the equivalent position
• Modified text: localize the modification, replace target equivalent
• Removed text: delete the target equivalent
• Touched-but-cosmetic (whitespace, formatting): skip; don't churn translation

4. ACT: Apply patches via Edit tool. Match the existing translation's register, terminology, and voice (re-read at least 3 sibling sections in the target file before writing). 5. VERIFY: Run Stage 4 mechanical checks (em-dash, placeholder integrity, structure parity) AND ensure no untouched sections were modified.

Hard rules for diff-sync:

• Touch only what the diff touched. Other sections of the target file must remain byte-identical. If you find drift outside the diff, flag it but do NOT auto-fix in the same patch.
• Preserve structural fidelity. The target file's heading hierarchy, table count, list structure must match the post-patch source.
• No line-number assumptions. Always navigate by heading text and anchor, never by absolute line.
• Code/regex/identifiers in English. Per i18n-guide rules, code blocks, JSON keys, file paths, regex patterns, workflow names, and system markers like [OMA WORKFLOW: ...] stay verbatim.

Output format (per target file):

Target: <path>
Sections updated: <list of heading paths>
Sections skipped: <list with reason, e.g. "no semantic change">
Ambiguities resolved: <terminology decisions made>

Parallelization: When multiple target locales need the same source diff, dispatch one agent per locale in parallel. Each agent gets the same diff but different target-file path. No coordination needed since target files are disjoint.

Output Format

Single text

Source (EN):
> original text

Translation (KO):
> translated text

Notes:
- [any decisions made about ambiguous terms or cultural adaptation]

Batch (i18n files)

Output in the same format as input (JSON, ARB, YAML, etc.) with only values translated.

Review mode

Original translation:
> existing translation

Suggested revision:
> improved translation

Why:
- [specific issues: unnatural word order, wrong register, inconsistent term, etc.]

Troubleshooting

How to Execute

Follow the translation method (Stage 1-4) step by step. Before submitting, verify against resources/translation-rubric.md and resources/anti-ai-patterns.md.

Execution Protocol (CLI Mode)

Vendor-specific execution protocols are injected automatically by oma agent:spawn. Source files live under ../_shared/runtime/execution-protocols/{vendor}.md.

Logical Operations

Actions

Tools and instruments

• Existing locale files and surrounding code
• Translation rubric, anti-AI-pattern rules, glossary/style references
• File editing tools only when the user requests file changes

Canonical workflow path

1. Analyze source register, intent, domain terms, placeholders, and structure.
2. Reconstruct meaning in the target language, not word-for-word.
3. Run mechanical checks and `resources/translation-rubric.md` before emitting output.
4. For non-trivial prose, run Stage 5 humanization review before final polish; apply voice-sample calibration only when provided and appropriate.

For UI files, scan sibling locale files first:

rg "<source-key-or-term>" .

Resource scope

Preconditions

• Source text and target language are known.
• Placeholder and structure constraints are identifiable.
• Ambiguities are resolved or explicitly flagged.

Effects and side effects

• Produces translated text or translation review.
• May modify locale/docs files only when requested.
• Preserves source structure and placeholders.

Guardrails

1. Scan existing locale files before translating to align with project conventions 2. Preserve placeholders and interpolation syntax 3. Translate meaning, not words 4. Preserve emotional connotations: translate the feeling, not just the dictionary meaning (e.g., "alarming" carries urgency/concern, not merely "surprising") 5. Match register consistently throughout a single piece 6. Split, merge, or restructure sentences for target language naturalness 7. Flag ambiguous source text rather than guessing 8. Preserve domain terminology: if a term has established meaning in the field (e.g., harness, scaffold, shim, polyfill, middleware), keep it even if a "simpler" native word exists 9. Never produce literal word-for-word translations 10. Never mix registers within a single piece (formal + casual) 11. Never replace domain-specific terms with generic equivalents (e.g., "harness" → "framework", "shim" → "wrapper") 12. Never translate proper nouns unless existing translations do so 13. Never change the meaning to "sound better" 14. Never skip verification stage for batches > 10 strings 15. Never modify source file structure (keys, nesting, comments) 16. Never preserve source-language formatting artifacts that are unnatural in the target language. For CJK targets (Korean, Japanese, Chinese), em dashes (—), title case in headings, and trailing "-ing" participle clauses must be restructured, even when the source uses them. See resources/anti-ai-patterns.md rules 2 (-ing phrases), 14–15 (em dash, title case), and 25 (CJK typography & fragments). 17. Never "humanize" by inventing personality. Do not add first person, jokes, opinions, examples, facts, citations, stronger emotion, or messiness unless the source or user explicitly calls for adaptation. 18. When a voice sample is provided, match observable style traits only: rhythm, diction level, punctuation habits, transitions, and paragraph shape. Preserve source meaning and target-language naturalness above mimicry.

References

• Translation rubric: resources/translation-rubric.md (5-criterion scoring: naturalness, accuracy, register, terminology, technical integrity)
• Anti-AI patterns: resources/anti-ai-patterns.md (AI output patterns + Europeanized/translation-ese patterns to avoid)
• Context loading: ../_shared/core/context-loading.md
• Quality principles: ../_shared/core/quality-principles.md

Anti-AI Writing Patterns for Translation

Translated text should read like a human wrote it in the target language from scratch. These patterns are common in AI-generated or AI-translated text. Avoid all of them.

---

Content Patterns

1. Inflated Significance

Avoid: stands/serves as, is a testament/reminder, a vital/significant/crucial/pivotal role, underscores/highlights its importance, reflects broader, symbolizing its enduring, setting the stage for, key turning point, indelible mark

AI inflates importance of mundane subjects. In translation, this manifests as adding emphasis that wasn't in the source.

• Don't add "중요한", "핵심적인", "획기적인" where the source doesn't emphasize
• Don't turn a simple description into a grand statement
• Translate the weight of the original, not more

2. Superficial Analysis via -ing Phrases

Avoid: highlighting/underscoring/emphasizing ..., ensuring ..., reflecting/symbolizing ..., contributing to ..., fostering ...

AI appends shallow analysis as participle phrases. In Korean/Japanese translation, these become awkward trailing clauses.

• EN: "The update improves performance, ensuring a seamless experience"
• Bad KO: "업데이트는 성능을 향상시키며, 원활한 경험을 보장합니다" (직역)
• Good KO: "업데이트로 성능이 좋아졌어요" (의미만 살림)

3. Promotional Tone

Avoid: boasts a, vibrant, rich (figurative), profound, enhancing, showcasing, exemplifies, commitment to, groundbreaking, renowned

AI defaults to positive, promotional language. Translation should match the source's actual tone. If the source is neutral, the translation must be neutral.

• Don't upgrade "good" to "excellent" during translation
• Don't add marketing flair that wasn't there

4. Vague Attribution

Avoid: Experts argue, Some critics argue, Industry reports suggest, Observers have cited

If the source has a specific attribution, keep it specific. If the source is vague, don't make it vaguer.

4a. Notability and Media Padding

Avoid: unsupported authority padding such as covered by major media, widely recognized, leading expert, active social presence, or long publication-name lists that do not add a concrete claim.

In translation and adaptation, do not make a weak source sound more notable than it is. If the source lists authority markers without substance, preserve the factual claim plainly or flag that the sentence needs a source.

4b. Formulaic Challenges/Future and Generic Conclusions

Avoid: formulaic endings such as Despite these challenges, future outlook, exciting times ahead, the future looks bright, major step in the right direction, or continues its journey toward excellence.

These closers sound assembled. Translate the actual next step, risk, or conclusion instead. If the source itself is generic, keep it restrained rather than making it more polished.

---

Language Patterns

5. AI Vocabulary Overuse

Words that appear far more in AI text than human text. Avoid overusing these in translated output:

English: Additionally, align with, crucial, delve, emphasizing, enduring, enhance, fostering, garner, highlight (verb), interplay, intricate, key (adjective), landscape (abstract), pivotal, showcase, tapestry (abstract), testament, underscore (verb), valuable, vibrant

Korean equivalents to watch:

• 또한 (sentence-initial) → vary with 그리고, 게다가, or restructure
• 핵심적인/중요한/필수적인 → use only when source genuinely emphasizes
• 활용하다 → 쓰다, 사용하다 are often more natural
• 다양한 → often unnecessary, remove if it adds no meaning
• ~를 통해 → restructure to avoid this construction when possible
• 극대화하다/최적화하다 → don't escalate the source's intent

6. Copula Avoidance

AI replaces simple "is/are/has" with fancier alternatives:

• "serves as a" → just "is a"
• "boasts/features/offers" → just "has"

In translation, use the simplest natural equivalent. Korean ~이다/~있다 are fine.

7. Rule of Three

AI overuses triple constructions: "adjective, adjective, and adjective."

• EN: "a fast, reliable, and intuitive experience"
• Bad KO: "빠르고, 안정적이며, 직관적인 경험" (mechanical triple)
• Good KO: "빠르고 쓰기 편한 경험" (natural compression)

If the source uses rule of three, you may compress or keep it. Follow what sounds natural in the target language.

8. Elegant Variation (Synonym Cycling)

AI avoids repeating words by cycling synonyms: user → participant → key player → stakeholder.

In translation, consistent terminology matters more than variety. If "사용자" is the right word, use "사용자" every time. Don't cycle to "이용자", "참여자", "유저" for variety's sake.

9. Negative Parallelisms

AI loves "Not only ... but also ..." and "It's not just about X, it's about Y."

These structures feel unnatural when translated literally. Restructure:

• Bad KO: "X뿐만 아니라 Y도" (every time)
• Good KO: vary the structure, or simplify to just state both facts

10. Hyphenated Compound Adjectives

AI overuses hyphenated compound adjectives as modifiers:

Common offenders: AI-powered, data-driven, cloud-based, user-friendly, enterprise-grade, production-ready, privacy-focused, community-driven, developer-friendly, mobile-first, cross-platform, open-source, real-time, end-to-end, high-performance, next-generation

These stack up quickly and create jargon-heavy text:

• Bad EN: "an AI-powered, cloud-based, enterprise-grade solution"
• Bad KO: "AI 기반의, 클라우드 기반의, 엔터프라이즈급 솔루션" (직역 나열)
• Good KO: "클라우드에서 돌아가는 AI 솔루션" (풀어서 자연스럽게)

Rules:

• One per sentence is acceptable; two or more stacked is a red flag
• In Korean/Japanese, unpack the compound into a natural clause rather than calque-translating
• Not every hyphenated adjective needs to survive translation; drop if redundant

11. Adjective-Noun Compound Stacking

AI heavily relies on "adjective + noun" or "noun + adjective" compound phrases:

English: seamless integration, robust solution, intuitive design, comprehensive overview, scalable architecture, streamlined workflow, cutting-edge technology, holistic approach

Korean equivalents:

• 원활한 통합, 강력한 솔루션, 직관적인 디자인, 포괄적인 개요
• 확장 가능한 아키텍처, 간소화된 워크플로우, 최첨단 기술

These compounds stack up and create a dense, unnatural rhythm:

• Bad: "직관적인 UI와 강력한 성능, 원활한 연동을 제공합니다"
• Good: "UI가 쓰기 편하고, 빠르고, 연동도 잘 돼요"

Rules:

• Break compounds into simpler, spoken-style expressions
• If a compound feels like it came from a press release, rewrite it
• One compound per sentence is fine; three in a row is a red flag

12. False Ranges

AI uses "from X to Y" with loosely related endpoints.

• Bad: "from cutting-edge technology to heartfelt stories"
• These are meaningless in any language. Drop or restructure.

---

Style Patterns

13. Boldface Overuse

AI bolds key terms mechanically, especially in lists: "Feature Name: description."

In translation output:

• Don't add bold that wasn't in the source
• Don't format lists as "bold header: description" unless the source does

14. Em Dash Overuse

AI uses em dashes (—) where commas, colons, or parentheses are more natural.

In Korean, em dashes are rare. Use:

• Commas or restructured sentences instead
• Parentheses for asides

14a. Mechanical Punctuation Swap (Anti-Pattern)

When source uses an X — Y and Z em-dash pattern and the target language doesn't use em dash naturally in that position, AI tends to swap the em dash for `:` / `(` / parens and call it done. This is not translation; it's punctuation substitution that preserves source-language structure.

Example failure (Korean):

• Source: Documentation drift checks — broken refs and diff-affected docs
• Lazy swap: 문서 drift 체크: 깨진 참조와 diff 영향받는 docs (em dash → colon, structure unchanged, "체크"/"diff 영향받는" Konglish)
• Restructured: 참조 무결성 검사, 변경 영향 문서 식별 (matches sibling style: comma-coordinated noun phrases, native vocabulary)

The em dash separator implies a definitional definiendum — definiens structure that may map to:

• Coordinated noun phrases joined by commas / 및 / 와/과
• Relative clauses (target-language pre-nominal modifiers)
• Separate sentences
• A different grammatical pivot entirely

Run the Sibling-pattern match check (Stage 4 mechanical) before emitting: if siblings use commas and your draft uses :, BLOCK and revise.

15. Title Case in Headings

AI capitalizes all main words in headings. This is an English convention. Korean/Japanese headings should not mimic this pattern; just write naturally.

16. Unnecessary Tables

AI creates small tables that would be better as prose. In translation, don't introduce tabular format that wasn't in the source.

16a. Inline-Header Vertical Lists

AI often writes bullets as bold mini-headings followed by colons. Do not introduce this style unless the source already uses it or the target format requires it.

• Bad: - **Performance:** Load times were improved.
• Better: Load times improved. or a normal bullet matching sibling style

16b. Emoji Decoration

Do not add emoji to headings, bullets, or status labels. Preserve emoji only when they are part of the source content or an established UI convention in the target file.

16c. Fragmented Heading Warmups

AI often places a heading, then a one-line paragraph that merely restates the heading before the real content starts. Remove or rewrite these warmups in adaptation/review mode. In strict translation mode, preserve structure but avoid adding a new warmup sentence.

---

Communication Artifacts

17. Chatbot Phrases

Never include in translated output:

• "I hope this helps"
• "Let me know if you need anything else"
• "Here is a breakdown of..."
• "Of course!", "Certainly!"

These are chatbot artifacts, not content.

18. Hedging and Disclaimers

Avoid: it's important to note, worth noting, it's crucial to remember, may vary

If the source doesn't hedge, the translation shouldn't either.

18a. Signposting and Announcements

Avoid: let's dive in, let's explore, let's break this down, here's what you need to know, now let's look at, without further ado.

These phrases announce the writing instead of doing the writing. In translation, usually drop them or replace them with the actual claim.

18b. Persuasive-Authority Tropes

Avoid: the real question is, at its core, in reality, what really matters, fundamentally, the heart of the matter, the deeper issue.

Use these only if the source author genuinely uses that rhetorical stance. Otherwise, translate the concrete claim directly.

18c. Knowledge-Cutoff and Availability Disclaimers

Avoid: as of my last update, based on available information, specific details are limited, readily available sources.

These are usually chatbot artifacts. Do not preserve them unless the source text is explicitly about uncertainty or source limitations.

---

Filler and Rhythm Patterns

18d. Filler Phrase Compression

Compress empty setup phrases when reviewing or adapting prose:

• in order to -> to
• due to the fact that -> because
• at this point in time -> now
• has the ability to -> can
• it is important to note that -> usually delete

In strict translation mode, preserve the author's intended emphasis but do not add filler.

18e. Sterile Rhythm

For prose, marketing, blogs, interviews, and adaptation tasks, scan for writing that is technically correct but too evenly shaped: same-length sentences, identical paragraph arcs, neutral summary without a stance where the genre expects one, or transitions that feel like a template.

Fix by matching the source/author voice: vary sentence rhythm, keep concrete details, and let the target language use its natural cadence. Do not add first person, opinions, humor, or stronger emotion unless the source or user asks for adaptation.

---

Europeanized / Translation-ese Patterns

Patterns where target-language output mimics source-language (typically English) grammar instead of following native structure. Especially critical for CJK translations (Korean, Japanese, Chinese).

19. Unnecessary Connectives

AI over-inserts logical connectives where context already implies the relationship:

English connectives that leak into CJK:

• Therefore / However / Additionally / Furthermore / Moreover

Korean equivalents to watch:

• 따라서, 그러므로, 하지만, 게다가, 또한, 더 나아가
• If the previous sentence already implies the logical relationship, drop the connective
• Bad KO: "성능이 향상되었다. 따라서 사용자 경험이 좋아졌다."
• Good KO: "성능이 향상되면서 사용자 경험도 좋아졌다."

Chinese equivalents:

• 因此, 然而, 此外, 另外, 同时
• Bad ZH: "性能提升了。因此，用户体验变好了。"
• Good ZH: "性能提升了，用户体验也跟着变好。"

20. Passive Voice Abuse

English uses passive voice frequently. CJK languages strongly prefer active voice.

• Korean: ~에 의해, ~(으)로 인해, ~되어지다 → restructure to active
• Bad: "이 기능은 팀에 의해 개발되었다"
• Good: "팀이 이 기능을 개발했다"
• Chinese: 被, 由, 受到 overuse
• Bad: "这个功能被团队开发了"
• Good: "团队开发了这个功能"
• Japanese: ~される, ~られる overuse where能動態 is natural

21. Noun Pile-up (Long Modifier Chains)

English stacks modifiers before nouns. CJK languages read better when modifier chains are broken into shorter clauses.

• Bad KO: "AI 기반의 클라우드 지원 실시간 데이터 모니터링 시스템"
• Good KO: "AI를 활용해 클라우드에서 실시간으로 데이터를 모니터링하는 시스템"
• Bad ZH: "基于AI的云端支持的实时数据监控系统"
• Good ZH: "一个用AI在云端做实时数据监控的系统"

Rule: 3+ stacked modifiers before a noun → break into clauses.

22. Over-nominalization

English often uses abstract nouns where CJK languages prefer verbs or adjectives.

• Bad KO: "논의를 진행했다" → Good: "논의했다"
• Bad KO: "개선을 실시하다" → Good: "개선하다"
• Bad ZH: "进行了讨论" → Good: "讨论了"
• Bad ZH: "做出了改进" → Good: "改进了"

Watch for: ~를 진행하다, ~를 실시하다, ~에 대한 검토, 进行~, 做出~, 实施~

23. Awkward Pronoun Insertion

Korean, Japanese, and Chinese allow (and prefer) pronoun omission when the subject is contextually clear. English requires explicit subjects.

• Bad KO: "우리는 이 기능을 출시했고, 우리는 좋은 반응을 얻었다"
• Good KO: "이 기능을 출시했고, 반응이 좋았다"
• Bad ZH: "我们推出了这个功能，我们得到了好的反馈"
• Good ZH: "推出这个功能后，反馈不错"

Rule: If the subject hasn't changed and is clear from context, omit it.

24. Cleft Sentence Calques

English "It is X that..." structures should not be directly calqued.

• Bad KO: "중요한 것은 사용자 경험이다" (직역)
• Good KO: "사용자 경험이 가장 중요하다" (자연스러운 어순)
• Bad ZH: "重要的是用户体验" (是...的 calque)
• Good ZH: "用户体验最重要"

25. CJK Typography & Fragment Sentences

English technical writing tolerates noun-only fragments ("Lint failed.", "Run conditions: X, Y, Z."). Korean and Japanese readers expect complete sentences with verbs in body text. AI translations calque the source's terse rhythm directly, producing reports that feel choppy and unfinished.

Body fragments (noun-ending sentences in body text) → rewrite as full sentences:

• Bad KO: "ANTHROPIC_API_KEY 미설정."
• Good KO: "ANTHROPIC_API_KEY는 설정하지 않았고, OAuth로 대신 인증합니다."
• Bad KO: "lint 실패."
• Good KO: "lint가 실패했습니다." (standalone) / "결과: lint 실패" (inside a label)
• Bad KO: "anti-pattern 1개."
• Good KO: "anti-pattern이 하나 발견되었습니다."

Tailing negation calque (do not directly translate English trailing negation fragments):

English commonly tacks short negation fragments onto the end of a sentence ("..., no guessing", "..., no wasted motion"). Calquing this into CJK produces awkward noun-ending fragments ("..., 추측 없이", "..., 낭비 없이"). In body text, expand the fragment into a full clause.

• Bad EN→KO: "선택된 항목에서 옵션이 나옵니다, 추측 없이."
• Good KO: "선택된 항목에서 바로 옵션을 가져오므로 사용자가 추측할 필요가 없습니다."
• Bad EN→KO: "한 번에 처리합니다, 낭비 없이."
• Good KO: "낭비되는 동작 없이 한 번에 처리합니다."

Inside label/table-cell positions, short negation fragments are acceptable (e.g., 결과: 추측 불필요).

Fragments are allowed inside label/table positions:

• Fragments are natural inside table cells, bullet headers, and key: value labels (e.g., 실행 조건:, Pass:).
• Only rewrite fragments that appear abruptly inside narrative body text.

Spacing between code spans and Korean particles:

Korean publishing and technical-writing convention attaches the trailing particle directly to an inline code span (backtick) with no space. Calquing the English convention of spacing around inline code looks visually broken in Korean.

• Bad: "prompt 로 5 개 하네스를 비교합니다"
• Good: "prompt로 5개 하네스를 비교합니다"
• Bad: "oh-my-agent 소스를 프로젝트에 시드"
• Good: "oh-my-agent 소스를 프로젝트에 심습니다" (also avoid Sino-Korean noun transliteration of English verbs; see the next sub-rule)

No Sino-Korean noun transliteration of English verbs:

Pinning English verbs into Korean as Sino-Korean nouns ("시드", "로드", "발동", "진행") strips out the action and reads as jargon. Unpack them into natural Korean verbs.

• Bad KO: "skill을 로드" → Good KO: "skill을 불러옵니다"
• Bad KO: "프로젝트에 시드" → Good KO: "프로젝트에 심습니다"
• Bad KO: "<HARD-GATE> 발동" → Good KO: "<HARD-GATE>가 트리거됐습니다" or "<HARD-GATE>가 걸렸습니다"

---

Self-Check

Before finalizing any translation, scan for:

• [ ] No AI vocabulary clustering (5+ flagged words in one paragraph)
• [ ] No inflated significance added beyond source
• [ ] No promotional tone upgrade
• [ ] Consistent terminology (no synonym cycling)
• [ ] Natural sentence structure for target language (not source-language word order)
• [ ] No unnecessary bold, em dashes, or formatting artifacts
• [ ] No chatbot communication artifacts
• [ ] No signposting or announcement phrases such as "let's dive in" unless the source intentionally uses them
• [ ] No persuasive-authority tropes such as "the real question is" or "at its core" unless the source voice requires them
• [ ] No generic positive conclusions or formulaic challenge/future sections
• [ ] No unsupported media/notability padding
• [ ] No emoji decoration or inline-header vertical lists introduced by the translation
• [ ] No filler phrases that can be compressed without changing meaning
• [ ] For prose/adaptation tasks, rhythm matches the source or provided voice sample without invented personality
• [ ] No unnecessary connectives where context already implies the relationship
• [ ] No passive voice where active voice is more natural in target language
• [ ] No long modifier chains (3+) stacked before a noun; break into clauses
• [ ] No over-nominalization (verbs/adjectives turned into nouns where unnecessary)
• [ ] No forced pronouns where omission is natural in target language
• [ ] No cleft sentence calques from English
• [ ] No body-text fragments (noun-ending sentences appearing abruptly in CJK body text); labels and table cells are exempt
• [ ] CJK typography: no space between inline code and a trailing Korean particle
• [ ] No Sino-Korean transliteration of English verbs (e.g., 시드 / 로드 / 발동 / 진행); unpack into natural Korean verbs

Translation Quality Rubric

5-point scale per criterion. Total 50 points.

Criteria

1. Naturalness (10 pts)

Does it read like it was originally written in the target language?

Red flags:

• Source language word order leaking through
• Unnatural particles or prepositions
• Overly long sentences that should be split
• Forced subjects where omission is natural
• Europeanized patterns: unnecessary connectives (따라서/그러나/또한), passive voice abuse, noun pile-up, over-nominalization, cleft sentence calques

2. Accuracy (10 pts)

Is the meaning fully preserved?

Red flags:

• Added meaning not in source
• Omitted important qualifiers
• Reversed logic (negation errors)
• Hallucinated content
• Emotional connotations flattened (e.g., "alarming" → neutral "놀라운" instead of urgent "우려되는")
• Figurative language translated literally when the image doesn't work in target language

3. Register Consistency (10 pts)

Does the tone match the configured register throughout?

Red flags:

• Mixing 합니다체 and 해요체 in Korean
• Switching between です/ます and 普通体 in Japanese
• Formal vocabulary in casual context or vice versa

4. Terminology (10 pts)

Are domain terms consistent and correct?

Red flags:

• Same source term translated differently in same batch
• Glossary term overridden without justification
• Technical term translated when it should stay in English

5. Technical Integrity (10 pts)

Are placeholders, formatting, and structure preserved?

Red flags:

• Modified or deleted {variables}
• Broken HTML/markdown tags
• Changed JSON/YAML key names
• Added or removed line breaks that affect rendering

Scoring Guide

Quick Self-Check (for translator)

Before submitting, verify:

• [ ] Read the full translation aloud: does it flow?
• [ ] Glossary terms are consistent across all strings
• [ ] Register matches config from start to finish
• [ ] All placeholders survived intact
• [ ] No source language word order leaking through
• [ ] Emotional connotations preserved (not flattened into neutral words)
• [ ] Figurative language handled naturally (interpret/substitute/retain, not literal calques)
• [ ] No Europeanized patterns (passive voice, noun pile-up, forced pronouns, unnecessary connectives)
• [ ] Translator's notes are concise, accurate, and calibrated to target audience