Translate a Java (Spring) app into Japanese

What Japanese changes in a messages.properties file

Japanese combines three scripts. Kanji carry meaning (保存, ‘save’), hiragana carry grammar and katakana carry loanwords (ログイン, ‘log in’). There are no spaces between words, and punctuation is full-width: 、 for a comma and 。 for a full stop. For a Spring application this has four consequences.

• Word order often flips. welcome=Welcome, {0} becomes welcome={0}さん、ようこそ: the placeholder moves to the front, followed by the honorific さん. A message assembled by concatenation in Java ("Hello " + user.getName()) can never be reordered. It has to use a {0} argument.
• One plural form. CLDR defines only the other category for Japanese. A {0,choice,0#no files|1#one file|1<{0} files} keeps its structure, but its branches become almost identical ({0} 件のファイル). Japanese counts with classifiers instead: 件 for items, 人 for people, 枚 for sheets.
• Register. Business software is expected to use the polite です/ます style in sentences (保存しました。, ‘saved’) and short neutral forms on buttons (保存, キャンセル). Instructions take the 〜してください form: メールアドレスを入力してください。
• Colons and brackets. Name: becomes 氏名： or 氏名: depending on your style guide. What matters is that every file follows the same rule.

Encoding: the trap specific to .properties files

For years, Java read .properties files as ISO-8859-1, a character set with no Japanese characters at all. As a result, projects use one of two conventions.

• Unicode escapes. 保存 is written \u4FDD\u5B58. Every Java version reads it, but no human reviewer can.
• Plain UTF-8. Since Java 9, ResourceBundle reads .properties files as UTF-8. Spring Boot reads messages as UTF-8 by default, configurable through spring.messages.encoding. If you declare your own ResourceBundleMessageSource, check which encoding it has been given.

The file Manuce returns keeps the original encoding, BOM and line endings. Any \uXXXX escapes the file already uses are preserved. Translation will therefore not change the encoding for you. If your base file is ISO-8859-1 without escapes, save the copy intended for Japanese as UTF-8 before uploading it. Then make sure the application reads it as UTF-8, otherwise the screen will show question marks or garbled characters.

What Manuce returns, and what it does not do

You upload messages.properties, or a copy named messages_ja.properties. You get the same file back with the values in Japanese. Indentation, key order, comments and quotation marks are unchanged. Continuation lines ending in \ are respected.

• Placeholders and tags checked. Each translated value is compared with its source: {0}, {1,number} or <b> must all be present, even when moved to the start of the sentence. If a mismatch persists, the source value is kept and the report says so.
• MessageFormat apostrophes. In a value with arguments, an apostrophe must be doubled: Can''t delete {0}. Japanese rarely needs one, as it quotes with 「」. If an apostrophe remains, for example in a product name, it is handled.
• Left as they are. Keys, empty values, URLs, email addresses, numbers, colours, date formats (MM/dd/yyyy stays as written), identifiers and anything marked as non-translatable are not touched.

The report lists the translated strings and the ones left unchanged, with the reason. Only the uploaded file is processed: your Java code, Thymeleaf templates and LocaleResolver remain your responsibility. Manuce does not provide sworn or certified translation, so terms and conditions that need a certified version require an accredited translator. Japanese carries a ×1.6 language coefficient. Pricing is based on the words in the values, excluding keys and tags.

Preparing the file and checking it afterwards

• Remove concatenation. Search the code for getMessage(...) + and replace each one with a single parameterised key. This is the most common cause of scrambled Japanese sentences.
• Comment ambiguous keys. A comment such as # button, verb above action.open=Open helps your Japanese reviewer choose between 開く (to open) and オープン (an ‘open’ status). Comments are kept in the returned file.
• Adapt date patterns yourself. Japan uses year-month-day order: yyyy/MM/dd or yyyy年M月d日. These patterns are not translated. If you store them in messages_ja.properties, edit them by hand.
• Check fonts. If the server generates PDFs or images, the embedded font must contain Japanese glyphs, otherwise empty boxes appear. In the browser, add a Japanese fallback font to your stylesheet.
• Test with the ja locale. Send an Accept-Language: ja header. Any key missing from messages_ja.properties falls back to messages.properties, which produces a half-translated screen.
• Check line breaks. Without spaces, browsers break Japanese between any two characters. Make sure a word such as ダウンロード is not split inside a narrow column or button.

In practice

1. Copy messages.properties to messages_ja.properties saved as UTF-8, or keep \uXXXX escapes if your project uses them.
2. Replace concatenated messages in your Java code with keys that take {0} arguments.
3. Upload the file, then review the quote and the free sample at your chosen level.
4. Put the file back in src/main/resources and test the application with the ja locale.
5. Read the report and deal with any strings left in the source language.