How People Translate Quickly | Locale-Aware Collation and Sorting QA: Order Names, Files and Search Results the Way Target-Language Users Expect

People searching locale-aware sorting, Unicode collation, locale collation, ICU Collator, alphabetical order localization, Unicode Collation Algorithm, sort accented characters, or how to sort translated strings correctly are trying to solve a user-experience problem that ordinary string comparison gets wrong. A product can translate every word accurately and still feel foreign if its names, files, countries, contacts, catalog entries, or search results appear in an order target-language users do not recognize as alphabetical or logical.

Current Unicode Technical Standard #10 defines the Unicode Collation Algorithm (UCA), while ICU provides locale-sensitive collators and CLDR supplies locale data and tailoring. Current documentation explicitly notes that users of different languages have different expectations for sorted order and that even one language can have different orderings such as dictionary versus phonebook order. The SEO query family therefore points to one dominant reader job: stop sorting localized text by raw Unicode code points or source-language assumptions and validate the list under the target locale’s actual collation rules.

This article has one dominant job: build a locale-aware collation and sorting QA workflow so translated names, files, menus, search results, indexes, and user-generated lists appear in the order the target locale expects. It does not replace Unicode normalization, which deals with canonically equivalent encodings, and it does not replace BCP 47 locale validation, which ensures the system knows which locale to use. This page owns the comparison layer: collation strength, accents, case, punctuation, numbers, script ordering, locale tailorings, stable sorting, and user-visible QA.

Quick answer

A reliable collation workflow is:

1. never use raw code-point order for user-facing alphabetical lists unless the product explicitly wants technical order;
2. pass the intended locale into a Unicode/ICU-aware collation library;
3. decide whether case, accents, punctuation, width, and numeric substrings should affect ordering;
4. test target-language special letters and digraphs;
5. test locale variants such as dictionary versus phonebook order where the product exposes them;
6. normalize or use a collation engine that handles canonical equivalence consistently;
7. use numeric collation for human-facing strings such as File 2 and File 10 when appropriate;
8. define tie-breaking so equal-at-primary-strength items sort stably;
9. test mixed scripts, names, emoji, symbols, and user-generated text;
10. keep database/index collation and application collation aligned enough that pagination and search do not contradict the UI.

The central rule is:

sort for the target reader’s alphabet and comparison expectations, not for the computer’s raw character numbers.

What collation means

Collation is the process of comparing strings for ordering and equality-like operations.

A raw programmer sort might compare code points.

A linguistic sort asks:

Which string should a reader expect first?

These are not the same question.

Why code-point order is not alphabetical order

Unicode assigns numeric code points to characters.

Those numbers are designed for encoding, not for every language’s dictionary order.

If you sort by raw code point:

• accented letters may appear in unexpected places;
• uppercase/lowercase may separate strangely;
• non-Latin scripts may cluster arbitrarily;
• numeric substrings sort lexicographically.

A locale-aware collator applies language-sensitive weights.

Worked example 1: Swedish letters

Swedish treats:

• Å;
• Ä;
• Ö

as letters near the end of the alphabet rather than simple variants of A/O in the same way some other locales do.

A sort designed for English or generic accent-insensitive behavior can produce an order Swedish users find wrong.

The correct locale changes the comparison.

Worked example 2: German dictionary and phonebook order

German can use different collation conventions.

A dictionary-style order and a phonebook-style order can treat umlauts differently.

The product should choose the convention that fits the feature.

Do not ask the translator to “fix the alphabet.”

This is locale configuration.

Worked example 3: File 2 versus File 10

Lexicographic sort:

• File 1
• File 10
• File 2

Human numeric expectation:

• File 1
• File 2
• File 10

ICU/locale collation can support numeric ordering.

Use it where item names contain meaningful numbers.

Step 1: identify user-facing sorts

Inventory lists such as:

• contacts;
• countries;
• cities;
• file names;
• product names;
• categories;
• glossary terms;
• index entries;
• search results;
• table columns.

Not every sort is linguistic.

A technical log sorted by machine ID may intentionally use binary order.

Classify the list before changing it.

Step 2: distinguish sort order from search relevance

A search engine may rank by:

• relevance;
• date;
• popularity.

Within equal relevance, collation may provide alphabetical tie-breaking.

Do not replace relevance ranking with alphabetical collation.

Use collation where alphabetical comparison belongs.

Step 3: use the target locale

A string list does not “know” how it should sort.

The application needs a locale such as:

• sv-SE;
• de-DE;
• fr-FR.

This is where BCP 47/locale routing matters.

If the application sorts German text under English collation, the translation itself cannot correct the order.

Step 4: understand collation strength

Collation engines often compare text at levels such as:

Primary

Base letters.

Secondary

Accents/diacritics.

Tertiary

Case and other distinctions.

Additional/quaternary/identical behavior

Used for finer tie-breaking depending on configuration.

The exact terminology belongs to the library, but the principle is simple:

the product chooses how much difference matters.

Example: accent-insensitive search versus accent-sensitive sort

Search may want:

cafe

to find:

café.

Alphabetical display may still distinguish the accented form according to locale conventions.

One comparison policy should not automatically serve every feature.

Step 5: case sensitivity

Should:

apple

and:

Apple

sort together?

Usually yes in user-facing lists.

Which appears first when otherwise equal?

That is a tie-breaking choice.

Do not use ASCII uppercase-before-lowercase behavior by accident.

Step 6: punctuation

Strings can contain:

• spaces;
• hyphens;
• apostrophes;
• periods;
• symbols.

ICU/CLDR provide options for handling punctuation as variable or ignorable at certain strengths.

The correct choice depends on the list.

Worked example 4: names with punctuation

Names:

• De Anza
• de-luge
• deanza

A raw sort and a punctuation-ignoring sort can differ.

For person names, follow locale/product expectations.

For technical identifiers, preserve punctuation significance.

Step 7: apostrophes in names

Names such as:

• O’Connor;
• D’Angelo;
• l’Hôpital

should not be sorted using an English-only punctuation hack.

Use the locale collator.

User-name sorting is culturally sensitive.

Step 8: particles and surnames

Human name sorting can depend on:

• surname particles;
• given/family order;
• locale conventions.

Collation alone cannot determine which substring is the surname.

Use a person-name data model if the product promises sophisticated contact sorting.

Do not split names with one global rule.

Step 9: numbers inside strings

Numeric collation treats digit sequences as numbers.

Useful for:

• Chapter 2;
• Chapter 10;
• Version 3;
• Room 12.

But version strings can have special semantics.

1.10

is not necessarily numeric 1.1.

Use domain-specific version sorting when needed.

Step 10: dates should not be sorted as localized text

Display:

19 September 2026

Do not sort the displayed string alphabetically to determine chronology.

Sort by the underlying date value.

Collation is for linguistic strings.

Typed data should use typed comparison.

Step 11: currencies and numbers should use numeric comparison

Same principle.

Do not sort:

• $100;
• $20;
• $3

as strings.

Sort the numeric amount.

Use collation only for labels.

Step 12: normalization and collation

Canonically equivalent strings should normally collate consistently.

Mature Unicode collators handle canonical behavior appropriately.

Still, a product mixing raw string sort and ICU sort can behave differently.

Choose one comparison layer for user-facing lists.

Step 13: locale tailorings

The Unicode Collation Algorithm provides a default framework.

CLDR supplies locale-specific tailorings.

A tailoring adjusts the generic order to match local conventions.

Do not hand-code Swedish, German, Spanish, or other alphabet rules when standard locale data already exists.

Use current libraries.

Step 14: language-specific letters

Examples across languages include letters or sequences with special ordering.

The exact behavior depends on locale.

Your QA fixture should include the special characters relevant to each supported language.

Ask the language lead for a small test list.

Step 15: digraphs and contractions

Some collation systems treat multi-character sequences specially.

A raw character-by-character sort can be wrong.

Locale data can encode contractions.

Do not approximate them with ad hoc string replacements.

Step 16: script ordering

A list can contain:

• Latin;
• Cyrillic;
• Greek;
• Han;
• Arabic.

What order should scripts appear?

The default Unicode collation provides an order.

Some products may tailor script order.

For multilingual directories, decide deliberately.

Step 17: mixed-script names

A contact list may contain:

• English;
• Japanese;
• Arabic;
• Cyrillic names.

Possible strategies:

• one locale-aware global sort;
• group by script;
• transliteration index.

The correct product behavior depends on user needs.

Do not let database code-point order become the accidental strategy.

Step 18: transliteration and sorting

Some address books sort non-Latin names by transliterated reading.

That requires:

• pronunciation/readings;
• transliteration data;
• locale-specific logic.

Collation alone does not invent pronunciation.

For Japanese names, kana reading fields may be necessary.

Step 19: Chinese collation choices

Chinese sorting can use:

• pinyin;
• stroke;
• radical/stroke;
• other conventions.

A single “Chinese alphabetical order” does not exist.

If the product needs a specific order, use the relevant locale/collation setting and test with users.

Step 20: Japanese ordering

Japanese indexes may use kana order and readings.

Kanji strings may need phonetic reading fields for user-friendly alphabetical indexing.

Do not sort raw Han code points and call it Japanese alphabetical order.

Step 21: Korean ordering

Korean Hangul collation should follow locale data.

Do not mix decomposed and composed Hangul under raw code-point sort.

Unicode normalization and collation libraries work together here.

Step 22: emoji and symbols

Emoji can appear in:

• user names;
• channel names;
• files.

The product should decide whether symbols:

• sort before letters;
• after letters;
• are ignored for primary comparison.

Use library behavior as a base and test actual user expectations.

Step 23: articles in titles

Some libraries or media products want titles sorted ignoring leading articles:

• The;
• A;
• An.

This is not generic collation.

It is domain-specific title processing.

If you strip articles, do it with language-specific rules.

Do not remove English articles from French or German titles.

Step 24: index headings

A long list may show index buckets:

A B C …

ICU provides alphabetic-index support.

This is better than generating A–Z manually for every locale.

Some scripts do not use the Latin alphabet.

Index labels should come from locale data.

Step 25: database collation

Databases have their own collations.

If the database sorts one way and the application sorts another, pagination can break.

Example:

Database page 1 returns 50 rows under database collation.

Application re-sorts them under ICU.

The global list is no longer correctly ordered across pages.

Align the sort layer with pagination.

Step 26: database versus application sorting

Options:

Database owns collation

Use a database collation that matches product locale behavior.

Application owns collation

Fetch enough data and sort in application.

For large datasets, this can be expensive.

Choose architecture deliberately.

Step 27: search indexes

Search systems may have:

• analyzers;
• sort keys;
• keyword fields.

Configure locale-aware sort keys where the search product supports them.

Do not sort search results by raw UTF-8 bytes.

Step 28: precomputed sort keys

ICU collators can generate sort keys for efficient repeated comparisons.

This is useful for large datasets.

But sort keys depend on:

• collation version;
• locale;
• options.

Do not persist them forever without versioning.

Collation data changes over time

Unicode and CLDR improve.

A library upgrade can change some sort order.

For most products this is desirable.

For persistent indexes, it may require reindexing.

Record collation version when stability matters.

Step 29: stable sorting

Two strings can compare equal at the chosen strength.

Example:

resume

and:

résumé

under an accent-insensitive primary comparison.

The product still needs deterministic order.

Use secondary/tertiary tie-breaks or stable original order.

Avoid random movement between refreshes.

Step 30: case/accent options should match the feature

A contact list may prefer accent-sensitive local order.

A search suggestion list may prefer accent-insensitive grouping.

A technical file list may preserve punctuation strongly.

Do not create one global collator and use it everywhere without review.

Step 31: QA with sorted fixture lists

For every supported locale, create a small list containing:

• plain letters;
• accented letters;
• locale-specific letters;
• mixed case;
• punctuation;
• numbers.

Store the expected order.

Run it after:

• ICU/CLDR upgrade;
• database migration;
• search-engine change.

This is regression testing for collation.

Worked example 5: Swedish fixture

Include names beginning with:

• A;
• Z;
• Å;
• Ä;
• Ö.

A correct Swedish order should reflect Swedish alphabet conventions.

If the application places Å beside A under an English-like sort, the fixture fails.

Step 32: language leads can provide five-minute fixtures

Do not ask linguists to test millions of records.

Ask:

Give us 10–20 strings that distinguish correct local sort from naive Unicode order.

That small expert list becomes an automated test.

This is a high-leverage collaboration.

Step 33: test UI sort toggles

A table can sort:

• ascending;
• descending.

Test both.

Descending should reverse the intended collation ordering, not introduce a separate code-point comparator.

Step 34: test null and empty values

Where do:

• empty string;
• null;
• whitespace-only values

sort?

This is a product rule.

Keep missing data handling separate from linguistic collation.

Step 35: test leading whitespace

User-generated names can begin with spaces.

Trim or preserve according to data policy before sorting.

Do not let invisible spaces move a record unexpectedly unless the whitespace is meaningful.

Step 36: test normalization variants

Include:

• NFC accented string;
• canonically equivalent NFD string.

They should usually collate together under a Unicode-aware collator.

If not, investigate the implementation.

Step 37: test width variants where relevant

East Asian text can contain:

• fullwidth;
• halfwidth

forms.

The collation strength/options can influence their relationship.

Use target-locale expectations.

Do not apply compatibility folding globally just to simplify sorting.

Step 38: test punctuation options

If the product ignores punctuation for primary sorting, test:

• A-B;
• AB;
• A B.

Then define tie-break behavior.

Punctuation-insensitive does not mean the strings are identical for display or identity.

Step 39: sort keys and cache invalidation

If you cache sort keys, include:

• locale;
• collation options;
• library/data version.

A cached Swedish sort key should not be reused under German collation.

This is machine metadata with linguistic consequences.

Step 40: locale switch

If the user changes app language:

• English → Swedish,

re-sort user-facing lists.

Do not keep the old order merely because records did not change.

Locale is part of the sort input.

Failure mode 1: raw code-point sort

Result: foreign alphabet order.

Repair: locale collator.

Failure mode 2: one English collator for all locales

Result: regional/script conventions ignored.

Repair: target locale.

Failure mode 3: numeric strings sorted lexicographically

Result: File 10 before File 2.

Repair: numeric collation/domain sort.

Failure mode 4: database and UI use different collations

Result: pagination disorder.

Repair: align sort ownership.

Failure mode 5: accents ignored everywhere

Result: locale distinctions flattened.

Repair: feature-specific strength.

Failure mode 6: persistent sort keys not versioned

Result: upgrade inconsistency.

Repair: reindex/version.

Failure mode 7: Chinese raw Han sort

Result: unusable index.

Repair: appropriate collation/reading data.

Failure mode 8: title articles stripped with English rules globally

Result: other languages damaged.

Repair: locale-specific domain rule.

Failure mode 9: user locale changes but list order stays

Result: mixed experience.

Repair: resort.

Failure mode 10: translation team asked to reorder source data manually

Result: unsustainable localization patch.

Repair: software collation.

A collation QA checklist

Feature:

• is this truly a user-facing linguistic sort?
• what locale?
• what data type?
• numeric option?
• accent/case strength?
• punctuation handling?

Architecture:

• database or app owns sorting?
• pagination aligned?
• search index aligned?
• sort keys versioned?

Testing:

• locale special letters?
• mixed case?
• accents?
• numbers?
• punctuation?
• normalization variants?
• mixed scripts?

A collation fixture format

For each locale:

locale: sv-SE
input: Ake, Zed, Åke, Äsa, Östen
expected: Ake, Zed, Åke, Äsa, Östen

Use real native-language examples approved by a language lead.

The code can then assert the order.

A 30-minute collation audit

10 minutes

Find user-facing .sort() calls and database ORDER BY clauses on localized text.

10 minutes

Identify which use raw/binary/default collation.

10 minutes

Test one locale with special ordering.

You can quickly find where localization quality depends on accidental defaults.

Search-intent transfer

People searching:

• “locale-aware sorting”
• “Unicode collation”
• “ICU Collator”
• “alphabetical order localization”
• “sort accented characters”

need one operational answer:

compare user-facing text with a locale-aware Unicode collation engine and validate the exact ordering options the feature requires.

That is the job this URL owns.

Transfer to dictionaries and glossaries

A multilingual glossary should sort headwords according to the selected language.

Do not sort French, Swedish, and Japanese terms under the same raw comparator.

This makes reference tools feel native.

Transfer to school vocabulary lists

Educational word lists can demonstrate local alphabetical order.

Students should see target-language conventions, not source-language sorting.

This is especially useful in bilingual resources.

Transfer to ecommerce

Product lists sorted A–Z should use customer locale.

SKU sort can remain technical.

Separate:

• product-name sort;
• identifier sort.

One is linguistic.

One is machine/business logic.

The deeper principle: alphabetical order is localized behavior

Translation changes words.

Localization also changes the rules by which those words are organized.

A correct target list in a wrong order is a subtle but persistent reminder that the software was built around another language.

Collation removes that friction.

Why this improves speed

Locale-aware collation prevents:

• manual list reordering;
• locale-specific sort hacks;
• language-review bug reports;
• repeated database exceptions.

One collator configuration can correctly order millions of strings.

That is far faster than fixing lists by hand.

Final operating model

identify linguistic sort → pass canonical target locale → choose strength/numeric/punctuation options → align database/application/search → build locale fixtures → reindex on relevant data-version changes → regression test

Sorting becomes infrastructure.

Translators can focus on the words themselves.

Build a sort contract per feature

A feature should document its sort behavior just as clearly as its locale.

Example:

Feature: Contact list Locale: user interface locale Collation: standard locale dictionary order Numeric: off Punctuation: normal locale handling Case: tertiary tie-break only Empty values: last Stable secondary key: contact ID

Another feature can use a different contract.

Example:

Feature: File browser Locale: user interface locale Numeric: on Primary key: filename Folders before files: product rule

Writing the contract prevents developers from assuming every list uses the same comparator.

Collation is part of information architecture

Users rely on ordering to find information quickly.

If a Swedish contact list places Å near A unexpectedly, the user has to scan more.

If File 10 appears before File 2, the user has to reinterpret the sequence.

Sorting is therefore not merely cosmetic.

It changes retrieval time.

That makes collation directly relevant to the “translate quickly” system: the product should not make readers pay for source-language assumptions after the translation team has done its job.

Locale-aware equality versus exact identity

A collator can consider two strings equal at one strength even when the original strings differ.

Example:

• resume;
• résumé.

At a base-letter level they may compare as equivalent.

That does not mean the product should merge their records.

Use collation equality for:

• sorting;
• search/grouping where appropriate.

Use stable IDs for:

• identity;
• database keys;
• deduplication unless the product explicitly defines linguistic equivalence.