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
We have noticed an issue with the LocaleChangeInterceptor when a request parameter is set to "de_de" the LocaleChangeInterceptor creates locale "de_DE_de". With other locales
like "en_us" it returns "en_US" correctly. We have isolated this issue to any lowercase locale with same language and country parameter for example, de_de, nl_nl, etc.
Here is a complete list of affected locales
bg_bg Bulgaria
hr_hr Crotia
de_de Germany
fi_fi Finland
fr_fr France
nl_nl Netherland
hu_hu Hungary
is_is iceland
it_it Italy
lv_lv Latvia
lt_lt Lithuania
mk_mk Macedonia
mt_mt Malta
no_no Norway
pl_pl Poland
pt_pt Portugal
ru_ru Russia
sk_sk Slovakia
th_th Thaliand
tr_tr Turkey
Issue is with the org.springframework.util.StringUtils.parseLocaleString method. When the localeString is parsed it incorrectly detects the endindex of the country code since the language and country are the same "de" it gets the first index of de which is actually the language. End result is it thinks the country is a variant. By changing localeString.indexOf to localeString.lastIndexOf it corrects the issue.
public static Locale parseLocaleString(String localeString) {
String[] parts = tokenizeToStringArray(localeString, "_ ", false, false);
System.out.println(parts.length);
String language = (parts.length > 0 ? parts[0] : "");
String country = (parts.length > 1 ? parts[1] : "");
String variant = "";
if (parts.length >= 2) {
// There is definitely a variant, and it is everything after the country
// code sans the separator between the country code and the variant.
int endIndexOfCountryCode = localeString.lastIndexOf(country) + country.length(); //@FIX change "localeString.indexOf" to localeString.lastIndexOf"
// Strip off any leading '_' and whitespace, what's left is the variant.
variant = trimLeadingWhitespace(localeString.substring(endIndexOfCountryCode));
if (variant.startsWith("_")) {
variant = trimLeadingCharacter(variant, '_');
}
}
System.out.println(language + ":" + country + ":" + variant);
return (language.length() > 0 ? new Locale(language, country, variant) : null);
}
commit f1246a43175dc040584140c9792beb5dce521e9b
Author: Chris Beams <cbeams@vmware.com>
Date: Thu May 17 09:36:38 2012 +0300
Fix locale parsing error with en_en, tr_tr, etc
Previously, StringUtils#parseLocaleString would parse locale strings
having the same lowercase token for both language and country
incorrectly, e.g. 'tr_tr' would parse to 'tr_TR_tr' as opposed to the
expected 'tr_TR'.
This commit fixes this behavior by using using String#lastIndexOf
instead of String#indexOf when determining the location of the country
code token.
Issue: SPR-9420
Arian Maleki opened SPR-9420 and commented
We have noticed an issue with the LocaleChangeInterceptor when a request parameter is set to "de_de" the LocaleChangeInterceptor creates locale "de_DE_de". With other locales
like "en_us" it returns "en_US" correctly. We have isolated this issue to any lowercase locale with same language and country parameter for example, de_de, nl_nl, etc.
Here is a complete list of affected locales
Issue is with the org.springframework.util.StringUtils.parseLocaleString method. When the localeString is parsed it incorrectly detects the endindex of the country code since the language and country are the same "de" it gets the first index of de which is actually the language. End result is it thinks the country is a variant. By changing localeString.indexOf to localeString.lastIndexOf it corrects the issue.
Affects: 2.5.6, 3.1 GA
Referenced from: commits f1246a4
The text was updated successfully, but these errors were encountered: