https://bugzilla.redhat.com/show_bug.cgi?id=834971
Bug ID: 834971 QA Contact: extras-qa@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: i18n-bugs@lists.fedoraproject.org, jni@redhat.com, me@kaio.net, shawn.p.huang@gmail.com Assignee: jni@redhat.com Summary: ibus-table key input limitation makes it hard to input Traditional Chinese with Quick and Cangjie Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: petersen@redhat.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: ibus-table Product: Fedora
This was originally brought up by Mathieu Bridon and other Hong Kong Fedora users. The text below is adopted from his mail.
Here's a proposal to fix IBus Table for Hong Kong users.
Both Cangjie and Quick can be used to type Simplified and Traditional Chinese, however, given their design, there isn't any combination of keys that would conflict between those languages. In other words, any given combination of character can only lead to results in one of those languages, never more than one.
Given all that, it would make sense to simply remove altogether the IBus filter for the Cangjie and Quick input methods in IBus.
Let's take an example.
In Cangjie, the combination "rji" can only return results in Traditional Chinese. That means if a user types this combination of keys, he is expecting results in Traditional Chinese because that's the language he/she wants to type.
But with the current IBus filter, if the filter is set to only let Simplified Chinese characters pass, he/she would not get any results.
In the same way, the combination "yri" can only return results in Simplified Chinese, and the combination "fji" can only return results in Japanese.
[ed: I have never heard of people using ibus-table for Japanese input]
This is by design of those two input methods: they were designed to avoid conflicts.
As such, the filter just makes no sense for Cangjie and Quick, and it should be simply removed for those two input methods.
Now, in the above I claimed that Cangjie and Quick were designed to have absolutely zero conflicts, which was a little exaggeration.
In reality, conflicts happen. However, Cangjie and Quick were really designed with the goal of minimizing conflicts, and they do it so well that the actual rate of conflicts is 8.04% [1]. This is such a small number, and it happens in so rare occasions, that it can just be ignored.
It is also important to note that if 90% of Hong Kong people [2] use Cangjie and Quick, many people (but much less than in HK) use them in Taiwan, and almost no one use them in Mainland China or in Japan.
Out of those three, Hong Kong and Taiwan write Traditional Chinese, Mainland Chinese write Simplified Chinese, and Japanese obviously write Japanese. So those two input methods really are used almost exclusively to write Traditional Chinese, which makes the aforementioned 8.04% figure completely negligible.
As such, it doesn't change the argument at all: the current IBus filter should be removed for the Cangjie and Quick input methods.
This is an absolute show-stopper for Hong Kong users at the moment (well, not me, I can't write Chinese , and the simple act of removing this filter for those two input methods would basically fix 90% of the problems for 90% of the Hong Kong people.
Do you think you guys could fix this issue before the release of GNOME 3.6?
Of course, we'd be happy to provide a patch if you agree on the solution and if you can provide some guidance.
[1] There's a scientific paper published on this, but it's unfortunately only available in Chinese: http://zh.wikipedia.org/wiki/%E5%80%89%E9%A0%A1%E8%BC%B8%E5%85%A5%E6%B3%95
[2] Not just Linux users, actual **people**, as this is how everyone learns to type at school in Hong Kong.