Translate a Unity or Godot Game into Japanese

What Japanese changes in your game strings

Japanese mixes three scripts: kanji for meaning, hiragana for grammar, and katakana for loanwords and many item names (Potion becomes ポーション). There are no spaces between words, punctuation is full-width (、 and 。), and spoken lines sit inside 「 and 」 rather than inverted commas.

Three things follow for a game:

• Word order flips: the verb goes last. You found {0} becomes {0}を見つけた。. A sentence assembled in code from several keys cannot follow that order; a complete string with a placeholder can.
• One plural form only (CLDR category other). If your table splits coins_one and coins_other, both will get the same sentence, and that is correct.
• Counter words: people (3人), flat objects (3枚) and animals (3匹) are counted differently. A generic {0} {1} string that drops in any item name cannot pick the right one; for inventories, a neutral pattern such as {1} ×{0} sidesteps the issue.

Register and character voice

A Japanese game does not use a single register. Menus and system prompts are usually in polite form (セーブしますか？), whereas characters speak according to who they are: plain form between friends, keigo for a shopkeeper or butler, and above all a first-person pronoun (俺, 僕, 私) that defines a character on its own.

A string table, however, does not say who is speaking. Descriptive keys (npc_merchant_greeting rather than str_0412) make reviewing much easier: keys are never translated and stay readable next to the Japanese. Once you have the file back, read each character's lines in sequence to check that tone and pronoun stay consistent; this is the one thing a value-by-value translation cannot guarantee by itself.

If your game targets young children, how many kanji to use and whether to add furigana are decisions for your art direction and text renderer, to be settled on your side.

Fonts and line breaking: set up in the engine

Translation does not fix rendering, and this is where Japanese most often breaks a game that worked perfectly in a Latin-script language.

• Unity with TextMeshPro: a static atlas built from Latin characters only will show empty boxes. You need a font covering common kanji (a family such as Noto Sans JP, for instance), either as a dynamic atlas or a fallback font, or a static atlas regenerated from the Japanese text you actually receive.
• Godot: add a Japanese font as a fallback to your theme fonts, otherwise strings appear blank or as boxes.
• Line breaking: with no spaces, lines break between characters. Make sure 。, 、, 」 or small kana such as ッ never start a line (the kinsoku rules).
• Size: dense kanji become unreadable at very small sizes; tooltips and button labels often need a larger font.

Japanese usually has fewer characters than the source, but each one is wider: test your buttons rather than assuming they will fit.

Exactly what Manuce returns, and what it does not do

You upload the string table exported as CSV: one key column, one column per language. Manuce fills in the ja column if it exists, or adds it. You get the same file back: indentation, key order, quotes, comments, line endings, encoding and BOM are preserved; only the values change.

• Each translated value is checked against the source: placeholders ({0}, {player_name}, %d) and rich-text tags (<color=#FFD700> in Unity, [b] in Godot) must all be present, even when Japanese word order moves them. If a mismatch persists, the source value is kept and the report says so.
• Left untranslated: keys, empty values, URLs, email addresses, numbers, colours, date formats, identifiers, and anything you mark as non-translatable.
• A report comes with the file: strings translated, strings left as they were, and why.

Pricing is based on the words in the values, excluding keys and tags, with a ×1.6 coefficient for Japanese. Only the string file is processed: text baked into textures, videos or voice-over sits outside the file and so outside the translation. Manuce does not run your game, so on-screen checks remain yours to do.

Preparing the file and checking in-game

1. Export the table as UTF-8 CSV. For Godot, send the source CSV (first column keys, then one column per locale code), not the .translation file generated on import.
2. Avoid opening and re-saving the CSV in a spreadsheet: depending on regional settings, some save it in another encoding, Shift_JIS for example, and the Japanese becomes garbled on import. A plain text editor is enough for a quick look.
3. Mark as non-translatable any names you want kept in Latin script: studio name, or the game title if it is your brand.
4. After re-importing, go through the busiest screens: inventory, shop, long dialogues, tooltips, settings.
5. Before releasing on a Japanese storefront, have a native player read the main dialogue.

In practice

1. Export the string table from your Unity or Godot project as UTF-8 CSV.
2. Upload the file for an instant quote on the value words and a free one-paragraph sample.
3. Choose your level and pay; the ja column is filled in or added.
4. Read the report and deal with any strings kept in the source language.
5. Re-import the CSV and check fonts, line breaks and dialogue in-game.