QA & troubleshootingこの記事を日本語で読む

Reviewing a translation you cannot read

A producer, a QA lead, or a developer will spend far more hours looking at a localization file than any single translator will. Almost none of those hours come with the ability to read the text. That is not a failure of process — it is the normal condition of shipping a game in a dozen languages with a team that speaks two or three of them.

The instinct is to treat everything you cannot read as a black box you simply have to trust. That gives up too early. A surprising amount of what makes a translation usable in-game has nothing to do with meaning, and all of it is checkable without knowing a single word of the target language.

What is mechanical, and needs no language at all

Format integrity is the clearest example. A placeholder like `{playerName}` or `%d` either survived translation intact or it did not — you can confirm this with a text search, no comprehension required. The same goes for tags in rich text (`<b>`, `<color=red>`), trailing punctuation that should match the source, and line-break characters embedded in a string.

Length is another mechanical signal. A translated line that is drastically longer or shorter than its source, especially for a fixed-width UI element, is worth a look even if you have no idea what it says — the risk is truncation or an overflowing box, and that risk exists independent of meaning.

  • Every placeholder and tag present in the source appears exactly once in the translation
  • No stray `{`, `}`, `%`, or `<` left unmatched
  • Line length within the range your UI can actually render
  • Same number of lines where the string is expected to be multi-line

Consistency you can check without understanding a word

A recurring source term — an item name, a stat label, a proper noun — should map to the same target text everywhere it recurs, unless grammar in that language genuinely requires variation. You do not need to know what the word means to notice that the same source string produced three different-looking target strings across three files. Group entries by source text and eyeball the target column; identical inputs producing wildly different outputs is a signal worth raising, even framed only as a question to the translator.

The reverse check works too: if the same target string appears for source strings that look unrelated, that is worth a second look — it can be a legitimate shared translation, or it can be a paste error.

Patterns that look untranslated or machine-flavored

You do not need to read a language to notice that a string is still in your source language, or close to it — a Latin-alphabet source language reads visually distinct from most non-Latin scripts, so an untranslated line stands out even to an eye that cannot parse either. Repetition of the exact source word inside an otherwise-translated sentence is another visible clue, since proper nouns aside, most languages do not reuse a foreign word verbatim.

Machine-translation flavor has some visible tells too, even without comprehension: unnaturally uniform sentence length across a whole file, punctuation habits that clearly follow the source language's convention rather than the target's, or a translation memory match that is suspiciously identical to a string with unrelated meaning in the source.

Back-translation, used carefully

Back-translation — running the target text through translation to get a rough sense of it in your own language — is a legitimate spot-check tool, not a review method. It tells you roughly what a line is about, which is enough to catch a wrong-item name, a missing negation, or a sentence that clearly does not match its context. It tells you nothing about tone, naturalness, or whether the phrasing fits the character speaking it — a fluent, well-written translation and an awkward one can both round-trip to the same rough back-translation.

Treat a back-translation mismatch as a question, not a verdict: it flags a line for a native reader, it does not replace one. Treat a back-translation match as reassurance about meaning only, never about quality.

What genuinely needs a native reader

Tone, humor, register (is this character rude or polite, casual or formal), and whether a line sounds like something a human would actually say — none of that is verifiable from the source side, no matter how careful your process is. The same applies to cultural fit: a joke, an idiom, or a reference that works in the source may land oddly, or not at all, in the target, and only someone who lives in that language can tell you.

The practical answer is not to give up on review, but to divide it: mechanical and consistency checks on every line, by whoever is available, and a native-reader pass on a sample — new content, anything flagged by the checks above, and anything a back-translation made you suspicious about. That split gets real coverage out of people who cannot read the language, and spends the scarce native-reader time on the lines that actually need it.

Related articles