A list of user-visible names sorted with names.sort() puts "Zebra" before "apple" and orders accented words oddly. Why does JavaScript's default string ordering do that, and what does Intl.Collator do differently?

## Why the default order looks wrong With no comparator, sorting coerces each element to a string and orders by UTF-16 code unit — effectively by character number. ```js ['Zebra', 'apple', 'résumé', 'resume'].sort(); // ['Zebra', 'apple', 'resume', 'résumé'] ``` `'Z'` is U+005A (90), `'a'` is U+0061 (97), so every capital precedes every lowercase letter. `'é'` is U+00E9 (233), above all ASCII, so `résumé` lands after `resume` — and, in a longer list, after words starting with `z`. Nothing here is a bug; it is a defined ordering that simply is not the ordering a human expects to read. ## Collation is locale data "Alphabetical" is not one order. A few examples of genuine disagreement: - In **Swedish**, å, ä and ö are distinct letters that come *after* z. - In **German phonebook** collation (`de-DE-u-co-phonebk`), ä sorts as though it were "ae". - Case, accent and punctuation can each be significant or ignorable depending on what you are doing. `Intl.Collator` is the interface to that data. ```js const collator = new Intl.Collator('en'); ['Zebra', 'apple', 'résumé', 'resume'].sort(collator.compare); // ['apple', 'resume', 'résumé', 'Zebra'] ``` ## compare is a bound function `collator.compare` is an accessor that returns a function already bound to its Collator, which is why `sort(collator.compare)` works without a wrapper — the usual `this`-loss trap does not apply. It returns a negative number, zero, or a positive number, exactly the contract `sort` expects. ## The options that matter - **`sensitivity`** — `'base'` treats case and accent differences as equal, `'accent'` distinguishes accents but not case, `'case'` the reverse, and `'variant'` (the default for sorting) distinguishes everything. - **`numeric: true`** — compares embedded digit runs as numbers, so `item2` precedes `item10` instead of following it. - **`ignorePunctuation: true`** — drops punctuation from the comparison, useful for title lists. - **`caseFirst`** — `'upper'` or `'lower'`, for locales where you want a deterministic case order. - **`usage: 'search'`** — tunes the collator for matching rather than ordering; combined with `sensitivity: 'base'` it gives accent- and case-insensitive comparison for a filter box. ```js const loose = new Intl.Collator('en', { usage: 'search', sensitivity: 'base' }); loose.compare('resume', 'RÉSUMÉ') === 0; // true — a match for filtering ``` ## Collator versus localeCompare `'a'.localeCompare('b', locales, options)` is defined as constructing an `Intl.Collator` and comparing. For a single comparison it reads well. Inside a comparator it is a trap: sorting *n* elements performs on the order of *n* log *n* comparisons, and the naive form re-derives the collator each time. Building one `Intl.Collator` and reusing `compare` moves the setup cost outside the loop — the documented reason the constructor exists as a separate object. ## Sorting for display versus keying for storage A collation result is a locale-specific opinion, so it is not a stable key. Two consequences in real systems: 1. If a list is paginated by a database that sorts with its own collation, sorting the page again in JavaScript with a different collator produces visibly inconsistent order across pages. Pick one authority. 2. Never persist "sorted position" derived from a collator — locale data is updated with the runtime, and a different user's locale gives a different order anyway. For deduplication or identity, do not use a case- and accent-insensitive collator as an equality test on stored keys; that is a display-level notion of sameness, and using it as a uniqueness rule silently merges distinct records. ## Ties A collator can report two different strings as equal — that is the whole point of `sensitivity: 'base'`. Sorting is stable, so equal elements keep their input order, which is usually what you want but means the visible result depends on the order the data arrived in. If you need a deterministic tiebreak, compare a secondary field explicitly.