You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
馃悰 Bug Report
With option
sort: true
, the default sorting usesString.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
after running
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.
The text was updated successfully, but these errors were encountered: