Skip to content

Taxonomy

Locale-dependent comparison

The answer changes with the machine's locale.

What it looks like

  • toLowerCase on an identifier that will be compared.
  • localeCompare used for a stable sort, or < used for a human-facing one.
  • parseFloat on a number that a user typed.

Why it survives review

In the author's locale — and in CI, which is almost always C or en-US — the behaviour is exactly right. The defect only exists on somebody else's machine, or for somebody else's data, so it cannot be reproduced by the person reviewing it.

How to see it

  1. Decide whether each comparison is for a human or for a machine. Human-facing sorting should be locale-aware; identifiers and keys should not be.
  2. 'I'.toLowerCase() is not 'i' in Turkish. For identifiers, use a locale-independent fold.
  3. Number and date parsing from user input is locale-dependent. Check which locale is assumed and whether it is stated.

A minimal pair

Correct

return a.id.toLowerCase() === b.id.toLowerCase();

Defective

return a.id.toLocaleLowerCase() === b.id.toLocaleLowerCase();

Under a Turkish locale, ID and id stop matching, and the lookup fails for those users only.

Practise it

2 diffs in the corpus carry this class. They are not listed, because knowing which diff contains what would make finding it a comprehension question about this page.

Go to the exercises