Don't use locale-sensitive sorting as the default

[noppa]

🐛 Bug Report

With option sort: true, the default sorting uses String.prototype.localeCompare to compare the two keys, without specifying the locale to use. As a default, localeCompare will then use the host environment's locale setting.

This is a bad default value to have, because international teams may have people using different locale settings in their machines. It doesn't make sense that the tool would suddenly change the key ordering just because the parsing is done at some other team member's computer than who orginally parsed the existing translations file.

Different localizations sort certain characters like "ä" differently, so this default is almost nondeterministic,
and will create messy diffs every time someone adds new translation keys with a different localization settings in their computer as the other team members have.

To Reproduce

A minimal reproducible example.

Expected behavior

In that example repository, running

LC_ALL=fi_FI npm run update-translations

after running

LC_ALL=en_EN npm run init-translations

should just add the new translation key "c". It should not change the order keys "a" and "ä" are sorted.

There's a more in depth description of the issue and steps to reproduce in the minimal reproducible example -repository.

Proposed solution

The default sorting should just be based on the UTF-16 code units values. This may produce sort order that looks a bit weird for people who are used to some other sort order in their own locale, but it will at least be the same and predictable order for everyone. And if they really care about the sort order, they can of course just define their own sorting function that uses some specified localization setting.

diff --git a/src/helpers.js b/src/helpers.js
index 7045af9..b6e1892 100644
--- a/src/helpers.js
+++ b/src/helpers.js
@@ -262,7 +262,7 @@ function makeDefaultSort(pluralSeparator) {
       return getPluralSuffixPosition(key1) - getPluralSuffixPosition(key2)
     }
 
-    return singularKey1.localeCompare(singularKey2)
+    return singularKey1 > singularKey2 ? 1 : -1
   }
 }

[karellm]

@noppa Can you please make a PRs with a failling test case?