Localization is not translation

I studied translation, ran multilingual marketing for a cross-border e-commerce service across twelve markets, and then moved into frontend work. In that order, which means I've been on both sides of the handoff where a translated site goes live and something is off.

The words are usually fine by then. What breaks is the stuff around them. These are the checks I run on anything that has to work in Japanese.

Line breaks

Japanese has no spaces between words, so the browser is allowed to wrap anywhere, including in the middle of one. In body text nobody notices. In a heading it looks careless.

:lang(ja) h1,
:lang(ja) h2 {
  word-break: auto-phrase;
  text-wrap: balance;
}

auto-phrase wraps at phrase boundaries instead. It only kicks in when the element (or a parent) has lang="ja", and it's Chromium-only for now. Other browsers skip that one declaration (text-wrap: balance still applies), so there's no downside to shipping it.

Names

Family name first, and most forms also ask for the reading in katakana (フリガナ), because the same kanji can be read several ways. A single "Full name" field loses both the order and the reading, and every email that starts with Dear ${firstName} comes out wrong.

The usual layout is four fields: family name, given name, and a katakana reading for each. autocomplete="family-name" and "given-name" on the first two let browsers fill them correctly.

Addresses

They run from large to small: postal code, prefecture, city, then the block and building. People expect to type the seven-digit postal code and have the prefecture and city fill themselves in. A form that starts with the street and ends with a US-style state dropdown makes them do it backwards.

Money and dates

Don't format them by hand. Intl already knows yen has no decimals, and the Japanese locale even uses a full-width yen sign:

new Intl.NumberFormat("ja-JP", { style: "currency", currency: "JPY" }).format(
  19800,
)
// "￥19,800"   (en-US gives "¥19,800")

Official documents and a lot of older users still write dates with the imperial era. The calendar extension handles it:

new Intl.DateTimeFormat("ja-JP-u-ca-japanese", {
  era: "long",
  year: "numeric",
  month: "long",
  day: "numeric",
  timeZone: "Asia/Tokyo",
}).format(new Date("2026-09-30"))
// "令和8年9月30日"

Set timeZone explicitly. new Date("2026-09-30") is midnight UTC, so without it a server or browser anywhere in the Americas prints the 29th.

Length

Japanese labels are usually shorter than English ones but need more line height to stay readable. Spanish and German go the other way and overflow buttons that were sized for English. Lay things out against the longest language you support, not the first one you wrote.

Checkout

Cards aren't the default everywhere. In Japan, paying at a convenience store (konbini) or by bank transfer is still normal, and a card-only checkout loses those buyers at the last step. The reverse is true too: a Japanese site that only offers konbini payment is hard to buy from abroad.

Copy

Marketing copy is the one place where good translation still isn't enough. I'd rather have a native speaker write from the same brief than translate a finished English version, because the reason people buy is often different in each market.