Translate a React or Next.js App into Japanese

What Japanese changes in your locale files

Japanese mixes kanji, hiragana and katakana. It has no spaces between words and puts the verb at the end of the sentence. In an i18next, react-intl or next-intl JSON file, these three features show up at once.

• Variables move. "deleteFiles": "Delete {{count}} files?" becomes "{{count}} 件のファイルを削除しますか？". The variable moves to the front, the verb goes last, and the question mark becomes full-width. This is expected, as long as {{count}} survives unchanged.
• Sentences split across keys break. If a component builds a string from t('youHave'), a number and t('unreadMessages'), no correct Japanese sentence fits that order. Merge them into one key first: "unread": "You have {{count}} unread messages".
• Numbers take counters. Files or items are counted with 件 or 個, people with 人 and flat sheets with 枚. A key called count gives no context. Names such as membersCount or invoiceCount tell the translator what is being counted.

Plurals, on the other hand, vanish: Japanese has a single CLDR category, other. With i18next (v21 format onwards), the items_one / items_other pair stays in the Japanese file, but only items_other is ever read. In an ICU message such as {count, plural, one {# item} other {# items}}, the other branch is displayed. An exact match such as =0 still takes priority and remains useful for “no items”.

Register, punctuation and Japanese conventions

A customer-facing Japanese interface addresses users in the polite です／ます style and uses keigo in sensitive messages. Typical examples are "保存しました" for a save confirmation and "入力内容をご確認ください" for a form error. Buttons stay short and noun-like: 保存, 送信, キャンセル. Loanwords are written in katakana (ダッシュボード, ログイン), so check that each term keeps the same spelling on every screen.

• Full-width punctuation: commas become 、 and full stops become 。. ？ and ！ are full-width too, and quotation marks become 「」.
• Dates: Japanese order is year, month, day (2025年3月14日 or 2025/03/14). A value such as "dateFormat": "MM/DD/YYYY" is left untouched by Manuce. Change it yourself, or format dates with Intl.DateTimeFormat('ja-JP').
• Currency: yen amounts have no decimals, which Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY' }) handles for you.
• Names: the family name comes first, and customers are addressed as {{name}} 様. The order of form fields belongs to the component, not the locale file.

Exactly what Manuce returns, and what it does not do

You upload the source JSON file (locales/en/common.json, messages/de.json or whatever your source language is). Manuce returns the same file, in the same format, ready to become locales/ja/common.json or messages/ja.json.

• Nested keys, {{name}} interpolations and ICU messages are preserved; only the values change.
• Indentation, key order, quotes, comments, line endings, encoding and BOM all match the source, so a file diff shows nothing but values.
• Every translated value is checked against the source for variables and tags such as <strong>. If {{count}} or a tag goes missing and the mismatch persists, the source value is kept and the report says so.
• Manuce does not translate keys, empty values, URLs, email addresses, numbers, colours, date formats, identifiers, or anything you mark as non-translatable.

The report lists the strings translated and those left as they were, with the reason. Manuce does not touch your code. It does not add ja to your Next.js or i18next configuration, set fonts or CSS, or reorder form fields. Pricing is based on the words in the values, excluding keys and tags, with the ×1.6 coefficient that applies to Japanese. For terms and conditions or legal notices aimed at Japan, note that Manuce does not provide sworn or certified translation.

Preparing the files and checking the Japanese UI

Before uploading:

• merge concatenated sentences into a single key with a variable;
• use descriptive key names, because the translator never sees the screen (checkout.payButton rather than btn3);
• identify brand or product names that must stay in Latin script, and mark them as non-translatable.

Once the file is back in the project, run a few checks that are specific to Japanese:

• Language attribute: set <html lang="ja">. Without it, the browser may pick a Chinese font and draw some kanji with shapes that look foreign to Japanese readers.
• Font stack: plan for something like "Hiragino Sans", "Yu Gothic", "Noto Sans JP", sans-serif. Japanese web fonts are heavy, so keep an eye on loading times.
• Line breaking: with no spaces, a string can wrap between almost any two characters. line-break: strict stops a 。 or a small kana from starting a line. Test headings and narrow buttons in particular.
• Length: Japanese often needs fewer characters than English, but each glyph is wider. At very small sizes kanji become unreadable, so check badges and captions.
• Italics: most Japanese fonts have no true italic. Use bold or 「」 brackets for emphasis instead.

In practice

1. Merge split sentences into single keys with variables and mark terms that must stay untranslated.
2. Upload your source JSON file and choose Japanese: you get an instant quote and a free sample.
3. Download the translated file and the report, then place the file in your ja locale folder.
4. Add ja to your project configuration, and set lang="ja" and a Japanese font stack.
5. Test the screens: line breaks, buttons, dates, yen amounts and messages with counters.