Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Locale deserialize 'zh-hant_CN'

See original GitHub issue

zh-hant_CN will convert to zh_HANT_cn Locale include (language, country, variant), Locale.toString() use ‘_’ to split then {language}_{country}_({variant}_# | #){script}-{extensions}

but Jackson deserialize Locale use ‘-’ or ‘_’ : ( code: FromStringDeserializer.Std._deserialize

iana language-tags

zh-Hant	Chinese, in traditional script	[Mark_Davis][Mark_Davis_2]	
zh-Hant-CN	PRC Mainland Chinese in traditional script	[Mark_Davis][Mark_Davis_2]	
zh-Hant-HK	Hong Kong Chinese in traditional script	[Mark_Davis][Mark_Davis_2]	
zh-Hant-MO	Macao Chinese in traditional script	[Mark_Davis][Mark_Davis_2]	
zh-Hant-SG	Singapore Chinese in traditional script	[Mark_Davis][Mark_Davis_2]	
zh-Hant-TW	Taiwan Chinese in traditional script	[Mark_Davis][Mark_Davis_2]

rfc4647 language lookup

  Example of a Lookup Fallback Pattern

   Range to match: zh-Hant-CN-x-private1-private2
   1. zh-Hant-CN-x-private1-private2
   2. zh-Hant-CN-x-private1
   3. zh-Hant-CN
   4. zh-Hant
   5. zh
   6. (default)

	public static void main(String[] args) {
		System.out.println(new Locale("zh-hant", "CN"));
	}

in jdk1.5 -> 1.8

jdk1.5	zh-hant_CN
jdk1.6	zh-hant_CN
jdk1.7	zh-hant_CN
jdk1.8	zh-hant_CN

others: #1344 #1600

Issue Analytics

State:
Created 6 years ago
Comments:6 (4 by maintainers)

Top GitHub Comments

2reactions

cowtowncodercommented, Mar 24, 2018

At this point I am not sure what expected handling would be; and I do not think proposed solution is correct. It is NOT correct to say that underscore (_) is the canonical separator, for example: RFCs that specify this claim hyphen should be used. Yet JDK prefers underscore for legacy reasons. Some more discussion can be found from answers on:

https://softwareengineering.stackexchange.com/questions/325458/parse-both-en-us-and-en-us-as-locale-in-java/367706#367706

Finally, I don’t think Jackson 2.9 should change handling unless it can be guaranteed change does not break existing usage. Because of this, I think I will change 3.0 to use toLanguageTag() and forLanguageTag(), but leave 2.9 as is.

0reactions

cowtowncodercommented, Mar 19, 2018

Another possibility: JDK 1.7 has Locale.forLanguageTag(String). I could possibly change code for next minor or major version to use that (although probably not safe for patch), if that is an improvement.