Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index

2010.11.11 17:12, Aron Xu rašė:
But keep in mind Hans and Hant cannot cover different kinds of
Chinese, for example there are differences between HK and TW, but they
are combined to one single Hant, which perhaps could not be accepted
by people who are using them, :)

Of course. The question though is if there will ever be two different Simplified Chinese localizations of LO. Are those differences really noticable?

Quoting the Apple document I linked to before:
The new standard defines new tags for the traditional Chinese (|Hant|) and simplified Chinese (|Hans|) scripts. Thus, traditional Chinese spoken in any country uses the code |zh-Hant|. Traditional Chinese, as it is spoken in Taiwan, now uses the locale code |zh-Hant_TW|.

IMHO, you can think of zh-Hans as zh@hans in glibc terms. Script is simply a different kind of locale modifier than country. Since glibc has four Chinese locales, they probably don't need the modifier. But if they needed it, the final locale codes would probably look like zh_CN@hans.

 From what I've read, it's going to be obsoleted in future versions of .Net.
Yes, I've wrote that it is to be replaced, but remember Windows XP is
still running on many people's desktops and laptops, I'm not sure this
situation can change very rapidly in near future.

XP will be EOL'd in 2014 anyway. It won't stay for ever, after all...
Regardless of that, I think our goal is for LO to work as expected in your locale. If it does, I don't see the exact language code as a problem.

And some other
applications are still using zh-CHS as a tag on there release
documents to tell people it is in Simplified Chinese, no matter
whether they have to use zh-Hans in new .NET, they just show such
information to end users and people get confused.

Hm, IMO, locale code is a technicality that the end users should not care about at all.

Well, I don't mind BCP 47 if it works well, but I've mentioned before
that it cannot cover all different variants, it's just a loosely
defined standard. To be more precise to end users, we might have to
place two sets of translations, zh_TW and zh_HK, into zh-Hant
packages. They are not the same, so we need to do it separately, even
if we make them into a single package to end users.

Not necessary, as stated above. zh_TW@hant and zh_HK@hant could be used, and then again specifying the country code would probably make the need for a script code obsolete... Ha!:)

Listing language variants with different regions is a good way to
solve conflicts in our development. On the other hand, using a loosely
defined name for our release language pack (which contains everything
fit into the category) is probably good for users.

I think in the end it's about Chinese (Simplified) vs. Chinese (China). Until we don't have two country versions of Simplified or Traditional, we can just skip country codes, I think.


E-mail to for instructions on how to unsubscribe
List archives are available at
All messages you send to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.