Earlier quoted context omitted.
I agree. Locale.getLanguage() returns the language code. The specific Locale() constructor used in the code is documented as taking a parameter: "An ISO 639 alpha-2 or alpha-3 language code, or a language subtag up to 8 characters in length. See the Locale class description about valid language values." I'd guess the app code lucked out on the string returned from getDisplayLanguage() getting mapped to the appropriat…
Would stronger typing help here? If I were to design those APIs, I'd maybe suggest a more opaque type called "LanguageCode" that is NOT a String and could not be returned from or passed as a String. Then getLanguage() could return a LanguageCode type, and the Locale() constructor could take the LanguageCode type as its parameter, and then tooling could enforce that you can't mix LanguageCode with String. Then, callin…
While we're not programmers, we can say with certainty that hitting the keys harder, does NOT change the behavior.
-Ops Team.