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.).
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.
I'll CC the guy who was going to script the conversion of the TW translation.
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
Note to self: not just as easy as po/LINGUAS. May also need to be added to mangleMap.
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 中文 (中国香港特别行政区)
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 中文 (繁體中文, 中華人民共和國香港特別行政區)
Hong Kong people uses Hant (Traditional Chinese) mostly.
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?
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.
(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.
(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'}
(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'}
(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
Thank you for doing this for zh_HK! I am appreciate.
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.
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
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.
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
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!
(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.
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]
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.
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.
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
(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.)
(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.)
(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.
(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
Maybe we should file a new bug for the fallback mechanism thing.
(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
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.
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.