Sort the GUI language selector by display name#703
Open
lhaeger wants to merge 1 commit into
Open
Conversation
The old sort key was country -> language -> variant on the Locale identifier. Because Locale.getCountry() returns "" (empty string, not null) for a language-only locale and compareStrings only short-circuits on null, every country-coded entry (en_US, pt_BR, zh_CN, en_GB) silently sorted after every language-only entry (de, fr, ...) in the GUI language selector - regardless of how its display name read. This made a typical "add en_GB and en_US for clearer English variants" configuration land at the bottom of the picker, dependent on country code rather than on visible name. There is no separate sort or order property in locale.properties; the comparator IS the only knob. Switch the comparator to sort by the configured .name field (the display name users actually see) using java.text.Collator with the JVM default locale. Country code, language code and variant no longer participate in the order; a country-coded locale is interleaved with the rest by its display name. A small TestNG suite in infra/common covers three cases: monotonicity of the sorted list under the default Collator, the specific scenario where a country-coded "Chinese" (zh_CN) precedes a language-only "Deutsch" (de) because "C" collates before "D", and the edge case of two locales with identical display names compareTo()-equal.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sort the GUI language selector by display name
Summary
The GUI language selector lists locales in an unusual order. This pull
request changes the order to sort by the configured display name, which
is what users typically would expect. The change affects only the visual
presentation; locale resolution is not touched.
Problem
The comparator in
AvailableLocale.LocaleDescriptorsorts by country codefirst, then by language, then by variant.
Locale.getCountry()returns anempty string for language-only locales such as
enorde, and an emptystring sorts before any real country code. As a result, every locale with a
country code (for example
en_US,pt_BR,zh_CN) appears below everylanguage-only entry, regardless of how the entries read in the selector.
Adding
en_USanden_GBto${midpoint.home}/localization/locale.propertiesplaces both at the bottom of the list. There is no separate sort property in
locale.properties, so the comparator is the only place this can be fixed.Change
The comparator now sorts by the configured display name (
.nameinlocale.properties) usingjava.text.Collatorwith the JVM default locale.The country code, language code, and variant no longer affect the order. With
this change, "English (UK)" appears between "Deutsch" and "Español"; the
familiar
pt_BRandzh_CNdefaults move to the alphabetical position oftheir display names ("Português (Brasil)", "中文").
Using
Collatorrather than plain string comparison handles accents andnon-Latin scripts as users would expect.
(Before vs. After)
Compatibility
AvailableLocale.AVAILABLE_LOCALESis read only by code that presents thelist to a user. Locale resolution compares
Localeobjects directly anddoes not depend on the descriptor order. Existing
locale.propertiesfileskeep working unchanged.
Tests
A new
AvailableLocaleTestininfra/commonadds three cases: the sortedlist is in non-decreasing collation order; a country-coded locale "Chinese"
(
zh_CN) sorts before a language-only locale "Deutsch" (de); two localeswith identical display names compare as equal.