Korean and Japanese are the two languages where a translation can be completely correct and still land badly. The grammar checks out, the terminology matches the glossary, the reviewer signs off — and native users still describe the product as cold, stiff, or vaguely off. Nobody can point at a specific error, because there isn't one.
The problem is almost never accuracy. It's register: the level of politeness a sentence carries, and whether that level matches the moment. English encodes politeness with word choice ("please", "sorry about that"). Korean and Japanese encode it in the grammar itself — every sentence you write must pick a level, and there is no neutral option to hide behind.
Here's what teams shipping into Seoul and Tokyo consistently get wrong, and what to do instead.
1. Your product has to pick a politeness level — on every single string
In Korean, the two registers you'll actually use in a product are 해요체 (haeyo-che) — polite but warm, the default for consumer apps — and 합니다체 (hamnida-che) — formal and declarative, right for legal notices, official announcements and enterprise tools. Mix them at random across a screen and the product reads like two different companies wrote it.
Japanese has the same problem in three layers. 丁寧語 (teineigo), the ですます polite form, is what almost every consumer app should use. Above it sit 尊敬語 (sonkeigo), respectful language elevating the user, and 謙譲語 (kenjougo), humble language lowering the speaker. Reach for those too eagerly and your chat app suddenly sounds like a private bank writing to a shareholder.
The practical fix is boring but effective: decide the register once, write it into the style guide, and treat a register mismatch as a bug — not a preference. "Use 해요체 for all in-product UI; 합니다체 for Terms, privacy and system-level notices" is a rule a reviewer can enforce. "Be friendly but professional" is not.
2. Stop translating the word "you"
This is the single most common tell that a Korean or Japanese UI was translated from English by someone working sentence-by-sentence.
Korean has a word that dictionaries map to "you" — 당신 (dangsin) — and in real usage it is almost never what you want. Depending on context it reads as distant, textbook-ish, weirdly intimate, or outright confrontational. Native Korean copy simply omits the subject, or names the relationship ("고객님" for a customer). Japanese has the same trap with あなた (anata), which in a product interface can come across as cold or presumptuous.
So "You have 3 unread messages" doesn't become "You(당신) have…". It becomes, in effect, "There are 3 unread messages" — the subject disappears and the sentence still knows exactly who it's talking about. Ask your linguists to rewrite around the pronoun rather than translate it, and flag any appearance of 당신/あなた in review as something to justify, not something to accept by default.
3. Never build sentences by concatenation
English is subject–verb–object. Korean and Japanese are subject–object–verb, with the verb — and therefore the politeness ending, and often the negation — arriving last. Any code that glues fragments together in English order will produce word salad.
The classic failure looks like this:
// Breaks badly in ko / ja
label = verb + " " + count + " " + noun;Because the verb has to move to the end and the counter word has to change with the noun, there is no ordering of those fragments that a translator can rescue. Use full sentences with named placeholders instead:
// Translatable
"delete_items": "{count}개 항목을 삭제할까요?"Related: neither language has English-style plurals, but both have counter words that change with the type of object being counted — 개 / 명 / 권 in Korean, 個 / 人 / 冊 in Japanese. A generic "{count} items" string cannot be correct for every noun it's reused with. If a counter is involved, give the string its own key.
4. Text gets shorter — and that's its own problem
Teams brace for German expansion and then get surprised in the other direction. Korean and Japanese usually take fewer characters than English — Japanese especially, where a whole English phrase can compress into two kanji.
That sounds like free space, but it introduces different bugs:
- Buttons look broken. A CTA that was "Get started for free" becomes four characters and floats in a sea of padding. Fixed-width buttons designed around English text need to flex, or the layout reads as unfinished.
- Characters need more vertical room. Hangul syllable blocks and kanji are visually denser than Latin letters. At the same font size they need more line-height — cramped leading makes dense text genuinely harder to read, not just uglier.
- Truncation cuts meaning, not just letters. Chopping the tail off a Japanese sentence can remove the verb — which is to say, the entire action and its politeness level. Truncating Korean can strip the particle that marked who did what.
5. Line breaking is a real engineering task
Japanese text has no spaces between words, so a naive line-breaker will split anywhere. Correct Japanese typesetting follows 禁則処理 (kinsoku shori) — a set of forbidden-break rules: a line may not begin with closing brackets, small kana (っ, ゃ, ゅ, ょ) or most punctuation, and may not end with an opening bracket. Browsers handle much of this when you let them; they handle none of it if you're inserting your own line breaks or measuring text with Latin assumptions.
Korean does use spaces, but the rules of 띄어쓰기 (word spacing) aren't the same as English, and breaking mid-word looks as wrong as it would in English. Set word-break: keep-all for Korean text and let the browser break at spaces rather than anywhere it likes — this one CSS line fixes a surprising number of "why does the Korean look bad" tickets.
And load real fonts for both. A Latin-first font stack silently falls back to whatever the OS supplies, which is how the same page ends up with three different Hangul shapes across three devices. (We go deeper on this in our CJK & SEA typography piece.)
6. Errors are where tone matters most
In English, product error copy has trended toward the breezy: "Oops! Something went wrong." Translate that spirit literally into Japanese and it reads as a company shrugging at its own failure.
Japanese users expect a genuine apology when something breaks — 申し訳ございません is not corporate boilerplate there, it's the baseline of taking responsibility. Korean expects sincerity too, though it tolerates a slightly lighter touch than Japanese. In both markets, an error message that jokes about the problem transfers your engineering failure onto the user's mood.
Give your linguists explicit permission to rewrite error strings rather than translate them, and put that permission in the brief. This is the category where transcreation pays for itself fastest.
7. The details that quietly signal "foreign"
- Name order. Family name comes first in both. A form hard-coded as [First name] [Last name] tells every user it wasn't built for them. Prefer a single full-name field unless you have a real reason to split.
- Dates. 2026년 8월 4일 and 2026年8月4日, or the numeric 2026.08.04 — not 08/04/2026, which is ambiguous everywhere anyway.
- Currency. Won and yen don't use decimal places in everyday prices. Showing ₩12,000.00 looks like a bug, because it is one.
- Addresses. Both order from largest unit to smallest — the inverse of the US form your database schema probably assumes.
- Loanwords. Katakana and Konglish are everywhere in tech, but the accepted term is specific: Japanese users know ログイン, and inventing a "purer" alternative just makes the UI harder to scan. Follow platform convention over linguistic purity.
8. Review has to happen in context
Every problem above shares a root cause: they're invisible in a spreadsheet. A reviewer looking at a column of isolated strings cannot see that the register shifts between two adjacent buttons, that a sentence will be truncated at the verb, or that a counter is reused across three different noun types.
So the highest-leverage change is usually process, not language: get a native reviewer looking at real screens — a staging build, or at minimum screenshots attached to the strings. One in-context review pass catches more real problems than three rounds of spreadsheet QA, and it catches exactly the class of issue that makes users say a product "feels foreign" without being able to explain why.
The short version
Pick your register deliberately and enforce it as a rule. Rewrite around "you" instead of translating it. Never concatenate — full sentences, named placeholders, separate keys for counters. Design for text that shrinks, give dense scripts room to breathe, and let the browser break lines properly. Rewrite error copy rather than translating it. Then put a native reviewer in front of the actual UI.
None of this is exotic. It's just the set of decisions English lets you avoid making — and Korean and Japanese don't.