Japan is one of the largest software markets in the world, and Japanese buyers are famously hard to win with an English-only product. They are also hard to win with a badly localized one. A B2B buyer in Tokyo who sees a mistranslated button label or a date in US format will often assume the vendor has no local support either, and in many cases they will be right.
The good news is that machine translation from English to Japanese has improved a great deal, and large language models handle tone and context far better than the phrase-based systems many teams remember. The bad news is that the problems that hurt Japanese localization most are not translation problems at all. They live in your CSS, your date library, your form validation and your font stack. This post covers both sides.
Pick a politeness level and write it down
Japanese grammar encodes the relationship between speaker and listener. For software, three registers matter. Plain form (da/dearu) reads as blunt or literary in a UI. Polite form (desu/masu, teineigo) is the standard for product interfaces. Honorific and humble forms (sonkeigo and kenjougo) belong in customer emails, billing notices and support replies, where the company is addressing a customer directly.
The mistake we see most often is mixing them. One screen says 保存しました (polite), the next says 保存完了 (terse noun form), and the error dialog uses humble language that sounds like a formal apology letter. Each string might be acceptable alone. Together they make the product feel like it was assembled by five vendors, which it often was.
Put the decision in a style guide before any translation starts. Specify the register for buttons (usually short noun or verb forms such as 保存 or 削除), for messages (desu/masu), and for transactional email (sonkeigo). Include rules for addressing the user: Japanese UI copy usually avoids あなた (you) entirely, and a direct translation of a casual US-style message such as Hey there, you're all set! will read as odd. Give your MT engine or LLM this guide as part of the prompt and make reviewers check against it.
Layout: length, line breaks and fonts
Japanese text usually takes fewer characters than English, but each character is full-width and visually dense, so the rendered width does not shrink as much as the character count suggests. Short labels sometimes get longer: Settings becomes 設定 (two characters), while Sign in with SSO can become a much longer phrase. Test real strings in real components rather than assuming Japanese will always fit.
Line breaking is where English-first products break most visibly. Japanese has no spaces between words, so browsers can break almost anywhere. The traditional rules, called kinsoku shori, forbid certain characters from starting a line (closing brackets, 。 and 、, small kana such as ゃ, and the long vowel mark ー) and others from ending one (opening brackets). Browsers apply a basic version by default. You can tighten it in CSS:
- line-break: strict applies the stricter set of kinsoku rules, which is what most Japanese readers expect in body copy.
- word-break: auto-phrase, supported in recent Chromium browsers, breaks at natural phrase boundaries for Japanese, which makes headings and buttons far more readable. Use it as a progressive enhancement.
- Avoid word-break: break-all on Japanese containers. It is often added to fix long English URLs and quietly ruins Japanese text.
- For headings, consider inserting <wbr> at phrase boundaries in the source string, or using a library such as BudouX, which was built for exactly this problem.
Fonts need attention too. A Japanese font covers thousands of glyphs, and a full web font file can run to several megabytes. Most products rely on system fonts first (Hiragino Sans on Apple devices, Yu Gothic or Meiryo on Windows) with Noto Sans JP as a web font fallback, loaded via a CDN that splits it into unicode-range subsets. Set a font stack per locale rather than letting the browser pick a Chinese glyph variant for shared Han characters, which happens more often than teams expect when lang attributes are missing. Always set lang='ja' on the html element for Japanese pages.
Formats, forms and input
Most format bugs disappear if you use Intl APIs with the ja-JP locale rather than formatting strings by hand. A few still need explicit handling:
| Item | Japanese convention | Common bug |
|---|---|---|
| Dates | 2026年8月25日, or 2026/08/25 in tables | MM/DD/YYYY hard-coded in templates |
| Currency | ¥12,800 or 12,800円, no decimal places | Showing ¥12,800.00 from a USD formatter |
| Names | Family name first, with 様 in formal contexts | Single full name field split as first/last |
| Addresses | Postal code first, then prefecture down to building | US-style address form with state dropdown |
| Phone | Domestic format such as 03-1234-5678 | Validation that rejects hyphens |
| Calendar | Japanese era years (e.g. Reiwa) on some official forms | Assuming Gregorian is accepted everywhere |
Input handling deserves its own test pass. Japanese users type through an IME, which composes text before committing it. If your search box or chat input submits on Enter, it may fire while the user is still choosing a kanji conversion. Check the isComposing flag on keyboard events, or listen for compositionend, before treating Enter as submit. Also allow both full-width and half-width digits in numeric fields, and normalize them on the server instead of rejecting the input. Half-width katakana should be avoided in output, though you may need to accept it from older systems.
Choosing an MT engine for English to Japanese
There is no single best engine, and the right answer depends on content type. We test candidates on a sample of a few hundred of the client's own strings rather than relying on published benchmarks, which rarely reflect SaaS UI text.
- Neural MT services (DeepL, Google Cloud Translation, Amazon Translate) are fast, cheap per character and consistent. They support glossaries, which is essential for product terms. They are weaker at following a style guide and at short, context-free UI strings.
- LLMs (GPT-class, Claude, Gemini) follow politeness instructions, handle placeholders and context notes well, and can be told the string is a button label rather than a sentence. They cost more per string, can drift on terminology without a strict glossary, and occasionally add or drop content, so they need automated checks.
- A hybrid that we often end up with: NMT with a glossary for long-form help content, an LLM with the style guide and screenshots or context notes for UI strings and marketing, and a native reviewer on top of both.
Whatever engine you choose, send context. A string key, a character limit, a description of where it appears, and the surrounding strings will improve output from any engine more than switching vendors will. If your strings currently ship to translation as a flat list of English sentences, fix that first.
Termbase and QA gates
A termbase for Japanese has to decide more than translations. It must fix whether a term is rendered in katakana or kanji (ダッシュボード versus 管理画面 for dashboard), whether product names stay in Latin script, and how loanwords end (ユーザー with the long vowel mark is the modern standard, ユーザ appears in older technical writing). Start with 100 to 300 terms pulled from your UI and help center, and let the native reviewer approve each one.
Then put automated gates in the pipeline before any human sees the output:
- Placeholder and markup check: every {variable}, HTML tag and ICU plural block in the source exists in the target, unchanged.
- Glossary compliance: required terms appear, forbidden variants do not.
- Length check against the character limit per key, measured in display width rather than raw characters.
- Register check: flag plain-form sentence endings in message strings that should use desu/masu. A simple pattern list catches most of these, and an LLM classifier catches the rest.
- Untranslated or mixed-script detection, for strings that came back in English or with stray Chinese characters.
- Visual review on screenshots of the running product, in both light and dark themes, at mobile width.
Finally, plan for continuous localization. A SaaS product changes every week, and a once-a-year translation batch leaves Japanese users with a half-English interface most of the time. Connect your string repository to the translation pipeline so new keys are translated, checked and queued for review automatically, and fail the release build if a Japanese key is missing in a customer-facing flow.
Questions we get asked
- Is machine translation good enough for Japanese SaaS localization?
- For a first draft, yes, especially with a glossary and context. For customer-facing flows such as onboarding, pricing and legal pages, a native Japanese reviewer is still needed to catch tone and terminology problems.
- Which politeness level should a Japanese UI use?
- Most products use polite desu/masu form for messages and short noun or verb forms for buttons, with honorific language reserved for emails and support replies. The key is to choose once and apply it consistently.
- How do I stop Japanese text breaking in the wrong place?
- Set lang to ja, use line-break: strict, avoid word-break: break-all, and add word-break: auto-phrase or a phrase-segmentation library such as BudouX for headings and buttons.