Translate an XLIFF File into Japanese, Tags and State Intact

What Japanese changes inside an XLIFF file

Japanese text mixes three scripts: kanji for concepts (保存, “save”), hiragana for grammar and katakana for loanwords (ダウンロード, “download”). Words are not separated by spaces, and punctuation is full-width: the comma becomes 、 and the full stop 。. In an XLIFF file this has practical consequences.

• Encoding. Japanese needs a Unicode encoding. Manuce keeps the file's encoding exactly as it is, so an XLIFF declared as ISO-8859-1 cannot hold Japanese characters. Save it as UTF-8 first.
• Target language. Check that the file declares Japanese: target-language="ja" on <file> in XLIFF 1.2, trgLang="ja" on the root <xliff> element in XLIFF 2.0.
• Length. Japanese often uses fewer characters than English, but each one is roughly as wide as two Latin letters. A label that is short in kanji (設定, “Settings”) grows quickly once katakana is involved (アカウントのセキュリティ設定, “Account security settings”).
• Register. Interface sentences are normally in the polite です/ます form: “The file could not be saved.” becomes 「ファイルを保存できませんでした。」. Buttons stay short, often a bare noun: 保存, キャンセル.

Inline tags and Japanese word order

Japanese puts the verb at the end. A unit such as Click <g id="1">Save</g> to continue. becomes 続行するには<g id="1">保存</g>をクリックしてください。: the tag still wraps the same word, but its position in the sentence has moved. With a single tag, that is harmless.

With several tags or placeholders, Manuce keeps them in their original order. Natural Japanese order is sometimes the reverse: “Page <x id="1"/> of <x id="2"/>” would usually start with the total. The translation therefore has to be built around the fixed order, for example <x id="1"/>ページ目（全<x id="2"/>ページ）. Review multi-tag units first.

Watch the spaces around tags too. Welcome, <ph id="1"/> has a space in English; Japanese expects 「ようこそ、<ph id="1"/>さん」, with no space and the honorific さん after the name. If your code adds spaces when concatenating strings, they will appear in the middle of the Japanese text.

A string that would lose a tag is rejected and flagged; if a value's tags or variables still do not match the source, the source value is kept and the report says so.

Plurals, counters and dates: what stays in your code

Japanese has a single CLDR plural category, other. If your units contain ICU messages ({count, plural, one {# file} other {# files}}), only the other branch matters for Japanese; check how the branches were rendered in the delivered file and what your library expects for ja.

Numbers, on the other hand, take a counter word that depends on what is being counted: 3件 for results, 3個 for objects, 3人 for people. “<x id="n"/> results” becomes <x id="n"/>件の結果. A vague string such as “<x id="n"/> items” forces a generic counter; a note in the file saying what is counted helps the translator.

Manuce does not translate numbers, date formats, URLs, email addresses, identifiers, colours or keys. A MM/dd/yyyy pattern inside a value stays as it is: Japanese year–month–day order (2025年3月14日 or 2025/03/14) belongs in your localisation code, not in the XLIFF.

What Manuce delivers, and what it does not do

• The same XLIFF file, 1.2 or 2.0: source text translated into the target element, state attribute updated.
• Indentation, element order, quotes, comments, line endings, encoding and BOM preserved; only the values change.
• Units marked translate="no" are respected; notes in the file are used as context by the translator.
• Every translated value is checked against the source for variables and tags.
• A report listing strings translated, strings left unchanged and the reason.

Manuce does not reorder tags, test the result in your application or adjust layout: a button too narrow for ダウンロード still needs widening on your side. It does not take glossaries or translation memories, and it does not produce sworn or certified translations.

Pricing is based on the words in the values, excluding keys and tags; Japanese carries a surcharge (×1.6 coefficient on the per-word rate).

Preparing the file and checking the result

Before uploading:

• Save the file as UTF-8 and confirm the target language is ja.
• Mark product names you want kept in Latin letters with translate="no"; otherwise a name may be rendered in katakana.
• Keep any developer notes your tool exports: “Open” as a status and “Open” as a button translate differently, for instance 公開中 and 開く.
• Read the free sample: it shows the register and the handling of tags before you pay.

After delivery:

• Go through the report and look for units left in the source language.
• Import the file and view the interface with a Japanese font and lang="ja" declared; without it, some kanji may be drawn with Chinese glyph shapes from a fallback font.
• Check line breaks: 。 or 、 should never start a line, and a label cut off mid-katakana becomes unreadable.
• Have a native speaker review multi-tag units, then move their state forward in your tool.

In practice

1. Export the XLIFF (1.2 or 2.0) as UTF-8, with ja as the target language.
2. Mark product names to keep in Latin letters with translate="no".
3. Upload the file for an instant quote on value words and a free one-paragraph sample.
4. Pay, then download the translated XLIFF and its report.
5. Import it and check the Japanese display in your application.