Visual novel word count: how to measure it and plan the translation

Every conversation about translating a visual novel starts with the same question: how much text is there? Most developers answer with a guess derived from playtime, or from the size of the script folder, and both mislead badly. Playtime includes reading speed, animation, music and idle time. File size includes commands, tags, comments, and whitespace. Neither is the number anyone actually needs.

The number matters more for this genre than almost any other, because in a text-heavy game the translation cost, the schedule, and most of the risk all scale with it. It also decides which plans are even available to you. A script of a certain size can be translated in one pass by one person; several times that size cannot, and needs to be split across chapters or translators, which introduces consistency problems that a small script never has.

This article is about producing that number honestly and then using it: what counts as text, how to extract and count it, how to handle branches and duplicated lines, how Japanese characters relate to English words, and how to turn a count into a plan you can actually run.

Decide what counts before you count

A single total hides the decisions that matter. Count in buckets instead, because each bucket has a different difficulty, a different rate, and a different chance of being cut from scope.

• Main script: narration and dialogue, the bulk of the volume in almost every visual novel
• Choice text and any branch-specific short lines, which are small in volume but appear at high-attention moments
• Interface text: menus, configuration screens, save and load, backlog, message-speed labels
• Supplementary content: item and term glossaries, character profiles, tips, gallery captions, extras
• System and error messages, including the ones a player only sees when something goes wrong
• Platform-facing text: achievement names and descriptions, the store page, the trailer captions
• Text drawn into images: chapter titles, signs, UI art with words painted on it

Extract a file you can actually count

The goal is a plain text file containing only what a player reads, with everything else removed: engine commands, tags, labels, comments, variable assignments, and — counted separately, if at all — speaker name tags that repeat thousands of times and would otherwise inflate the total.

If your engine has its own translation export, use it. Engines built for this genre generally provide a way to emit exactly the translatable set of lines, and that output is by definition the right scope: it is what the translation pipeline will actually consume. Counting your raw script files instead means counting things that will never be translated, which is how estimates end up twenty per cent too high.

If you are counting raw script files, strip in this order: comments first, then engine commands and tags, then labels and jump targets, then blank lines. Then read a few pages of the result before trusting it. A stripping pass that silently ate half your dialogue produces a very confident, very wrong number, and the only way to catch that is to look at the output.

# 1. Export the translatable lines (use your engine's export if it has one)
# 2. Strip comments, tags, labels and blank lines from the raw script
# 3. Read a page of the result to confirm nothing was eaten
# 4. Count

wc -w export/script_en.txt   # English source: count words
wc -m export/script_ja.txt   # Japanese source: count characters (no spaces to split on)
wc -l export/script_ja.txt   # Line count, useful for chunking by scene

Branches, routes and duplicated lines

A branching novel contains more text than any single playthrough shows, and this is the most common source of underestimation. Translation is priced against the total that exists, not the amount one player sees. If your game has a common route and four character routes, the translator translates the common route once and all four routes in full, regardless of how many of them a given player reads.

So count per section, not as one number: the common route separately from each individual route, and each chapter separately within them. This is more work than a single total and it pays for itself immediately, because it is also the unit you will use to schedule delivery, to split work between translators, and to decide whether a partial release is possible.

Duplicates deserve their own column. Exact repeated lines only need translating once if your pipeline keys them or if the translator uses a tool that remembers previous segments — this is what translation memory does. Near-duplicates get no such benefit and may actually be worse than unique text, because the translator has to check each one for the small difference. Report both a total count and a unique count, and treat the gap between them as information rather than as a discount you are entitled to. Lines that only differ by a variable substitution count once, but each variant still has to be checked in context.

Japanese characters and English words are not the same unit

Translation work is quoted per source word or per source character depending on the language pair and the person you are talking to, so you need to be able to speak in both units and to know that converting between them is an estimate, not an arithmetic fact.

Do not apply a ratio you read somewhere as if it were a constant. The relationship between a Japanese character count and the resulting English word count varies with writing style — a dialogue-heavy script with short lines behaves differently from dense narration — with how much of the text is kanji versus kana, with how often character names and honorifics repeat, and with the translator's approach. Two novels of the same character count can produce noticeably different English word counts.

The practical method is to measure your own ratio rather than borrow one. Take a representative sample — a full scene or a short chapter, not a hand-picked page — have it translated properly, and measure both sides. That gives you a ratio grounded in your actual writing, which you can apply to the rest of the count and then correct after the first real delivery. The sample is worth paying for on its own merits anyway, for reasons the next section covers.

The same measurement has a second use. The ratio you find is also roughly how much your text boxes need to stretch. If a scene expands substantially in translation, the layout question is not hypothetical, and it is far cheaper to discover on one chapter than on a finished script.

Turning the count into a plan

A count becomes a plan when it is divided into units that can be delivered, reviewed and paid for independently. Chapters or routes are the natural boundary because they are self-contained enough for a translator to work on without holding the whole script in their head, and because they let you stop between units if the budget or the schedule changes.

Do three things before mass translation starts. Build a glossary of names, places, terms and any coined vocabulary, with the chosen rendering for each. Write a short character voice sheet: formality level, speech habits, how each character addresses the others. Then commission a pilot chapter and read it carefully, ideally with someone who reads the target language natively. A pilot surfaces tone problems, honorific handling and name choices while fixing them costs one chapter of rework rather than the entire novel.

Then decide your freeze policy, because this is the failure mode specific to long scripts. Every edit to a scene that has already been translated creates rework in every language, and in a novel of this size the temptation to keep polishing prose is constant. Decide when the source script is frozen, what counts as an exception, and who approves one. A script that keeps moving during translation is the most reliable way to turn a manageable count into an unmanageable one.

Track it all in one sheet, with a row per chunk. This is unglamorous and it is what keeps a six-month translation from becoming untraceable.

chapter,route,lines,ja_chars,status,assignee,delivered
ch01,common,412,18240,translated,A,2026-06-03
ch02,common,388,17110,in_review,A,
ch03,common,455,20050,in_progress,A,
ch04,route_mira,540,26980,not_started,,
ch04,route_sae,502,24310,not_started,,
ui,-,180,2400,translated,B,2026-05-28
glossary,-,96,1850,approved,B,2026-05-20

What the count does not tell you

A word count predicts the translation of the text as it exists today, and nothing else. Several real costs sit outside it and are the usual reason a carefully built estimate still comes in low.

Rework from script edits is the largest of them, and it scales with how disciplined your freeze is rather than with volume. Proofreading in context — actually reading the translated text inside the game, in the real text boxes, with the real line breaks — scales with the number of scenes and routes rather than with words, and a branching novel has far more states to check than its word count suggests. Text baked into images is a separate production job with an art cost, not a translation cost. Voice, if you have it, is a different undertaking entirely. And every chapter you add after release adds words in every language you have already committed to.

None of that argues against counting. It argues for treating the count as a planning instrument rather than a price: it tells you what shape of plan is possible, where the work divides, and which conversations you can have with a translator without wasting their time. That is a great deal more than most projects have when they start asking for quotes.