How People Translate Quickly | Segmentation Rules and SRX: Fix Sentence Boundaries Before Bad Splits Damage TM Leverage

People searching segmentation rules translation, SRX rules, CAT tool sentence segmentation, translation segmentation, sentence boundary rules, abbreviation segmentation, or how to stop CAT tools splitting sentences in the wrong place are trying to solve an upstream productivity problem. A CAT tool works with segments, and those segment boundaries determine what the translator sees, what translation memory can match, what repetitions can propagate, and how easily changes can be reviewed. Current TMS documentation still treats segmentation as a first-class project setting because poor segmentation can reduce TM match values, create awkward fragments, and force translators to repair sentence boundaries manually.

The search language around SRX, segmentation rules, abbreviation lists, break rules, no-break rules, and sentence segmentation points to one dominant reader job: configure the source-language boundary rules before the project is imported so ordinary sentences, abbreviations, table cells, headings, and domain-specific patterns become sensible translation units. A translator should not spend an entire project joining “Dr.” to the surname, splitting two sentences that were imported as one block, or repairing every product code that contains a period.

This article has one job: build reusable segmentation rules that prevent bad CAT-tool boundaries before translation begins. It does not replace the existing segment-boundary-repair workflow for one-off manual joins and splits after import. Manual repair is the emergency tool. Segmentation-rule design is the preventive system. The reader should finish this article knowing how to diagnose bad segmentation, decide whether a rule belongs in abbreviations or SRX, test it safely, protect TM leverage, and promote the rule into project templates without creating a new class of false boundaries.

Quick answer

A reliable segmentation-rule workflow is:

import a representative source sample with the default rules;
inspect where the CAT tool splits and does not split;
classify every bad boundary as a repeated pattern or one-off source defect;
keep one-off source defects out of global segmentation rules;
add abbreviations to a no-break list when periods inside abbreviations cause false sentence breaks;
use SRX or equivalent regular-expression rules when the boundary depends on character patterns;
test both positive and negative examples before changing a production project;
reimport a sample and compare segment counts and TM leverage;
verify CJK, tables, cells, headings, numbered lists, and inline tags separately;
only then promote the new segmentation rule into a reusable project template.

The core rule is:

fix the recurring boundary rule upstream; fix the exceptional sentence locally.

What segmentation actually does

Segmentation is the process of dividing source content into translation units.

A source paragraph might contain:

The device is ready. Press Start. Wait for the green indicator.

A sentence-based segmentation engine may create three units:

The device is ready.
Press Start.
Wait for the green indicator.

That can be useful because each sentence becomes independently translatable, searchable, reusable in translation memory, and easy to compare.

But segmentation is only useful when the boundaries correspond reasonably well to meaning.

Why segmentation affects translation memory

Translation memory normally stores source-target segment pairs.

Suppose an earlier project stored:

Translation memories can be used bidirectionally.

Now a new source file contains the exact same sentence.

If segmentation is the same, the tool may offer a 100% or context match.

If the new file instead imports:

Translation memories can be used

and:

bidirectionally.

the original TM unit no longer aligns with either fragment.

The translator loses reuse even though the wording has not changed.

That is why segmentation is not merely visual formatting.

It determines the unit of memory.

Segmentation can create false translation work

Bad split:

Dr.

Tan approved the report.

The translator now receives two fragments.

Problems:

“Dr.” may be copied or translated wrongly;
the second fragment begins unnaturally;
TM retrieval weakens;
reviewer sees broken context;
word count may become misleading.

If this pattern appears once, manual repair is fine.

If it appears 800 times in medical reports, the rule needs fixing.

Break rules and no-break rules

A segmentation engine needs to decide when punctuation creates a boundary.

A simplified model:

Break rule

A period followed by space and uppercase letter may signal a new sentence.

No-break rule

If the period belongs to a known abbreviation such as “Dr.”, do not break.

Real segmentation engines use richer language-specific rules, but this model is useful.

SRX in plain language

SRX stands for Segmentation Rules eXchange.

It is an XML-based way to express segmentation rules that can be exchanged across compatible tools.

Typical SRX logic says:

what pattern appears before a possible boundary;
what pattern appears after it;
whether the engine should break there.

A rule can therefore express:

Do not split after “Dr.” when another word follows.

Or:

Split after a question mark when normal sentence text follows.

The translator does not need to become a regex specialist to benefit from SRX.

The important skill is designing the boundary policy.

Abbreviation lists are the easiest first repair

Many bad breaks come from abbreviations:

Dr.
Prof.
Fig.
Sec.
No.
Inc.
Ltd.
approx.
e.g.
i.e.

If the TMS supports an abbreviation list, use that before writing complicated regex.

An abbreviation list is easier to read, audit, maintain, and explain.

Use SRX when the boundary pattern cannot be expressed as a simple list.

Worked example 1: “No.” as abbreviation and ordinary word

Source:

No. 15 was selected.

The period after “No.” should not end the sentence.

But source may also contain:

No. Stop immediately.

Here “No.” is a complete sentence.

A simple abbreviation list may treat every “No.” as nonbreaking.

That creates a different error.

The correct solution depends on source patterns.

This is why segmentation rules need examples, not assumptions.

Build a test corpus before editing rules

A good test corpus contains:

cases that must split;
cases that must not split;
borderline cases;
real client examples.

For an abbreviation rule:

Must not split

Dr. Tan approved the form.

Must not split

See Fig. 4 for details.

Must split

Stop. Tan must wait outside.

Borderline

No. Continue only after approval.

Do not edit production segmentation until the test set behaves.

Positive and negative tests

Every rule needs both.

Positive test

A case the rule should change.

Negative test

A similar case the rule must leave alone.

If you test only the desired case, a broad regex can look successful while breaking hundreds of normal sentences.

Step 1: diagnose source or rule

A bad segment does not automatically mean the segmentation rule is wrong.

Possible causes:

manual line break;
paragraph break;
hidden formatting;
broken OCR;
copied PDF text;
unusual punctuation;
source author error.

If the source contains an accidental newline in the middle of a sentence, changing SRX may be the wrong fix.

First ask:

Is the boundary generated by language rules or by source structure?

Structural boundaries can outrank sentence rules

A spreadsheet cell may be one unit.

An XML element may be one unit.

A paragraph may be one unit before inner sentence segmentation.

Some tools apply segmentation only inside the structural unit extracted by the file filter.

Therefore two systems interact:

file extraction;
sentence segmentation.

Do not try to solve a file-filter problem with SRX.

Step 2: identify repeated patterns

One wrong boundary:

local repair.

Fifty identical wrong boundaries:

candidate rule.

A useful rule should eliminate repeated work.

If a pattern appears only once in a 100,000-word project, the global configuration may cost more than the repair.

Step 3: decide the segmentation goal

Different projects want different segment sizes.

Technical manual

Sentence segmentation is usually useful.

Subtitle

Segment boundaries may already represent timing units.

Spreadsheet

One cell may need to remain one segment.

Survey strings

Each field may be a complete UI unit even if it contains several sentences.

Legal clauses

Long sentences may still be useful as single units if splitting damages internal references.

Segmentation should follow the content’s reuse and editing model.

One sentence is not always the perfect segment

The common rule “one sentence = one segment” is useful but not universal.

A source string may contain:

Yes. Continue.

If it is one UI message with one identifier, splitting may create technical problems.

An Excel cell may intentionally contain a two-sentence help tooltip.

A product localization key often should remain one key-aligned unit.

The correct segment is the smallest unit that preserves meaning, context, technical identity, and useful reuse.

Step 4: understand segmentation order

A typical pipeline can look like:

file filter → structural extraction → segmentation → CAT segment IDs.

Changing the file filter can change the text that reaches SRX.

Changing SRX can change how extracted text splits.

Changing either after translation starts can disturb TM matches, segment IDs, review history, and propagation.

Configure early.

Step 5: handle abbreviations conservatively

An abbreviation list should contain forms that truly occur before continued text.

Avoid dumping a huge dictionary of abbreviations into the rule set.

Why?

Every no-break exception reduces normal sentence splitting.

A rarely used abbreviation can create unexpected merges.

Start with observed client or domain forms.

Domain-specific abbreviations

Medical:

Dr.
mg.
approx.

Academic:

Fig.
Eq.
Sec.
Vol.

Corporate:

Inc.
Ltd.
Co.

Legal:

Art.
para.
cl.

Build domain layers if the tool supports reusable profiles.

Step 6: handle initials

Names can contain:

A. B. Tan

A naive period rule may create:

A.

B.

Tan

This is terrible segmentation.

Possible no-break patterns can protect initials followed by another name token.

But test against real sentence-final initials.

Do not overgeneralize.

Step 7: handle decimal numbers

Source:

The tolerance is 2.5 mm.

A period inside 2.5 is not a sentence boundary.

Default language rules usually handle this.

Custom rules should not break it.

Whenever you edit period logic, include decimals in the regression test.

Step 8: handle numbered headings

Source:

3. Installation

The period after section number may look like a sentence boundary.

File structure may already keep the heading together.

If not, a rule can protect numbering patterns.

Test both headings and prose.

Step 9: handle list numbering

Source:

1. Turn off the device.

The segment should usually include the list item text.

Do not let “1.” become its own segment unless numbering is handled as a tag or nontranslatable element.

The exact solution may belong to the file filter rather than SRX.

Step 10: handle ellipses

Source:

Wait… then continue.

Should this split?

Usually not.

But:

Wait… Then continue.

Could represent two sentences stylistically.

Ellipses are language and style dependent.

Default rules often handle them.

Custom rules require careful tests.

Step 11: handle colons

Some projects want to split after a colon.

Others do not.

Example:

Warning: Do not disconnect power.

Keeping the whole sentence together often preserves meaning.

But structured content may use:

Step 1: Disconnect power.

Here a break may be desirable.

A global colon rule is risky.

Use only when source conventions are stable.

Step 12: handle semicolons

Semicolons normally connect clauses within one sentence.

Splitting can improve short-segment reuse in some technical content.

It can also destroy natural clause context.

Do not split on semicolons merely to create more segments.

Evaluate actual TM benefit.

Step 13: handle question marks and exclamation marks

These are strong sentence-boundary signals.

But product names or quoted fragments can complicate them.

Example:

Are you sure? Yes.

Two sentences.

Example:

The feature “Ready?” appears in the menu.

The question mark is inside a quoted name.

A robust tokenizer may understand quotes.

Custom rules need testing.

Step 14: handle quotation marks

A boundary can occur:

He said, “Stop.” Then he left.

The period is before a closing quote.

Rules must recognize punctuation plus quote plus whitespace.

Languages use different quotation marks:

“ ”
‘ ’
« »
„ “

Do not import one English regex into every source language.

Step 15: handle parentheses

Source:

The unit stops automatically (after 10 minutes). Restart it.

The period before or after parenthesis can affect detection.

Include parentheses in tests when source uses them heavily.

Step 16: handle abbreviations at sentence end

Source:

The supplier is Acme Ltd. The order is confirmed.

“Ltd.” is both abbreviation and sentence-final token.

A no-break list that always prevents breaking after “Ltd.” would merge two sentences.

This is a classic segmentation problem.

A better rule may consider what follows.

Step 17: test case sensitivity

Abbreviation forms may appear:

Fig.
fig.
FIG.

Decide whether rules should be case-sensitive.

A case-insensitive rule is convenient.

It can also match ordinary words unexpectedly.

Use observed data.

Step 18: source language matters

Segmentation rules are source-language rules.

The English source punctuation system differs from Chinese, Japanese, Thai, Arabic, German, and other languages.

Do not reuse one SRX profile blindly across source languages.

CJK and space-less languages

Custom segmentation in CJK source languages can interact with spaces when the target language uses space-delimited words.

The general lesson is:

custom boundaries can affect target token separation.

Test CJK-to-Latin pairs visually.

A technically valid split can create joined target words if spacing behavior is wrong.

Thai and languages without the same sentence cues

Some languages use sentence boundaries differently from English punctuation conventions.

Default vendor rules often contain years of language-specific behavior.

Replace them only when there is a strong project reason.

Custom is not automatically better.

Step 19: preserve default rules when possible

The safest customization is usually:

default language rules + small project-specific exception.

The riskiest is:

replace the entire segmentation system with a homemade regex set.

Default rules handle many edge cases you may not remember to test.

Prefer minimal change.

Step 20: version custom rules

Name them clearly:

EN-Medical-v1

EN-Technical-v2

JA-UI-v1

Record the reason, date, test cases, and change.

Segmentation affects every future import.

Treat the rule as infrastructure.

Step 21: compare segment counts

Before rule change:

10,420 segments.

After:

9,860 segments.

Why did 560 disappear?

Maybe the rule correctly stopped splitting abbreviations.

Maybe it accidentally merged sentences.

Segment count is not a quality score.

It is a diagnostic signal.

Large count changes deserve inspection.

Step 22: compare TM leverage

Run project analysis with old and new segmentation.

Check:

100% matches;
fuzzy matches;
repetitions;
new words.

A segmentation rule can improve reuse.

It can also reduce reuse.

Measure.

Worked example 2: TM leverage gain

Historical TM stores:

See Fig. 4 for details.

Default import incorrectly creates:

See Fig.

and:

4 for details.

No useful exact match.

After adding the abbreviation rule for Fig.:

the full sentence aligns with TM.

One rule recovers hundreds of matches across manuals.

This is a high-value customization.

Worked example 3: overbroad no-break rule

Project adds No. to the abbreviation list.

Now:

No. Stop immediately.

imports as one segment.

Reviewers notice many merged dialogue lines.

The rule saved one problem and created another.

Solution:

refine context;
remove global abbreviation;
use file-specific handling if possible.

This is why negative tests matter.

Step 23: reimport instead of editing every segment manually

If the project is early and bad segmentation is widespread:

pause translation;
fix rule;
reimport;
reuse safe work through TM.

This can be faster than manually repairing thousands of boundaries.

But once project has extensive review state, reimport may be costly.

Act early.

Step 24: know when manual repair is better

Manual join/split is better when:

one-off source typo;
rare edge case;
already translated project;
custom rule would be risky.

The existing segment-boundary-repair workflow should own these local exceptions.

Do not force a global rule to fix one ugly sentence.

Step 25: keep segmentation out of target-side stylistic decisions

Segmentation is primarily source-side structure.

Do not split source simply because target translation would be easier to write in smaller pieces.

The target can often restructure within the segment.

Change source segmentation when it improves meaning units, technical mapping, TM reuse, or review.

Step 26: legal and long-sentence content

Legal sentences can be very long.

Splitting at semicolons or clause markers might feel helpful.

But internal references such as “provided that,” “notwithstanding,” and “subject to” can depend on the whole structure.

Long does not automatically mean badly segmented.

Use domain judgment.

Step 27: subtitles and time-coded content

Subtitle segmentation is constrained by timecodes, reading speed, and shot changes.

Do not apply ordinary document SRX blindly.

The subtitle format may already define units.

Respect timing structure.

Step 28: spreadsheets

Spreadsheet cells can contain one label, one sentence, multiple sentences, or formulas.

Some TMS settings can keep one cell as one segment.

That may be appropriate when cell identity matters more than sentence-level TM leverage.

Decide before import.

Step 29: XML and JSON strings

Software resource keys often map one value to one interface unit.

Further sentence segmentation can break context key mapping, character limits, developer comments, or review.

For UI localization, keeping one key value as one segment can be safer.

File format matters.

Step 30: headings

A heading without terminal punctuation may already be one structural segment.

SRX does not need to invent a boundary.

If headings merge into following paragraphs, inspect source formatting or file extraction first.

Segmentation and context matching

Context matches can depend on previous segment, next segment, or segment key.

Changing segmentation changes previous/next relationships.

That can alter 101% matches.

A segmentation rule can therefore affect not only exact text matches but contextual confidence.

Segmentation and repetitions

If repeated source strings split differently, repetition counts change.

A repeated sentence may cease to be recognized because one occurrence includes a neighboring fragment.

Consistent boundaries improve repetition leverage.

Segmentation and word count

Word count can change slightly depending on how the tool handles tags, numbers, or joined segments.

More importantly, match-band distribution can change significantly.

Do not compare quotes across two segmentation profiles without noting the rule difference.

Segmentation and alignment

Legacy source-target alignment works better when units correspond.

If the current project uses custom segmentation, consider whether alignment data follows similar boundaries.

Otherwise imported TM may contain differently sized units.

Segmentation and machine translation

MT can translate long or short segments.

But very fragmented input can reduce context.

A fragment:

because of the

is poor MT input.

Good segmentation helps both human and machine translation.

Segmentation and AI assistants

LLM-based translation can sometimes reconstruct fragmented context if neighboring segments are supplied.

That does not justify bad segmentation.

Stable segment units remain important for TM, status, review, propagation, and QA.

Step 31: test tags around boundaries

Inline formatting may sit near sentence ends.

Example:

Click <b>Save.</b> Then continue.

A split can place tags across segment boundaries incorrectly if the file parser is not handling them safely.

Always inspect tag-rich samples.

Step 32: test nonbreaking spaces

Some punctuation uses nonbreaking spaces in source.

Regex expecting ordinary spaces may fail.

Unicode-aware testing matters.

Do not build rules from visually identical characters alone.

Step 33: test line breaks

A line break can mean visual wrap, paragraph, or hard boundary.

Line-break versus paragraph-break mistakes are a common source of poor segmentation.

Inspect authoring practices.

A source cleanup may solve the problem better than SRX.

Step 34: build a segmentation bug log

For every recurring problem, record:

sample source;
current split;
desired split;
file type;
source language;
frequency;
rule owner.

This becomes the backlog for rule improvements.

Result:

target words join incorrectly.