Your Japanese Product Speaks in Five Different Voices, and Your Customers Hear Every One

Look at everything your company publishes in Japanese and count who wrote it. The UI strings came from one translation vendor. The help center came from another, or from the same vendor in a different year with a different translator. The onboarding emails were localized by marketing's agency. The release notes are machine translated. The support team writes its own replies, and lately someone has started drafting Japanese knowledge base articles with an AI assistant.

Each piece may be acceptable on its own. Together, they don't sound like one company. A Japanese customer who moves from your sign-up email to your getting-started guide to a support reply goes through three different registers, two names for the same feature, and at least one sentence that addresses them in a way no Japanese company would. Nobody files a ticket that says "your voice is inconsistent." They just conclude, quietly, that your product wasn't really made for them.

Inconsistent Japanese is rarely a translation-quality problem. Every vendor did what they were asked. Nobody told them who your company is when it speaks Japanese, so each of them decided for themselves.

What "voice" means in Japanese

I've written before that documentation always has a voice, whether you choose one or not. In English, voice is mostly a matter of word choice, sentence length, and how much you hedge. In Japanese, some of those choices are built into the grammar, and getting them inconsistent is far more visible.

The biggest one is register. Japanese prose is written either in the polite style, ending sentences with forms like です and ます (敬体), or in the plain style, ending them with forms like だ and である (常体). The Japan Translation Federation's standard style guide for translators is direct about this: pick one style for the body text and don't mix them. It also says the polite style is the norm for manuals and website text aimed at general readers, because the plain style can come across as impolite.

That sounds simple until you have five sources of Japanese text. When I read Japanese content that came from several sources, register drift shows up in predictable places:

• The getting-started guide is polite; the API reference is plain. Different vendors, different years, nobody comparing them.
• Procedures change form from page to page. One guide says 「保存してください」 ("please save"), the next says 「保存します」 ("you save" or "save"), and a third mixes both within one numbered list.
• Error messages don't match anything else. Developers write them in English late in the sprint, they get translated in isolation, and they often end up in a different register from the screen they appear on.
• The reader is addressed literally. English documentation says "you" constantly. Machine translation and inexperienced translators often carry it over as あなた, which reads oddly in most Japanese product documentation and sounds nothing like the rest of your content.
• Support replies have their own personality. Your support team, writing under time pressure, settles into its own phrasing, and customers notice when the help center and the person helping them sound like different companies.

Fixing most of this starts with a decision, not a native speaker's ear.

Write the decision down: a one-page Japanese voice sheet

Before you hire anyone or change any vendor, write a short document that answers the questions every Japanese writer working on your product currently answers for themselves. One page is enough:

1. Register by content type. Polite style for UI messages, docs, emails, and support? Plain style anywhere, such as tables, code comments, or list items in the API reference? Decide, and list exceptions explicitly.
2. How procedures are written. Pick one form for instructions and use it everywhere.
3. How the reader is addressed. Decide what replaces "you," including whether customers are ever called お客様 in product text or only in emails and support.
4. How the company refers to itself. Your company name, 当社, or nothing at all.
5. Error message pattern. What happened, why, and what to do next, in the same register as the surrounding UI. Decide how apologetic errors should be, and keep it consistent.
6. Mechanics. Full-width 「、」 and 「。」 as punctuation, which is what the JTF guide specifies, and whether you put a space between Japanese text and half-width letters or numbers. The JTF guide's default is no space; some companies choose otherwise. Either is fine. Inconsistency isn't.
7. Five before-and-after examples. Real sentences from your current content, rewritten to the standard. Examples do more than rules.

Hand this sheet to every vendor, agency, contractor, support agent, and AI tool that produces Japanese for you. If you use an AI assistant to draft Japanese, put the sheet in its instructions. Then the voice belongs to your company instead of whoever touched the text last.

Check it without reading Japanese

Register is one of the few Japanese quality problems you can check mechanically. If your docs live in Markdown, the open-source textlint ecosystem has a rule that flags mixed polite and plain styles, checking body text, headings, and lists separately:

{
  "rules": {
    "no-mix-dearu-desumasu": {
      "preferInHeader": "",
      "preferInBody": "ですます",
      "preferInList": "である"
    }
  }
}

Put that in a .textlintrc.json, install textlint and textlint-rule-no-mix-dearu-desumasu from npm, and run npx textlint "docs/ja/**/*.md". Setting preferInBody explicitly makes the rule enforce your chosen style instead of whichever style a given file happens to use more. Add it to CI and register drift stops being something you discover from a customer.

For everything that isn't in Markdown, such as emails, UI strings, and support macros, do a manual sample:

• Collect one example of each content type: a UI dialog, an error message, a docs page, a transactional email, a support reply, and a release note.
• Ask a Japanese-speaking colleague or partner to spend thirty minutes reading them in order, as one customer would encounter them, and to mark where the voice changes.
• Check the reader address. Search your Japanese content for あなた. Every hit is worth a second look.

The goal of the sample isn't a score. It's a list of the places where your company stops sounding like itself.

Why this takes someone who reads both sides

A voice sheet only works if the person writing it understands both the language and the product. The register for an API reference is a different decision from the register for a billing email, and making those calls well requires knowing what each piece of content is for and who reads it.

At Inkwright, my co-founder Hiromi is a native Japanese speaker who has also worked as a software engineer, and she writes or reviews every Japanese document we deliver. I've spent decades in software engineering and writing, and I first moved to Japan in 1989. Together, we can read your codebase, your docs, and your Japanese content side by side and write the standard your vendors and tools should follow.

One company, one voice, in Japanese too

If your Japanese content comes from several sources and you suspect it doesn't sound like one company, I'd be glad to look at a sample with you and help you decide what your Japanese voice should be. You can reach me through the contact page.