Bug 872282 - Add Chinese (Hong Kong) - zh_HK - locale to anaconda
Summary: Add Chinese (Hong Kong) - zh_HK - locale to anaconda
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 872791
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-01 17:37 UTC by Adam Williamson
Modified: 2014-02-05 12:48 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 12:48:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot of Gnome desktop with zh_HK locale (226.74 KB, image/png)
2012-11-02 19:45 UTC, Steve Tyler
no flags Details
screenshot showing four Chinese language choices in installer language menu (133.79 KB, image/png)
2012-11-05 06:56 UTC, Steve Tyler
no flags Details
demo patch to list four Chinese language choices in the installer language menu (1.28 KB, patch)
2012-11-05 07:14 UTC, Steve Tyler
no flags Details | Diff

Description Adam Williamson 2012-11-01 17:37:06 UTC
As discussed near the end of https://bugzilla.redhat.com/show_bug.cgi?id=858801 - especially comment 25 - it would be nice to have the zh_HK locale available in anaconda's list. HK users can pick zh_TW as both Taiwan and Hong Kong use very similar variants of traditional Chinese, but there are a few translation differences and some differences in the other aspects of localization (rendering of dates and numbers for e.g.).

Comment 1 Chris Lumens 2012-11-01 21:03:27 UTC
Once there's a translation of some reasonable completeness (I see 0% on transifex right now), this is as easy as adding to po/LINGUAS.

Comment 2 Adam Williamson 2012-11-01 21:30:02 UTC
I'll CC the guy who was going to script the conversion of the TW translation.

Comment 3 Cheng-Chia Tseng 2012-11-02 02:20:54 UTC
I am going to use the script provided by gnome-il18n[1] to do the conversion these days.

1. http://git.gnome.org/browse/gnome-i18n/tree/zh_HK/tw2hk.pl

Comment 4 Chris Lumens 2012-11-02 14:21:50 UTC
Note to self:  not just as easy as po/LINGUAS.  May also need to be added to mangleMap.

Comment 5 Steve Tyler 2012-11-02 15:36:08 UTC
If the translation goes under zh_HK, mangleMap shouldn't need to be changed:

$ ls -d /usr/share/locale/zh_HK

>>> 'zh_HK' in babel.localedata.list()
True

>>> print babel.Locale('zh', 'HK').english_name
Chinese (Hong Kong SAR China)

>>> print babel.Locale('zh', 'HK').display_name
中文 (中国香港特别行政区)

Comment 6 Steve Tyler 2012-11-02 16:06:35 UTC
Babel supports both simplified and traditional scripts for zh_HK:

>>> print babel.Locale('zh', 'HK', script='Hans').english_name
Chinese (Simplified Han, Hong Kong SAR China)
>>> print babel.Locale('zh', 'HK', script='Hant').english_name
Chinese (Traditional Han, Hong Kong SAR China)
>>> 
>>> print babel.Locale('zh', 'HK', script='Hans').display_name
中文 (简体中文, 中国香港特别行政区)
>>> print babel.Locale('zh', 'HK', script='Hant').display_name
中文 (繁體中文, 中華人民共和國香港特別行政區)

Comment 7 Cheng-Chia Tseng 2012-11-02 16:27:48 UTC
Hong Kong people uses Hant (Traditional Chinese) mostly.

Comment 8 Steve Tyler 2012-11-02 16:52:12 UTC
OK, thanks. Maybe we will need to add an entry to mangleMap then. I don't read Chinese, but it looks like the default script for zh_HK is Hans (Comment 5). Could you confirm that?

Comment 9 Steve Tyler 2012-11-02 19:45:22 UTC
Created attachment 637230 [details]
screenshot of Gnome desktop with zh_HK locale

This is to confirm that setting the locale in F17 to zh_HK results in traditional Chinese being displayed.

Comment 10 Cheng-Chia Tseng 2012-11-03 02:40:50 UTC
(In reply to comment #8)
> OK, thanks. Maybe we will need to add an entry to mangleMap then. I don't
> read Chinese, but it looks like the default script for zh_HK is Hans
> (Comment 5). Could you confirm that?

Yes, Chinese characters in comment 5 is Hans.

Comment 11 Steve Tyler 2012-11-03 02:57:45 UTC
(In reply to comment #10)
> (In reply to comment #8)
> > OK, thanks. Maybe we will need to add an entry to mangleMap then. I don't
> > read Chinese, but it looks like the default script for zh_HK is Hans
> > (Comment 5). Could you confirm that?
> 
> Yes, Chinese characters in comment 5 is Hans.

Thanks. What are the Chinese characters in the screenshot in Comment 9?

mangleMap may need an entry like:

{ "zh_HK":  "zh_Hant_HK" }

The name "zh_Hant_HK" comes from here:
$ rpm -ql python-babel | grep localedata | grep zh

Babel parses "zh_Hant_HK" this way:

>>> import babel
>>> babel.Locale.parse('zh_Hant_HK').__dict__
{'_Locale__data': None, 'territory': 'HK', 'variant': None, 'language': 'zh', 'script': 'Hant'}

Comment 12 Cheng-Chia Tseng 2012-11-03 03:08:31 UTC
(In reply to comment #11)
> 
> Thanks. What are the Chinese characters in the screenshot in Comment 9?

It's Hant (Traditional Chinese). As I said, most Hong Kong people use Hant. :)

> 
> mangleMap may need an entry like:
> 
> { "zh_HK":  "zh_Hant_HK" }
> 
> The name "zh_Hant_HK" comes from here:
> $ rpm -ql python-babel | grep localedata | grep zh
> 
> Babel parses "zh_Hant_HK" this way:
> 
> >>> import babel
> >>> babel.Locale.parse('zh_Hant_HK').__dict__
> {'_Locale__data': None, 'territory': 'HK', 'variant': None, 'language':
> 'zh', 'script': 'Hant'}

Comment 13 Steve Tyler 2012-11-03 03:18:24 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > 
> > Thanks. What are the Chinese characters in the screenshot in Comment 9?
> 
> It's Hant (Traditional Chinese). As I said, most Hong Kong people use Hant.
> :)

Thanks. There is only one 'zh_HK' locale file, so it was important to confirm that when 'zh_HK' is configured, the desktop displays Hant:

$ ls -1 /usr/share/i18n/locales/zh*
/usr/share/i18n/locales/zh_CN
/usr/share/i18n/locales/zh_HK
/usr/share/i18n/locales/zh_SG
/usr/share/i18n/locales/zh_TW

Comment 14 Cheng-Chia Tseng 2012-11-03 03:21:15 UTC
Thank you for doing this for zh_HK! I am appreciate.

Comment 15 Cheng-Chia Tseng 2012-11-03 08:42:24 UTC
I am still waiting to be approved to be a member of Chinese (Hong Kong) team on Transifex. I will upload the translation by that time.

Comment 16 Steve Tyler 2012-11-04 22:45:17 UTC
Transifex is showing 98% translation coverage for zh_HK in Anaconda → Master:

Fedora Project  /  Chinese (Hong Kong) zh_HK
Anaconda
https://fedora.transifex.com/projects/p/fedora/language/zh_HK/?project=2059

Comment 17 Steve Tyler 2012-11-05 06:56:50 UTC
Created attachment 638346 [details]
screenshot showing four Chinese language choices in installer language menu

This screenshot shows the installer language menu with four Chinese language choices. Each specifies a script -- Hans or Hant. If there is no translation, installation is in English, but the i18n locale should be correct for each.[1]

These are the corresponding Babel locales:
>>> print babel.Locale.parse('zh_Hans_CN').english_name
Chinese (Simplified Han, China)
>>> print babel.Locale.parse('zh_Hant_HK').english_name
Chinese (Traditional Han, Hong Kong SAR China)
>>> print babel.Locale.parse('zh_Hans_SG').english_name
Chinese (Simplified Han, Singapore)
>>> print babel.Locale.parse('zh_Hant_TW').english_name
Chinese (Traditional Han, Taiwan)

[1] Bug 872791 prevented me from testing all four.

Comment 18 Steve Tyler 2012-11-05 07:14:01 UTC
Created attachment 638347 [details]
demo patch to list four Chinese language choices in the installer language menu

Patch is against anaconda-18.24-1.

Tested with:
$ qemu-kvm -m 4096 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Beta/TC7/Fedora-18-Beta-TC7-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on -usbdevice mouse

Comment 19 Adam Williamson 2012-11-05 07:23:39 UTC
If we aren't going to provide a translation for Singapore, we should probably not include it, as discussed on the other bug. Singaporean users are probably better off with using 'China' as their location and getting a translation, than using 'Singapore' as their location and getting no translation!

Comment 20 Cheng-Chia Tseng 2012-11-05 11:54:53 UTC
(In reply to comment #19)
> If we aren't going to provide a translation for Singapore, we should
> probably not include it, as discussed on the other bug. Singaporean users
> are probably better off with using 'China' as their location and getting a
> translation, than using 'Singapore' as their location and getting no
> translation!

I agree with Adam.

zh_SG is rarely used even in singapore. They mostly use zh_CN instead.

Comment 21 Steve Tyler 2012-11-05 14:09:36 UTC
Thanks for your comments. After a test install with zh_SG, the only Chinese characters that I could find on the Gnome desktop were in the date in the calendar. Transifex doesn't have zh_SG at all:
https://fedora.transifex.com/projects/p/fedora/language/zh_SG/

So we definitely don't want to include zh_SG in the language menu.

The strings all come from Babel. Are any problems with them apparent in the screenshot?
Attachment 638346 [details]

Comment 22 Cheng-Chia Tseng 2012-11-05 16:12:43 UTC
It looks good and correct.

Frankly, Traditional Chinese has been called "正體中文" instead of "繁體中文" officially in Taiwan since the president Ma Ying-jeou thought that "繁" character in Chinese also expresses "complicated" and "a huge amount of" while "正" character delivers "traditional" and "rightful".

However, this issue is not widely recognized by Chinese out of Taiwan and those organizations which defines the standards. If the naming of Traditional Chinese is not defined in Anaconda, let's forget about it. I think "繁體中文" is still be recognized by Chinese users in Taiwan.

Comment 23 Adam Williamson 2012-11-05 18:18:21 UTC
we're kind of getting out of spec here, but i'm thinking there must be some sort of mechanism for handling closely-related translations. zh_HK/zh_TW and zh_CN/zh_SG aren't the only cases, after all. it's already been pointed out that 'translations' for all the English locales are going to be very similar, and I'm sure there are other cases. so it makes me feel like someone somewhere must know a 'good' way for handling this, maybe you can mark a locale as using translations from another locale when there are no translations for that locale? so zh_SG would fall back on the zh_CN translation for any string which didn't have a zh_SG translation? anyway, like i said, we're broadening out a long way there.

Comment 24 Cheng-Chia Tseng 2012-11-06 01:58:16 UTC
A Hong Kong user said that there was a locale fallback mechanism supported by ubuntu. It is something like:

LANGUAGE variable
zh_HK:zh_TW:en_US:en
zh_SG:zh_CN:en_US;en

I do a search in the bugzilla, and find this report [1] which is related but not resolved.

1. https://bugzilla.redhat.com/show_bug.cgi?id=624158

Comment 25 Steve Tyler 2012-11-06 14:57:45 UTC
(In reply to comment #22)
> It looks good and correct.
> 
> Frankly, Traditional Chinese has been called "正體中文" instead of "繁體中文"
> officially in Taiwan since the president Ma Ying-jeou thought that "繁"
> character in Chinese also expresses "complicated" and "a huge amount of"
> while "正" character delivers "traditional" and "rightful".
> 
> However, this issue is not widely recognized by Chinese out of Taiwan and
> those organizations which defines the standards. If the naming of
> Traditional Chinese is not defined in Anaconda, let's forget about it. I
> think "繁體中文" is still be recognized by Chinese users in Taiwan.

Thanks for your comments. The string for the name of Traditional Chinese from Babel comes from the CLDR. These pages have more about the CLDR "process for data collection, resolution, public feedback and release":

CLDR Process
http://cldr.unicode.org/index/process

CLDR Change Requests
http://cldr.unicode.org/index/bug-reports

The string for the name of Traditional Chinese from Babel, "繁體中文", can be found here:

$ rpm -ql python-babel | grep localedata | grep zh | xargs grep "繁體中文"
Binary file /usr/lib/python2.7/site-packages/babel/localedata/zh_Hant.dat matches

The CLDR has "繁體中文" here:

Locale Data Summary for zh_Hant [Traditional Chinese]
http://www.unicode.org/cldr/charts/summary/zh_Hant.html

The latest version of the CLDR can be downloaded here:

CLDR Releases/Downloads
http://cldr.unicode.org/index/downloads/
(core.zip has the CLDR in XML format.)

Comment 26 Cheng-Chia Tseng 2012-11-06 16:34:01 UTC
(In reply to comment #25)
> (In reply to comment #22)
> > It looks good and correct.
> > 
> > Frankly, Traditional Chinese has been called "正體中文" instead of "繁體中文"
> > officially in Taiwan since the president Ma Ying-jeou thought that "繁"
> > character in Chinese also expresses "complicated" and "a huge amount of"
> > while "正" character delivers "traditional" and "rightful".
> > 
> > However, this issue is not widely recognized by Chinese out of Taiwan and
> > those organizations which defines the standards. If the naming of
> > Traditional Chinese is not defined in Anaconda, let's forget about it. I
> > think "繁體中文" is still be recognized by Chinese users in Taiwan.
> 
> Thanks for your comments. The string for the name of Traditional Chinese
> from Babel comes from the CLDR. These pages have more about the CLDR
> "process for data collection, resolution, public feedback and release":
> 
> CLDR Process
> http://cldr.unicode.org/index/process
> 
> CLDR Change Requests
> http://cldr.unicode.org/index/bug-reports

Thanks, I have filed another report there about that. 

> 
> The string for the name of Traditional Chinese from Babel, "繁體中文", can be
> found here:
> 
> $ rpm -ql python-babel | grep localedata | grep zh | xargs grep "繁體中文"
> Binary file /usr/lib/python2.7/site-packages/babel/localedata/zh_Hant.dat
> matches
> 
> The CLDR has "繁體中文" here:
> 
> Locale Data Summary for zh_Hant [Traditional Chinese]
> http://www.unicode.org/cldr/charts/summary/zh_Hant.html
> 
> The latest version of the CLDR can be downloaded here:
> 
> CLDR Releases/Downloads
> http://cldr.unicode.org/index/downloads/
> (core.zip has the CLDR in XML format.)

Comment 27 Abel Cheung 2012-11-06 16:44:21 UTC
(In reply to comment #24)
> zh_HK:zh_TW:en_US:en
> zh_SG:zh_CN:en_US;en

Actually the following setting should be sufficient:
zh_HK -> LANGUAGE=zh_HK:zh_TW
zh_SG -> LANGUAGE=zh_SG:zh_CN

When neither zh_HK nor zh_TW translations were present, it would automatically fallback to source code strings, which means English for virtually all software.

Although non-GNU software may not honor $LANGUAGE, it's another story then. At least GNOME desktop and more visible software on Fedora supports it.

Comment 28 Steve Tyler 2012-11-06 18:47:42 UTC
(In reply to comment #26)
...
> > CLDR Change Requests
> > http://cldr.unicode.org/index/bug-reports
> 
> Thanks, I have filed another report there about that. 

Thanks:

繁體 is now officially called as 正體 in Taiwan
http://unicode.org/cldr/trac/ticket/5433

Comment 29 Adam Williamson 2012-11-08 04:27:45 UTC
Maybe we should file a new bug for the fallback mechanism thing.

Comment 30 Cheng-Chia Tseng 2012-11-08 11:25:57 UTC
(In reply to comment #29)
> Maybe we should file a new bug for the fallback mechanism thing.

What about bug 624158?

It seems to be something alike. Sorry that I don't know much about the technical details. :P

Comment 31 Fedora End Of Life 2013-12-21 09:15:41 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 32 Fedora End Of Life 2014-02-05 12:48:50 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.