How should locale-specific sorting stay consistent between the browser, API, and database?

Use one product-level ordering contract and make the server authoritative for any paginated or shared list. Define the locale, collation settings, and a final unique tie-breaker explicitly, then apply that contract in the API and database. Let the browser display and filter within that contract, but do not expect independently configured browser and database collators to produce identical order by accident.

What should the ordering contract include?

A locale string alone is not enough. The ICU collation API guide explains that a collator defines the properties and behavior of sort ordering, and that ICU supports predefined collators for locales plus locale keywords and custom rules in some cases. PostgreSQL collation documentation likewise treats collation as part of the expression used by ORDER BY, not a vague database-wide preference.

For an application contract, write down at least:

• locale or collation identifier used for user-visible ordering
• any comparison behaviors your stack depends on, such as case, accents, digit-aware ordering, or punctuation treatment, but only if your chosen browser/runtime and database settings can express them
• normalized sort field, if you derive one
• immutable unique tie-breaker, usually id
• cursor format bound to that exact ordering

Without the tie-breaker, equal display names produce unstable result boundaries. The ICU collation concepts guide describes multiple comparison levels and an identical level used as a tiebreaker inside collation itself. At the product level, you still want your own final unique key so the result set has a total order.

Which tier should own the final order?

If the UI shows a complete in-memory dataset, browser sorting with ECMAScript Intl.Collator is fine. But once the list is paginated, cached, or shared across clients, the backend should own the full order and page boundaries. Sorting each fetched page in the browser only creates locally sorted pages, not a globally sorted list.

That matters because browser and database runtimes can use different locale data and collation providers. PostgreSQL documents that a collation object has a provider such as libc or icu, and that ordering operations use the collation of the sort key. ICU also documents that collator behavior comes from the configured collator instance and locale tailoring in the ICU API guide. Even when both tiers say de or fr, do not promise identical ranking from separate runtimes. Use the browser for presentation details, not for redefining server page order.

What does a concrete contract look like?

Suppose you sort customers by display name for a German-language workspace:

1. Primary sort: display_name with your chosen German collation.
2. Comparison behavior: document whether accents, case, punctuation, or digit ordering matter for this list, based on the settings your stack actually supports.
3. Final tie-breaker: ascending immutable customer_id.
4. Cursor: (display_name, customer_id) under that same contract.

Now consider Muller, Müller, Mueller, and another Müller. Your database query should order by the chosen collation and then customer_id. The API returns rows in that order and encodes the last tuple into the cursor. The browser may highlight matches, group results, or sort a small already-loaded subset for a temporary local view, but it should not silently reshuffle server-paginated results.

Should you persist sort keys or compare them across systems?

Usually no. The ICU collation concepts guide says sort keys are most useful in databases as a performance technique, while the ICU API guide explains that they are generated from a particular collator. Treat sort keys as implementation-specific optimization artifacts tied to the collator configuration that generated them; avoid using them as a durable cross-system contract. Also keep sorting separate from equality: two names can compare equal at one collation strength while still be different application values, as the ICU comparison-level discussion makes clear.

How do you test consistency?

Test the contract, not internals. Build a fixture corpus with accents, case differences, punctuation, digits, and duplicate labels. Assert the API order, database ORDER BY, and browser rendering behavior against the same expected sequence for a pinned environment. When collation libraries or providers change, rerun fixtures and review intentional order changes instead of assuming upgrades are invisible.

Follow-up: Can the browser re-sort server results for the current page only?

Only for an explicitly local view. Do not present that as the canonical order if pagination, cursors, or exports still come from the server contract.

Follow-up: Is collation the same as equality or uniqueness?

No. Collation defines ordering and some comparisons; it is not your business-level identity rule. Keep uniqueness and record identity on separate fields and constraints.

Next step: write a one-page ordering contract for each user-visible sorted list, then add cross-tier fixture tests before changing any locale settings.

Reviewed: 2026-09-06