zh-TW is an unsupported culture code

[smoogipoo]

We're currently pulling culture codes from the osu-web directory listing.

zh-tw is one of them, and the only one which looks to be unsupported by .NET. This particular localisation does not generate a zh-tw directory in the output path:

I don't know exactly how this is currently working in osu!/from where it's managing to pull the string resources, but it causes issues such as:

• The culture appears in JetBrains Rider's Localization Manager as its own entity:
  
• External rulesets can't include the zh-TW localisation (see: Interact with localizaton karaoke-dev/karaoke#1266)

Other projects, notably Humanizer and dotnet-roslyn use zh-Hans and zh-Hant in place of our zh and zh-TW locales respectively.

I can't really find any documentation on the supported culture codes - the closest I can find is documentation related to Bing maps which lists zh-Hans and zh-Hant: https://docs.microsoft.com/en-us/bingmaps/rest-services/common-parameters-and-types/supported-culture-codes, however we should be reasonably able to trust that JetBrains Rider's visualisation is accurate and that zh-TW is the only one which is unsupported.

[andy840119]

zh-TW Means it's a language related to the country, and zh, zh-Hans and zh-Hant means it's just a language.
Like the relationship between ja-JP and ja.
Not really sure it will ba another reason to change zh, zh-TW into zh-Hans and zh-Hant
.
But the weird things is that compile osu.Desktop generated zh-TW (And it works on lazer also)

[smoogipoo]

But the weird things is that compile osu.Desktop generated zh-TW (And it works on lazer also)

Aha. So that must be why lazer's working.

Weirdly, compiling osu.Game.Resources locally doesn't generate zh-TW but it's included in the Nuget.org nupkg? The only thing I can come up with is that osu-resources is packaged on Windows whereas neither of us are using it.

Edit: Compiling on Windows via dotnet build doesn't work either. Bizarre.

[smoogipoo]

It looks like it may be related to the available culture codes of the system.

• zh-CN and zh-TW .NET resources are not generated in windows-latest (windows-2022) actions/runner-images#5189 Describes a similar experience using the windows-latest GitHub runner as opposed to windows-2019. For reference, our AppVeyor runner uses a similar windows-2019 image. So it looks like the zh-TW culture code has also been removed in more recent Windows releases.
• .Net Core MVC Localization cannot work on ubuntu16.0.4 aspnet/Mvc#7307 (comment) Describes Ubuntu and Windows returning different available cultures. This matches up with what I'm seeing. Of particular importance, zh-Hant is a superset (i.e. a parent) of zh-TW which is listed in both systems, so we should not cause any breaking changes by using zh-Hant.
• zh-CN and zh-TW .NET resources are not generated in windows-latest (windows-2022) actions/runner-images#5189 (comment) Describes zh-CN and zh-TW as "obsolete", matching the above, though no particular reference is given for this.
• Cultures aliased by ICU cannot be used for resource localization on non-Windows environments dotnet/msbuild#3897 Is an open issue to fix this in MSBuild.

I still think using zh-Hant and conforming to existing projects is a good path forward.

[andy840119]

I think it might be a suitable way.

BTW, i'm curious about will osu-web follow the same roles?

Also, not really sure language in osu-web is more related with country(Because it have country flag? Or is that a language flag?)
So will use something like ja-JP is more suitable than ja?

[smoogipoo]

I'm unsure what to do with osu-web and crowdin for that matter.

Initially I was thinking this could be a osu-localisation-analyser tool-specific thing, maybe a CLI option for converting zh-TW to zh-Hant, in order to avoid having to change crowdin + coordinate with peppy's private scripts that I don't have access to.

[smoogipoo]

For the time being, let's wait and see if .NET SDK 6.0.300 fixes the issue. It looks to be on their radar in some fashion:
dotnet/msbuild#7331 (comment)

[bdach]

Not sure how to interpret the linked chain of pulls above in the context of waiting for SDK 6.0.300. Are these changes to be reviewed now, or are they just PR'd for visibility and to be reviewed later if upstream doesn't include a workaround on their side?

[smoogipoo]

They can be reviewed. At the end of the day I think whatever the SDK does is going to be considered a "hack" as this seems to have been an intentional change.