On Thu, Nov 9, 2017 at 11:19 PM, Alexandre Julliard <julliard@winehq.org> wrote:

Zhiyi Zhang <yi.gd.cn@gmail.com> writes:

> Superseded patch 138395.
>
> LocaleNameToLCID now can handle zh-Hant and zh-Hans correctly with
> get_default_children().get_default_children() acts as a map from a
> parent language to its default child language.Since zh-Hant and
> zh-Hans are not actual locale identifiers. All locale info of zh-Hant
> and zh-Hans are directly mapped to its own child language, zh-HK and zh-CN.

The LOCALE_SPARENT data is a good addition, but this could be split to a
separate patch. Also you should be able to extend the existing
get_default_sublang() logic instead of adding another table of defaults.

--
Alexandre Julliard
julliard@winehq.org

OK, I'll split LOCALE_SPARENT into a different patch.

I tried extending get_default_sublang(). But it didn't work well.

get_default_sublang depends on a LCID as parameter. However,

currently there is no way to know the LCID of zh-Hant is 0x7c04.

We need another internal map to do that. Maybe missing a .nls file?

But in Windows it seems there isn't separate .nls for zh-Hant or zh-Hans.

Getting all locale info from zh-Hant just returns the same info from zh-HK.

Even so, zh-Hant(0x7c04) and zh-Hans(0x0004) have the same primary langid

but different sublang.I think getting different sublang from get_default_sublang()

sort of defeat its "get default" purpose.That's why I wrote a separate function that

takes in LOCALE_SPARENT to do that.

Parental relationships of some Chinese locales, they all have "zh"(which is 0x04

,according to https://msdn.microsoft.com/en-us/library/windows/desktop/dd318693(v=vs.85).aspx

and LCID structure spec. Their lower 10 bits) as primary language identifier.

zh-CN → zh-Hans → zh → Invariant
zh-HK → zh-Hant → zh → Invariant

zh-TW → zh-Hant → zh → Invariant

Any suggestions?