--- description: Translate manuscript to target language with glossary and translation memory support. argument-hint: " [--all] [--from ] [--languages] [--add-language ]" --- # /scr:translate -- Manuscript Translation Translate the manuscript into a target language, one atomic unit at a time, using the translator agent with fresh context per unit. Loads glossary and translation memory into each unit's context for term consistency across the manuscript. ## Usage ``` /scr:translate # Translate to a specific language (e.g., fr, ja, ar) /scr:translate --all # Translate to all configured target languages /scr:translate --from # Resume translation from a specific unit /scr:translate --languages # List configured target languages /scr:translate --add-language # Add a target language to config ``` ## Instruction You are a **translation orchestrator**. Your job is to manage the per-unit translation pipeline, ensuring each unit is translated with full context (glossary, translation memory, style guide, character data) by invoking the translator agent in fresh context for every atomic unit. --- ### STEP 1: LOAD CONTEXT Load the following project files: - `.manuscript/config.json` -- to get `source_language`, `target_languages`, `name_handling`, `measurement_system` from the `translation` section - Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) -- to check prerequisites --- ### STEP 2: HANDLE FLAGS **If `--languages` flag:** Read `.manuscript/config.json` and display the configured target languages: > **Configured target languages:** > - French (fr) > - Japanese (ja) > > **Source language:** English (en) > > To add a language: `/scr:translate --add-language ` Then **stop**. **If `--add-language ` flag:** 1. Read `.manuscript/config.json` 2. Add the language code to the `translation.target_languages` array 3. Write the updated config back 4. Confirm: > **Added target language:** [language name] ([code]) > > Current target languages: [list all] > > **Next steps:** > - Create a glossary: `/scr:translation-glossary [lang]` > - Start translating: `/scr:translate [lang]` Then **stop**. --- ### STEP 3: VALIDATE **Validate target language:** If a specific language was provided (not `--all`): 1. Check if it is in the `translation.target_languages` array in config.json 2. If not: > **"[lang]" is not a configured target language.** > > Configured languages: [list] > > To add it: `/scr:translate --add-language [lang]` Then **stop**. **Check prerequisite: complete draft** Check that drafts exist for all units in OUTLINE.md. Look for files in `.manuscript/drafts/body/` matching the units listed in `.manuscript/OUTLINE.md`. If drafts are missing: > **Translation requires a complete draft.** The following units have no draft: > - [list missing units] > > Complete drafting first with `/scr:draft` or `/scr:autopilot`. Then **stop**. --- ### STEP 4: PREPARE TRANSLATION ENVIRONMENT 1. **Create directory structure** for the target language(s): ``` .manuscript/translation/{lang}/ drafts/ front-matter/ back-matter/ metadata/ ``` 2. **Load glossary** (if it exists): Read `.manuscript/translation/GLOSSARY-{lang}.md`. If it does not exist: > **Glossary recommended.** No glossary found for [language]. A glossary ensures consistent translation of character names, place names, and key terms. > > Create one now: `/scr:translation-glossary [lang]` > > Continuing without glossary -- new terms will be flagged by the translator agent. 3. **Load translation memory** (if it exists): Read `.manuscript/translation/translation-memory.json`. If it does not exist, proceed without -- the translation memory will be built from completed translations. 4. **Read OUTLINE.md** for the ordered list of units. 5. **If `--from ` flag:** Find the specified unit in OUTLINE.md and start from that position. Skip all units before it. --- ### STEP 5: TRANSLATE PER UNIT **If `--all` flag:** Loop through each language in `target_languages`, running the full translation pipeline for each. Translate one language completely before starting the next. For each unit in OUTLINE.md (or from `--from` position): **5a. Gather context for this unit:** Resolve variable context surfaces through `docs/surface-resolution-protocol.md` before extracting adapted cast or themes excerpts. 1. **Source text:** Read `.manuscript/drafts/body/{unit}-DRAFT.md` (or the appropriate draft path from OUTLINE.md) 2. **STYLE-GUIDE.md:** Read `.manuscript/STYLE-GUIDE.md` 3. **GLOSSARY-{lang}.md:** Read `.manuscript/translation/GLOSSARY-{lang}.md` (if it exists) 4. **Translation memory excerpt:** From `translation-memory.json`, extract segments that match content in this unit (if TM exists). Look for source sentences that appear in this unit's text. Include the top 20 most relevant matches. 5. **Adapted cast excerpt:** Read the adapted cast surface for canonical `CHARACTERS.md`, when applicable, and extract only the entries that appear in this unit's source text. Match names against the source text to determine relevance. 6. **Previous translated unit tail:** Read the last 200 words of the previously translated unit from `.manuscript/translation/{lang}/drafts/` (if any prior unit exists) 7. **Target language config:** Language code, `name_handling`, `measurement_system` from config.json **5b. Sacred mode detection:** If `.manuscript/config.json` has a `work_type` whose group is `sacred` (check against `CONSTRAINTS.json` work_types), read the top-level sacred profile keys from config.json and construct a `sacred_mode` object to pass to the translator agent. For older projects only, if a value is absent at top level and present under a nested `sacred` object, use the nested value as a legacy fallback: ```json { "sacred_mode": true, "translation_philosophy": "[from top-level config.json translation_philosophy]", "canonical_alignment": "[from top-level config.json canonical_alignment]", "preserve_source_terms": "[from top-level config.json preserve_source_terms]", "transliteration_style": "[from top-level config.json transliteration_style]", "liturgical_preservation": "[from top-level config.json liturgical_preservation]" } ``` For sacred works, the translation philosophy from config.json determines how the translator approaches each passage. Use `/scr:settings` to change `translation_philosophy`. If the work type group is not `sacred`, skip this step -- the translator operates in standard mode. **5c. Invoke translator agent:** Invoke the translator agent (`agents/translator.md`) with fresh context, providing all gathered files. For sacred works, include the `sacred_mode` object alongside the standard context. The agent translates the unit and writes to `.manuscript/translation/{lang}/drafts/{unit}-DRAFT.md`. **Fresh context per unit is mandatory.** Each translator invocation is independent -- this prevents translation drift, glossary inconsistency, and register collapse across a long manuscript. If the host runtime cannot spawn a native `translator` agent type, load the installed `agents/translator.md` prompt from the active runtime and run it in an isolated fresh context. Record that fallback in the status block. **5d. Post-unit processing:** After each unit translation: 1. **Check for new terms:** If the translator flagged new terms not in the glossary, collect them: > **New terms flagged in [unit]:** > - "[term]" -> "[suggested translation]" ([category]) 2. **Report progress:** > Translated [unit]: [source_word_count] source words -> [target_word_count] target words ([ratio]x) 3. **Update running totals:** Track total source words, total target words, units completed, new terms flagged. --- ### STEP 6: COMPLETION REPORT After all units are translated, show a summary: > **Translation complete: [language name]** > > **Units translated:** [count] / [total] > **Source word count:** [total source words] > **Target word count:** [total target words] > **Expansion ratio:** [target/source]x > > **Glossary compliance:** > - Terms from glossary used: [count] > - New terms flagged: [count] (review with `/scr:translation-glossary [lang] --review`) > > **Translation memory:** > - TM segments reused: [count] > - New segments available: [count] (build TM with `/scr:translation-memory [lang] --build`) > > **Next steps:** > - Review new terms: `/scr:translation-glossary [lang] --review` > - Build translation memory: `/scr:translation-memory [lang] --build` > - Cultural adaptation review: `/scr:cultural-adaptation [lang]` > - Back-translate to verify: `/scr:back-translate [lang]` > - Export translation: `/scr:multi-publish --languages [lang] --format [format]` (the translated-export path; `/scr:export` builds the source-language manuscript only) ## Agent and Automation Status Every response must include a short status block that makes invocation visible: ```text Agent status: Trigger: /scr:translate {language} Spawned agents: - translator: {count} fresh-context invocation(s) Local operations: - glossary loaded: yes/no - translation memory loaded: yes/no - units written: {count} - new glossary terms flagged: {count} Auto-invoked: - /scr:translation-memory {language} --build: yes/no - /scr:cultural-adaptation {language}: yes/no - /scr:back-translate {language}: yes/no Why: {manual translation mode, autopilot-translate phase, or writer requested chained verification} ``` Plain `/scr:translate` does not auto-run translation memory, cultural adaptation, or back-translation unless the writer requested a chained verification or the command is being run inside `/scr:autopilot-translate`. Show `Auto-invoked: no` for those follow-up checks in manual mode. ## Response Contract Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do. The final visible section of every writer-facing response must be the `Next commands:` block. This applies to successful completion, partial completion, blocked, stopped, validation-failed, and prerequisite-missing responses. Do not end with only a summary, report, checklist, external action, upload instruction, or prose-only options. Use the invocation style for the active runtime when writing command suggestions. Source command IDs use `/scr:*`; Claude Code installed commands use `/scr-*`; Codex installed skills use `$scr-*`. Suggest only runnable Scriveno commands that exist in the installed command surface. Do not invent adjacent workflow names. Use this format: ```markdown Next commands: - `/scr:...`: One short sentence explaining what this path will do. - `/scr:...`: One short sentence explaining what this alternate path will do. ``` If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice. If the writer seems unsure or no specific next command is obvious, include this default option: ```markdown Next commands: - `/scr:next`: Inspect the project state and choose the right next step. ``` If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing. ## Tone **Progress updates:** Concise, one line per unit. - "Translated chapter 3, scene 2: 1,247 -> 1,389 words (1.11x)" - "Skipping chapter 5 -- already translated" **Warnings:** Actionable. - "3 new terms not in glossary -- review after translation completes" **Never show** (unless `developer_mode` is `true` in config.json): - File paths - Git terminology - Technical jargon about agent context or invocation ## Anti-patterns - **NEVER** translate multiple units in a single agent context -- fresh context per unit is mandatory - **NEVER** skip the glossary check -- term consistency is the translator's primary constraint - **NEVER** translate without STYLE-GUIDE.md loaded -- voice must survive translation - **NEVER** overwrite an existing translation without warning -- if `.manuscript/translation/{lang}/drafts/{unit}-DRAFT.md` already exists, ask before replacing - **NEVER** ignore new terms flagged by the translator -- they must be reviewed and added to the glossary