Japanese text wraps in the wrong place — a line starts with 、or 」

A Japanese text box wraps and something reads as wrong even to someone who cannot say exactly why: a line starts with a lone 、 or 。, a closing bracket 」 sits by itself at the start of a line with nothing before it, or a small kana like っ or ょ opens a line on its own. None of these are typos or mistranslations — the words are all correct. The line break itself landed somewhere Japanese typography treats as forbidden.

This is governed by a real, named rule set — kinsoku shori (禁則処理, line-breaking prohibitions) — not a vague sense that something looks off. Knowing the actual rule lets you tell a genuine bug from a false alarm, and points at the real fix instead of randomly rewording text until it happens to wrap better.

What kinsoku shori actually prohibits

Kinsoku shori defines two categories of characters that must not sit in certain positions at a line break. Line-start prohibitions (行頭禁則, gyōtō kinsoku) forbid certain characters from beginning a line — the natural break has to move so they stay attached to the end of the previous line instead.

• Closing punctuation must not start a line: 」』）〉》, closing quotation marks and parentheses
• Sentence-ending punctuation must not start a line: 。 and 、
• Small kana (捨て仮名/拗音) must not start a line: っ ゃ ゅ ょ ぁ ぃ ぅ ぇ ぉ, and the prolonged sound mark ー

Line-end prohibitions and the orphaned bracket

The mirror rule, line-end prohibitions (行末禁則, gyōmatsu kinsoku), forbids certain opening characters from ending a line — an opening bracket 「 or 『 must not be the last character on a line, because it would be visually separated from the text it opens. When a renderer correctly applies kinsoku shori, an opening bracket that would otherwise land at a line's end gets pushed to the start of the next line along with the character after it, or the line is shortened earlier so the bracket and its content stay together.

The symptom of a closing bracket sitting alone at the start of a line is specifically the line-start rule failing — the renderer let 」 open a new line instead of pulling it back to close out the previous line's content.

Why space-based wrapping does nothing for Japanese

Most text-rendering systems decide where a line can break by looking for space characters, because that is how word boundaries work in English and most Latin-script languages. Japanese text has no spaces between words at all, so a wrapping algorithm built only around space-detection has no valid break points in a Japanese string and either fails to wrap, or falls back to breaking at an arbitrary character boundary with no awareness of kinsoku shori.

Correct Japanese line breaking needs a renderer that either understands kinsoku shori directly, or that a text-layout engine's CJK line-breaking mode has been explicitly enabled — this is not something you get for free from a component built and tested only against English strings.

/* CSS line-breaking behavior differs per property */
.jp-text {
  line-break: strict;   /* applies stricter kinsoku shori rules */
  overflow-wrap: normal; /* does not force mid-word breaks */
}

Why terms split mid-word after translation

A separate but related symptom: a product name, unit, or compound term that should stay on one line gets split across two, even though no kinsoku rule is technically violated. This is not a kinsoku shori failure — kinsoku shori only governs punctuation and small kana, not ordinary word cohesion, and unlike English, Japanese has no built-in concept of a protected run of characters that must not be broken, because there are no spaces marking word boundaries in the first place. If a term must not split, that has to be marked explicitly — wrapping it in a no-break span, or inserting a zero-width no-break marker — it is not something the renderer infers on its own.

Why hard newlines baked into source strings go wrong after translation

A different cause entirely: some source strings contain a literal newline character placed by hand to control where a line breaks in the source language's layout. That newline travels through translation unchanged, but the translated text has a different length and different natural break points, so the hard-coded newline now lands somewhere unrelated to where the translated text should actually wrap — often producing exactly the awkward line-start or line-end violations above, because the forced break point has no relationship to kinsoku shori at all.

• Fix: remove hard-coded newlines from strings that get translated, and let the layout wrap the text naturally with kinsoku shori enabled
• If a manual break is genuinely required by the UI, place it per-locale rather than assuming the source language's break point survives translation

What to verify on device

Automated checks catch the mechanical cases — search translated text for hard-coded newlines, and confirm the rendering surface has kinsoku shori (or CJK line-break mode) enabled at all. But the only reliable final check is looking at the actual rendered text on the target device or platform at the container widths the game really uses, because line breaks depend on the exact width, font, and point size — a string that wraps fine in a wide debug view can still violate kinsoku shori once it is squeezed into the narrower box the shipping UI actually uses.