Updating a story in five languages: how do you track translations still awaiting review?
When the Chinese entry requirements change, earlier approvals for other languages no longer suffice. Tie review records to the source version, language, and field. Add any record with a version mismatch or without approval to the work queue, and release all languages together only after every affected row is approved.
Tie each approval to a specific source version first
After changing the entry requirements, register the affected fields again for each language so that approval records refer to a specific source version. “Japanese is done” might refer to yesterday’s text. A valid record should answer: Which source version is the translation based on? What was changed? Who approved it? Is it cleared for release?
Use two levels of records: a change card containing the old and new source text, and a review ledger with one entry per language and field. Chinese also needs checking: the dialogue may have been updated while a failure message still describes the old requirements. Derive each language’s overall status from its field statuses.
The following is a fictional teaching example. Its characters, story, records, and progress are invented. It is neither a real user case nor a tested result, and it does not represent existing features of any product. Every procedure described here is a documentation convention that can be carried out manually.
Break the entry requirements into changes you can assess individually
Suppose A Night in Mist Harbor is maintained in Chinese, English, Japanese, Korean, and Spanish. The author adds restrictions on entering the Archive Tower.
| Source version | Gatekeeper’s exact words |
|---|---|
| Version 7 | You can enter the Archive Tower if you have a copper key. |
| Version 8 | You may enter the Archive Tower only if you have a copper key and arrive before the bell rings; each companion must also have a key of their own. |
Check three points: a copper key is still required; an arrival deadline has been added; and the key requirement explicitly applies to everyone entering. Keeping only “copper key” while omitting the other two points does not count as a completed update across languages.
The change card can be filled out as follows:
- Change ID: Archive Tower entry requirements change 8.
- Source location: Chapter 2 / Archive Tower entrance / Gatekeeper’s explanation.
- Baseline change: Replace version 7 with version 8, retaining the complete wording of both versions.
- Interpretation rules: Arriving as the bell rings does not count as arriving “before the bell rings”; if any companion lacks a key, the group cannot enter together.
- Affected fields: Gatekeeper’s explanation, option text, failure messages, quest summary.
- Story-rule approver: Lin Cen; appoint separate translation approvers for each language.
The two interpretation rules are fictional details supplied by the author of this example, not assumptions for translators to make. If it has not yet been decided whether someone without a key may wait outside, mark this as “Awaiting clarification” and pause approval of the relevant sentences.
Use a field-level ledger to see exactly what is holding up each language
The smallest ledger entry is one field in one language. Include at least these columns:
| Column | What to enter |
|---|---|
| Language and field location | For example, Japanese / Archive Tower entrance / Failure message |
| Target source version | Version 8, which this update must match |
| Source version underlying the current translation | The actual basis, version 7 or version 8; this does not imply approval |
| Translation revision ID and text location | Enough information to find the complete text under review |
| Affected content | Differences such as the deadline and individual key requirements |
| Status and reason for blockage | Awaiting update, Awaiting review, Returned for revision, Approved, or Awaiting clarification |
| Approval record | Name, date, source version, and translation revision ID |
| Release requirements | Checks this field still needs to satisfy |
“Awaiting update” means the update is incomplete. “Awaiting review” means the new text has been submitted but not yet approved. “Returned for revision” means a problem was found and revisions are needed. “Awaiting clarification” means the interpretation rules remain undecided. “Approved” requires valid sign-off on the current text. If the translation changes after approval, return it to Awaiting review and keep the old sign-off as history.
The following is only a progress excerpt. It is not a complete translation sample and does not indicate that language quality has been validated.
| Language / Field | Current source basis | Status | Approver or next step |
|---|---|---|---|
| Chinese / Gatekeeper’s explanation | Version 8 | Approved | Lin Cen has approved this revision |
| English / Option text | Version 7 | Awaiting update | Xu He to add the time constraint |
| Japanese / Failure message | Version 8 | Returned for revision | Chen Yao noted that it still implies a key can be shared |
| Korean / Quest summary | Version 8 | Awaiting review | Awaiting Zhou Ning’s point-by-point check |
| Spanish / Gatekeeper’s explanation | Version 8 | Awaiting review | Awaiting Luo Qing’s check of the wording about which companions the requirement covers |
The actual ledger must cover every affected field. These five rows cannot establish that any language is complete overall. Even a field requiring no edits needs a reason, such as “The option only asks about the rules and makes no promise of entry.” Mark it Approved only after confirming that it can be retained under the new source version.
Work through a returned revision to show how release approval works
Suppose a reviewer paraphrases the meaning of the Japanese failure message in Chinese as “The group has no copper key and cannot enter.” This is a semantic paraphrase originally given in Chinese, not the Japanese translation itself. It may imply that the entire group can share one key, and it does not distinguish arriving late from lacking a key.
The return record should say: “Under version 8, the current message does not express that each person must have a key of their own. Please add separate messages covering missing keys and missing the deadline.” Simply writing “The translation is inaccurate” does not explain the approval criteria.
After revision, work through the wording sentence by sentence using three fictional scenarios:
- Both people arrive before the bell rings, each with a key: the explanation and options should allow both to enter.
- They arrive before the bell rings; the player has a key, but the companion does not: the message should identify the companion’s missing key and must not promise that both can enter together.
- Both have keys but arrive as the bell rings: the message should state that they have missed the deadline.
These walkthroughs check textual meaning. They are not actual test records and cannot demonstrate that the program’s branching logic is correct. If conditions are configured separately, add a separate check for the person responsible to approve.
This example releases all five languages together. All of the following must hold: records exist for all four field types in all five languages; every row’s actual source basis matches the target version 8; semantic walkthroughs reveal no conflicts; sign-offs correspond to the current translation revision IDs; and every affected row is Approved. Any row marked Awaiting update, Awaiting review, Returned for revision, or Awaiting clarification blocks release. Being based on version 8 does not replace completing the update and obtaining approval. If the Korean summary still awaits approval or the English options still await updating, the entire change is still awaiting release approval.
Choose the right level of detail and retain superseded approvals
For a small amount of text, list the four fields for each language in a document. For collaboration among several people, a spreadsheet makes it easier to filter outstanding work. A language overview without field-level detail is useful for tracking progress, but cannot serve as release evidence: it could conceal an overlooked failure message.
Languages can also be released separately, provided that each batch’s requirements version is explicit, the shared story rules are confirmed to permit multiple versions to coexist, and all affected rows in that batch are Approved. If all five languages share the new entry logic, old translations will lead players to make choices using outdated instructions. Completing Chinese alone is not sufficient grounds for release.
If version 8 changes again to “Entry is still allowed after the bell rings,” create a version 9 record and manually reopen review of the relevant fields. Version 8 sign-offs cannot establish that version 9 is correct. Even a change to unrelated punctuation should have its impact assessment recorded, with confirmation of which fields can be retained; there is no need to blindly redo every language.
The ledger establishes what an approval covers and who is responsible. It cannot replace language proficiency or guarantee that people will find every reference. First list the dialogue, options, messages, and summaries in which the requirements appear, then expand that list across all five languages. Finally, add rows to the work queue if their actual source basis does not match the target version or their status is not Approved. Include a row when either condition holds: take the union of the two sets. This finds older text without overlooking records already based on version 8 that still await review or have been returned for revision.
