People searching Unicode line breaking, UAX 14, CJK line break, word wrapping localization, nonbreaking space localization, line break rules, international text wrapping, or how to stop translated text breaking in the wrong place are usually looking at a layout defect that is neither purely linguistic nor purely visual. A translation can be accurate, correctly punctuated, and within a nominal character limit yet still wrap badly because the renderer breaks before closing punctuation, separates a number from its unit, splits a person’s name, leaves an opening bracket at the end of a line, or treats Chinese, Japanese, Korean, Thai, emoji, hyphens, and narrow nonbreaking spaces as if every language followed English word boundaries.
Current Unicode guidance defines a line-breaking algorithm in UAX #14 that produces permissible break opportunities from Unicode line-break properties. The algorithm is designed to work across writing systems, with tailoring where language or product conventions require it. This search language matters because the problem is not “insert manual line breaks until the screenshot looks good.” The real reader job is: give the renderer enough linguistic and Unicode-aware information to choose legal, readable wrap positions automatically, then reserve hard line breaks for places where the content genuinely requires them.
This article has one dominant job: build a Unicode line-breaking and wrapping QA workflow that lets translated text reflow naturally across languages without hand-placing source-language line breaks or breaking protected text relationships. It does not replace whitespace/punctuation cleanup, which checks typography and spacing. It does not replace length-constraint QA, which checks hard limits. This page owns the reflow layer: where the renderer may break, where it must not break, how CJK and other scripts differ, how nonbreaking characters work, and how to test responsive layouts after translation.
Quick answer
A reliable line-breaking QA workflow is:
- let the platform use Unicode-aware line-breaking rules instead of splitting on spaces alone;
- remove source-authored manual line breaks that exist only for visual wrapping unless they are semantically required;
- preserve hard paragraph and line breaks only when the content structure requires them;
- use nonbreaking spaces or word-joining controls only for relationships that must stay together;
- test number-unit, currency, date, name, URL, code, and product-name sequences explicitly;
- test CJK and other scripts that do not rely on ordinary ASCII spaces;
- distinguish line breaking from hyphenation;
- test narrow and wide responsive layouts;
- inspect final rendering after font changes because glyph width affects wrapping;
- fix the component or line-break policy rather than shortening correct translation solely to imitate source line count.
The central rule is:
store semantic text; let a Unicode-aware renderer choose visual line breaks.
What line breaking actually means
Line breaking asks:
Where may a renderer wrap a line when the current line runs out of horizontal space?
That is different from:
- sentence segmentation;
- paragraph structure;
- manual newline characters;
- hyphenation.
A paragraph can remain one semantic block while the renderer wraps it into:
- three lines on desktop;
- six lines on mobile.
Those line breaks are layout decisions.
Break opportunity versus forced break
A break opportunity is a place where wrapping is allowed.
A forced break is a place where the text must break.
Examples:
Opportunity
Space between ordinary English words.
Forced
Paragraph break or explicit hard line break.
Localization should prefer opportunities over forced breaks for normal prose because opportunities adapt to:
- language;
- font;
- screen size;
- zoom.
Why source manual wrapping is dangerous
A designer may write:
Start your free trial today
because it looks good in English hero copy.
If the newline is stored in the string, the translator receives two lines.
A target language may need:
- different break;
- one line;
- three lines.
The source visual choice becomes target grammar.
That is avoidable.
Step 1: distinguish semantic breaks from decorative breaks
Semantic:
- poem line;
- postal address line;
- code block;
- dialogue transcript format;
- title/subtitle boundary;
- deliberately separate bullet lines.
Decorative:
- break inserted only so English fits a mockup.
Decorative breaks should usually be removed from the localization string and handled by layout.
Worked example 1: hero headline
Source resource:
Learn faster\nwith expert guidance
The translator cannot choose a different break.
Better: one headline string.
CSS/layout wraps it naturally.
If art direction requires a particular break per locale: support locale-specific line-break hints at the design layer, not one universal English newline.
Step 2: understand Unicode line-break properties
Unicode assigns line-break classes to characters.
The line-breaking algorithm considers relationships between:
- letters;
- spaces;
- punctuation;
- numbers;
- combining marks;
- ideographs;
- emoji-like sequences;
- mandatory breaks.
You do not need to memorize every class.
You do need a Unicode-aware renderer.
A rule based only on:
break at ASCII space
is not multilingual line breaking.
CJK is the obvious stress test
Chinese and Japanese text often has no spaces between every word.
If the renderer only breaks at spaces:
- long lines overflow;
- layout breaks.
Unicode line breaking allows break opportunities between many ideographic characters while preventing inappropriate punctuation positions.
This is why the renderer must understand the script.
Step 3: test opening punctuation
An opening bracket or quote should not be stranded at the end of a line if the language convention says it belongs with following text.
Examples:
([- opening quotation marks.
The Unicode algorithm includes punctuation behavior.
Manual string splitting can defeat it.
Step 4: test closing punctuation
Closing punctuation should normally stay with the preceding text.
A line beginning with: ) or a closing quote can look broken.
CJK punctuation rules are especially important because full-width punctuation participates in line-breaking behavior differently from simple Latin text.
Use the real target punctuation.
Step 5: test commas, periods, and colons
Punctuation can affect break opportunities.
Do not insert spaces before or after punctuation solely to influence wrapping.
Use:
- target typographic rules;
- Unicode-aware renderer.
If a layout needs more room: fix layout.
Step 6: nonbreaking space
A nonbreaking space looks like a space but prevents a line break at that location.
It can be useful for relationships such as:
- number + unit;
- title + name in some styles;
- certain abbreviations;
- grouped references.
But it should be used deliberately.
Replacing every normal space with NBSP destroys reflow.
Step 7: narrow no-break space
Some typographic conventions use a narrow nonbreaking space.
It can keep:
- number and unit;
- punctuation relation
together while using less width than ordinary space.
Support depends on fonts and rendering.
Use locale data or style guidance where possible.
Do not insert it manually without a policy.
Step 8: word joiner
Unicode WORD JOINER can prevent line breaking without introducing visible whitespace.
It can be useful for certain sequences.
It is invisible.
That means:
- hard to review;
- easy to lose.
Prefer semantic markup or formatter behavior where available.
If used in text resources: make invisible characters visible in QA tools.
Step 9: zero-width space
A zero-width space can create a possible break without visible spacing.
It can help with:
- long compounds;
- technical strings;
- languages or scripts requiring additional wrap hints.
It can also corrupt identifiers if inserted blindly.
Use it only where the text system expects discretionary break hints.
Zero-width space is not a normal space substitute
A search/identifier pipeline can treat it as a real code point.
If inserted into:
- URL;
- key;
- code;
the string may stop matching.
Line-break hints belong in presentation text, not identity fields.
Step 10: nonbreaking hyphen
Some languages/products need a hyphenated expression to remain together.
A nonbreaking hyphen can prevent a wrap at the hyphen.
Use sparingly.
Ordinary hyphens can be valid break points depending on language rules.
Do not globally replace all hyphens.
Step 11: soft hyphen
A soft hyphen indicates a discretionary hyphenation opportunity.
It may:
- remain invisible when no break occurs;
- display a hyphen when line breaks there.
This is different from line breaking between words.
If the product supports hyphenation: use language-aware mechanisms.
Do not manually insert soft hyphens into every long word unless editorial workflow owns them.
Line breaking versus hyphenation
Line breaking decides:
may the line wrap here?
Hyphenation decides:
may this word be split with a hyphen here?
A product can support:
- wrapping without hyphenation;
- both;
- language-specific hyphenation.
Do not conflate them.
Step 12: test number + unit
Example: 15 km
Should the line break between: 15 and: km?
Many style systems prefer keeping them together.
Use:
- unit formatter;
- locale typography.
Do not rely on translators to remember NBSP for every measurement.
Structured formatters can produce the correct spacing.
Step 13: test currency
Example: $125 or a locale pattern with symbol and amount.
The formatted currency should behave as one coherent value.
A line break between: currency symbol and amount
can be confusing.
Currency formatters should output appropriate spacing and nonbreaking behavior where supported.
Step 14: test percentages
15%
or locale-specific spaced percent pattern.
The sign and number should normally stay together.
Do not create a break opportunity in the middle of a formatted percentage.
Step 15: dates
A date can contain:
- day;
- month;
- year;
- spaces;
- punctuation.
Some long written dates may wrap naturally.
A numeric date should not break at arbitrary separators.
Date formatting and line-break behavior intersect.
Test real output.
Step 16: times
A time such as: 10:30 PM
may need:
- nonbreaking relation;
- locale-specific spacing.
Use the time formatter.
Do not build: 10:30 + " " + PM
as separate layout spans unless the component understands their relationship.
Step 17: personal names
Breaking a long person name can be acceptable in some contexts.
In others:
- badge;
- certificate;
- formal signature
may need special layout.
Do not globally insert no-break spaces through every name.
That can force overflow.
Let the component decide:
- wrap;
- shrink;
- truncate;
- move to next line.
Step 18: product names
A multiword product name may need to remain visually intact in marketing.
But making every word nonbreaking can create severe mobile overflow.
Decide by:
- component;
- brand guidance.
A brand can define:
- allowed break positions;
- no-break tokens.
Step 19: URLs
Long URLs need special wrapping rules.
Breaking at arbitrary positions can:
- look odd;
- make copy/paste confusing.
Web browsers have their own behavior.
If you display URLs in prose:
- use semantic link markup;
- let the browser wrap.
Do not insert spaces into the URL.
Step 20: email addresses
An email address is an identifier.
Visual wrapping may occur in narrow layouts.
Do not modify the stored address.
Use CSS or controlled break opportunities that preserve copy/paste.
Test:
- long local part;
- long domain.
Step 21: filenames and paths
A long filename may need to wrap.
A path can include:
- slash;
- backslash;
- dots.
Do not insert literal spaces.
Use component-specific wrapping.
For technical documentation: monospace/code containers can scroll horizontally instead of breaking.
Step 22: code
Code has syntax.
Line breaking can change readability or meaning if copied.
Use:
- code block;
- horizontal scroll;
- language-aware formatter.
Do not treat code as ordinary prose.
Inline code may need no-break behavior for short tokens.
Step 23: identifiers
Model number: AB-4821-X
Should remain one identity.
If it must wrap: use rendering that does not alter the copied string.
Avoid inserting zero-width characters into a value that users may copy for operational use unless the environment strips or handles them safely.
Step 24: emoji sequences
Some emoji are multiple code points.
A line break should not split inside a grapheme/emoji ZWJ sequence.
Modern Unicode-aware rendering handles this.
Do not perform wrapping by slicing code units.
Text segmentation and line breaking must cooperate.
Step 25: combining marks
A base character plus combining mark should remain together.
Unicode line-breaking rules account for combining behavior.
A homemade character-count wrapper can split incorrectly.
Use the platform text engine.
Step 26: Thai and other scripts
Some scripts require word segmentation that is not simply space-delimited.
Line breaking can depend on dictionary or language-specific segmentation.
A Unicode-aware line-break implementation can be tailored with locale data.
Test real target text.
Do not assume CJK is the only space-less case.
Step 27: responsive UI
A line may fit at:
- desktop width.
It may break at:
- tablet;
- phone;
- split view;
- large accessibility text.
Test several widths.
A localization layout that only works in one screenshot is not ready.
Step 28: text scaling
Users can enlarge system text.
Line breaks change.
A fixed-height component may clip.
Test:
- 100%;
- larger accessibility sizes.
Translation expansion and accessibility scaling compound.
Step 29: font changes
Line wrapping depends on glyph metrics.
Change the font:
- same text;
- different line breaks.
Therefore a brand-font update can create localization regressions without any translation change.
Run visual regression on multilingual screens after typography changes.
Step 30: fallback fonts
If one script uses a fallback font:
- glyph widths;
- line height
can differ.
A mixed-script string may wrap unexpectedly.
Font glyph QA and line-break QA should share test cases.
Failure mode 1: preserve English manual line breaks
Result: target wraps unnaturally.
Repair: semantic string + automatic layout.
Failure mode 2: break only at ASCII spaces
Result: CJK or Thai overflows.
Repair: Unicode-aware engine.
Failure mode 3: insert NBSP everywhere
Result: text cannot reflow.
Repair: no-break only semantic pairs.
Failure mode 4: add spaces inside URLs
Result: identifier broken.
Repair: presentation wrapping.
Failure mode 5: shorten correct translation to match source line count
Result: meaning/style loss.
Repair: flexible layout.
Failure mode 6: ignore punctuation classes
Result: opening/closing punctuation stranded.
Repair: UAX #14 behavior.
Failure mode 7: hard-code line breaks in CMS copy
Result: mobile/desktop conflict.
Repair: responsive layout.
Failure mode 8: test only one font
Result: production font wraps differently.
Repair: real typography in QA.
A line-breaking QA checklist
Content:
- source decorative newlines removed?
- semantic newlines preserved?
- identifiers protected?
- no-break pairs deliberate?
- zero-width hints documented?
Renderer:
- Unicode-aware?
- CJK tested?
- Thai/space-less script tested?
- combining marks safe?
- emoji safe?
Layout:
- mobile?
- desktop?
- zoom?
- accessibility size?
- production font?
- fallback font?
This catches both text and component errors.
A break-pair table
| Sequence | Typical goal |
|---|---|
| ordinary words | wrap allowed |
| number + unit | often keep together |
| currency symbol + amount | keep together |
| opening bracket + next text | avoid break after opening |
| preceding text + closing punctuation | avoid break before closing |
| URL | specialized wrapping |
| code token | often no-break/scroll |
| CJK characters | locale-aware opportunities |
The exact policy remains language and product dependent.
Build a multilingual wrap fixture
A useful fixture page should contain:
- English paragraph;
- Chinese paragraph;
- Japanese paragraph;
- Thai paragraph;
- Arabic paragraph;
- number + unit;
- percentage;
- currency;
- long URL;
- email address;
- long personal name;
- product code;
- emoji sequence;
- parenthetical phrase.
Render it at several widths.
This one page can expose:
- weak break logic;
- unsupported scripts;
- broken fonts;
- bidi surprises;
- overaggressive no-break behavior.
Run it after:
- browser update;
- UI-framework upgrade;
- typography change.
Line breaking and CSS
Web products often use CSS properties such as:
line-break;word-break;overflow-wrap;hyphens;white-space.
These controls can radically change multilingual behavior.
A developer should not set: word-break: break-all
globally merely to stop overflow.
It may split:
- Latin words;
- identifiers;
- CJK punctuation
in visually poor places.
Use the least aggressive property that solves the real problem.
overflow-wrap is not a language engine
Emergency wrapping can prevent a long unbreakable string from escaping its container.
That is useful for:
- unknown URLs;
- user-generated tokens.
It should not replace normal language-aware line breaking.
Think of it as: last-resort overflow protection.
Use ordinary Unicode line breaks first.
white-space: nowrap needs strong justification
A designer may use no-wrap for:
- button;
- tab.
Translated text expands.
The button overflows.
Before shortening: ask whether no-wrap is necessary.
Some components can:
- grow;
- wrap;
- move.
A one-line English assumption should not become a universal translation constraint.
Buttons
Buttons often have real design limits.
Possible strategies:
- wider button;
- multiline button;
- shorter approved target;
- icon plus label.
Do not enforce one strategy globally.
Test:
- longest supported locale;
- accessibility text size.
A button that wraps to four lines may need design changes.
Tabs
Tabs are narrower than paragraphs.
If labels wrap, navigation height can become inconsistent.
Options:
- scrollable tabs;
- shorter terminology;
- responsive overflow menu.
Do not truncate so aggressively that tabs become indistinguishable.
Line-break QA should feed product design.
Navigation menus
Menu items can often grow vertically.
Allow natural wrapping where possible.
But:
- one item two lines;
- others one line
can affect scanability.
A design system may prefer dynamic width.
Localization tests should reveal the tradeoff early.
Tables
A table cell can become a line-breaking trap.
Columns may contain:
- dates;
- numbers;
- identifiers;
- translated prose.
Treat columns differently:
- prose wraps;
- IDs may no-wrap or specialized wrap;
- numbers align.
One global cell style is rarely ideal.
Tooltips
A tooltip with a fixed width can wrap naturally.
Hard line breaks from source are unnecessary.
Test:
- CJK;
- long German-like compounds;
- Arabic.
A tooltip should adapt in height.
Notifications
Push notifications have platform truncation.
Line breaks may be controlled by OS.
Do not insert manual breaks assuming one device.
Focus on:
- concise source;
- complete meaning early;
- platform preview.
This is not the place for custom UAX tailoring.
Emails
Email clients differ.
HTML email can wrap ordinary paragraphs.
Do not hard-code line breaks for one desktop preview.
Use:
- responsive layout;
- natural paragraphs.
For plain-text emails: line wrapping may be client-controlled.
PDFs
PDF production can freeze line breaks.
Translation expansion changes pagination.
Use a DTP/rendering pass with:
- target font;
- paragraph styles;
- hyphenation policy.
Do not preserve source line endings from extracted PDF text.
They are artifacts of the original layout.
OCR and PDF extraction
Text extracted from PDF often contains a newline at every source visual line.
If imported literally into CAT:
- segmentation breaks;
- target inherits arbitrary line endings.
Source cleanup should:
- join visual line wraps;
- preserve real paragraphs.
This can dramatically improve translation.
Word processors
A DOCX paragraph usually stores text independent of visual line wrapping.
That is localization-friendly.
Manual soft line breaks inserted by authors can still interfere.
Audit them.
A line break in a heading may be decorative.
Presentation slides
Slides often need art-directed breaks.
A translator may need:
- locale-specific line break;
- redesigned text box.
For slides, manual breaks can be legitimate per target locale.
Do not force the source break.
Let target DTP choose.
Captions
Captions can have:
- limited width;
- image relationship.
Allow natural wrap.
Keep figure number and label together if the style requires it.
Use nonbreaking relation through formatting or fields rather than typed spaces.
Subtitles
Subtitle line breaking is a special domain.
It is constrained by:
- reading speed;
- character count;
- timing;
- shot changes.
Do not apply ordinary UI wrapping rules blindly.
Subtitle tools have specialized line-break guidance.
This page’s general principle still applies: break at readable linguistic boundaries.
Poetry
Poetry line breaks carry meaning and form.
They are semantic, not decorative.
Preserve them according to literary translation strategy.
Do not let responsive layout automatically rewrap a poem as prose if line structure matters.
Addresses
Postal addresses often use semantic lines:
- recipient;
- street;
- locality;
- postal code;
- country.
These should not be collapsed into one auto-wrapped paragraph when the postal format requires lines.
Address formatting is structured content.
A line break can be part of the data presentation.
Code samples
Long code lines may:
- scroll horizontally;
- wrap at syntax-aware positions.