Translate an Angular app into Japanese
Upload the messages.xlf generated by ng extract-i18n: Manuce fills in the Japanese targets, keeps every interpolation placeholder and returns the same file, ready to become messages.ja.xlf. Japanese has its own rules for word order, full-width punctuation, plurals and politeness, so here is what to prepare and check.
What it costs
For the language files of a Angular app totalling about 2,500 words, into Japanese:
To understand, internal use.
Ready to send, by the technical specialist.
Cross-checked. For documents that commit you.
Price for one language, original layout included. VAT not applicable — article 293 B of the French General Tax Code (CGI). The exact quote, based on your file's word count, is shown before you pay.
What Japanese changes in a messages.xlf
Japanese mixes three scripts: kanji for concepts (設定, "settings"), hiragana for grammar (を, が, ます) and katakana for loanwords (ダウンロード). Words are not separated by spaces and punctuation is full-width: 、 for the comma, 。 for the full stop, ？ and ： at the end of labels. A Japanese target should have no spaces around these marks.
Word order is subject-object-verb. Delete {{ fileName }}? becomes {{ fileName }}を削除しますか？, with the variable moving to the front. In the XLIFF, the placeholder <x id="INTERPOLATION" equiv-text="{{ fileName }}"/> (or <ph name="INTERPOLATION"/> in XLIFF 2.0) changes position in the target. That is expected: Angular rebuilds the sentence from where the placeholders sit in the target, not from their order in the source.
Register matters. In a business interface, messages use the polite -masu and -desu endings: 保存しました rather than 保存した for "Saved". Buttons stay as short nouns or verbs: 保存, キャンセル, 閉じる. Form validation messages follow suit: "This field is required" becomes この項目は必須です.
ICU plurals and formats: what the ja locale handles itself
CLDR defines a single plural category for Japanese: other. An expression such as {count, plural, =0 {No files} one {1 file} other {{{count}} files}} remains valid, but under the ja locale Angular never selects the one branch: a count of 1 falls into other. The branch that matters is therefore other {{{count}}件のファイル}, which reads correctly for any number. Explicit cases such as =0 or =1 still apply.
Japanese does not mark grammatical gender, so a select on gender often ends up with identical branches. That is not a mistake, and the ICU structure must stay intact for the build to succeed.
Dates, numbers and currencies are not translated: DatePipe and CurrencyPipe format them according to the locale. With ja, longDate gives 2025年3月14日 and yen amounts have no decimals. A hard-coded pattern like 'MM/dd/yyyy' in a template will not be changed, so switch to named formats before extraction.
What Manuce returns, and what it does not do
You upload the file produced by ng extract-i18n, in XLIFF 1.2 or 2.0. Manuce fills in the targets and returns the same file: indentation, key order, quotes, comments, line endings, encoding and BOM are preserved; only the values change. Rename it messages.ja.xlf and it slots back into the project.
Each Japanese value is checked against the source for the same variables and tags. If a mismatch persists, the source value is kept and the report says so. You see which units remain in the original language and why, rather than finding out when the build fails.
Not translated: unit IDs (including custom @@id values), empty values, URLs, email addresses, numbers, colours, date formats, identifiers and anything marked as non-translatable. Pricing is based on the words in the values, with keys and tags excluded; Japanese carries a language coefficient of ×1.6.
Manuce does not edit angular.json, your templates or your stylesheets: registering the locale, building and visual checks remain with you. Nor does it provide certified (sworn) translation, should a legal text in the app need one.
Preparing the file and checking the result
- Give context in the attribute:
i18n="button|Closes the dialog@@closeDialog". "Close" a window is 閉じる, but a ticket marked "Closed" is 完了 or クローズ. Meaning and description travel with the XLIFF and remove the guesswork. - Do not split sentences. A sentence spread over three
i18nelements (Hello,<b>{{ name }}</b>,welcome) cannot be reordered. Keep it in one element, inner tags included, so Japanese can place the name and honorific where they belong ({{ name }}様、ようこそ). - Avoid concatenation in TypeScript:
'Page ' + n + ' of ' + totalcan never become{{ total }}ページ中{{ n }}ページ目. Use$localizewith placeholders, whichng extract-i18nadds to the same file. - Plan for fonts: add Japanese fallbacks to your
font-family(Hiragino Sans, Yu Gothic, Noto Sans JP) and make sure the page carrieslang="ja"; otherwise some systems render kanji with Chinese glyph shapes. - Test lengths: 設定 is shorter than "Settings", but katakana grows quickly ("Download" → ダウンロード) and every character is full-width. Without spaces, browsers can break lines almost anywhere, so check buttons, tabs and narrow columns.
In practice
- Run ng extract-i18n and take the resulting messages.xlf (XLIFF 1.2 or 2.0).
- Upload it: instant quote on the exact word count and a free sample paragraph at your chosen level.
- Download the filled file and the report, then rename it messages.ja.xlf.
- Register the ja locale in your project, build and review the screens.
Frequently asked questions
Should I keep the one branch in my ICU plurals?
The ICU structure is left as it is so the file still compiles. Under the ja locale Angular only uses the other branch, so that branch must work for every count. Explicit =0 or =1 cases are still honoured.
Can interpolation placeholders move within the target?
Yes, and in Japanese they usually must, because the verb comes last. Placeholders are kept and every target is checked against the source. If a placeholder is missing or altered, the source value is kept and flagged in the report.
Which politeness level is used?
For a business interface, the polite -masu and -desu forms are standard in messages, while buttons stay as short words. If your app targets a specific audience, say so in the i18n descriptions.
Are $localize strings from my TypeScript code translated?
Yes, provided they appear in the messages.xlf produced by ng extract-i18n, where they are handled like any other unit. Strings assembled by hand through concatenation never reach the file and stay in the original language.
Can I order Japanese alongside other languages?
Yes. A discount applies to the whole order from two languages: −20% for 2, −30% for 3, −40% for 4 and −50% from 5. Each language comes back as its own file in the same format.
The specialist in charge
This subject goes to Dédale, the technical specialist. See how it works.
The same file, into another language
Into Japanese, other files
See also
Try it on your own file, free
A sample of your file translated at the level you choose, before any payment. You judge, then you decide.