Choose a directory order without merging equal-looking entries

Define the directory’s audience and membership

Unicode Collation Algorithm revision 55 is approved and stable, version 18.0.0. It distinguishes collation from code-point order and warns against comparing keys from different collations.

Write down who uses the directory and what they are trying to locate. A bilingual supplier list and a local exhibition index may need different editorial decisions. Select a supported audience setting with the language owner rather than treating the administrator’s own desktop preference as the customer requirement. Keep the language decision visible beside the directory brief.

Freeze a small fictional membership list with stable record references. Include two similarly named entries that must both remain present. Record any legitimate exclusions separately so that an ordering review cannot quietly become a filtering review. The starting count and the final count should reconcile even when the appearance of the list changes.

Expose a tie without erasing either record

Our Node 24.22.1, ICU 78.3, Unicode 17.0 fixture uses Intl.Collator with locale en and sensitivity base. Lumen and LUMEN compare equal. Records R31 and R44 both remain; the fixture orders their tie by record ID.

The final tie rule is an editorial engineering choice for this fixture, not a universal linguistic preference. Explain why the directory needs a repeatable order and who can approve that choice. If readers need a visible distinction, add truthful context to the entry rather than relying on an invisible technical reference to make the display understandable.

Reverse the incoming order in a second test and compare the complete result. Then divide the resulting list at the proposed page boundary. Each expected record should appear once in the retained snapshot. A directory can contain every entry in its database yet still be confusing when an unstable presentation sends the same entry to successive pages while hiding its neighbor.

Keep page navigation and evidence coherent

Record the requested audience setting, the resolved implementation settings and the version supplied by the technical owner. Do not infer the actual setting from the language of the surrounding interface. A translated page can still be using an unrelated default for its list. Include the resolved values in the review packet so a later discrepancy has a concrete starting point.

Inspect a page transition, a return to the previous page and a repeat of the same request against the same fixture snapshot. Distinguish a legitimate membership update from a presentation defect. If the data changed between captures, rebuild comparable evidence rather than blaming the comparison function for an inconsistent sample. The acceptance object is a defined list at a defined moment.

Ask the language reviewer to evaluate whether the order is useful for the intended audience. Technical reproducibility alone does not establish that judgment. Conversely, an intuitively attractive screenshot does not explain how ties will behave after new entries arrive. Both owners should understand the final contract without having to read a platform’s internal data structures.

Plan changes without rewriting identity

When a library or audience setting changes, compare the old and proposed ordered lists using record references. Highlight moves, additions, omissions and display-label changes separately. A moved entry is not automatically a duplicate or a content correction. Keep the approved labels intact unless the editor independently authorizes a change to them.

Retain the fixture and the reason for the tie rule with the release evidence. If the implementation cannot support the promised behavior, narrow the presentation or request an engineering decision; do not silently drop one of the troublesome entries. Acceptance means the intended readers can navigate a stable, complete directory under the declared setting, not that every language or future library will produce the same sequence.

Make the reasoning concrete.

A fictional maker directory contains two businesses with very similar display names. Its export step keeps only one after treating an ordering tie as evidence of a duplicate.

The publisher holds the lossy export and asks for a complete ordered list. It does not use a presentation decision to authorize record consolidation.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Audience

   Whose directory-reading expectation is being served?

2. Membership

   Which fixed record list must remain present?

3. Tie

   What is the approved disposition of indistinguishable ordering positions?

4. Runtime

   Which actual settings and version produced the evidence?

5. Navigation

   Does the retained snapshot cross pages without omission or repetition?

Watch for the wrong conclusion.

• Using a sorting result as a duplicate-record verdict.
• Comparing captures from different data snapshots.
• Inferring runtime settings from interface language.

Sources & scope

Workflows and business scenarios are original editorial analysis. Technical claims remain source-derived wherever repeated. Synthetic local computations are identified; unperformed visual or deployment checks are not claimed. No real account, content, permissions or transmission changes are authorized.

• Unicode Collation Algorithm →Primary standard or internationalization guidance · Supports: Supports the stated collation distinctions.