Install Fcitx for Japanese users
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | im-config (Ubuntu) |
High
|
Aron Xu | ||
| | language-selector (Ubuntu) |
High
|
Gunnar Hjalmarsson | ||
Bug Description
According to my proposal [1], Fcitx should be default for Japanese uses on Vivid release cycle.
https:/
Ref: https:/
Related branches
| Iain Lane (laney) wrote : | #4 |
| Gunnar Hjalmarsson (gunnarhj) wrote : | #5 |
@Iain: Otherwise there would in effect be a regression with respect to the Japanese remix. It has been shipped with fcitix as the default IM framework, making use of the old im-config behavior. The new im-config behavior, which is locale based, breaks that.
On Wed, Apr 01, 2015 at 08:35:53AM -0000, Gunnar Hjalmarsson wrote:
> @Iain: Otherwise there would in effect be a regression with respect to
> the Japanese remix. It has been shipped with fcitix as the default IM
> framework, making use of the old im-config behavior. The new im-config
> behavior, which is locale based, breaks that.
Presumably the remix can do whatever it wants. This bug is asking to
make the change for *all* Ubuntu users. I think it's quite late in the
cycle to do that.
--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]
On 2015-04-01 13:22, Iain Lane wrote:
> Presumably the remix can do whatever it wants.
Leaving to Ikuya to comment on that.
> This bug is asking to make the change for *all* Ubuntu users. I think
> it's quite late in the cycle to do that.
Basically the change would only affect new users, just as with Chinese. But you know better than me if it's *too* late.
1. Most of Japanese users already use Fcitx because of using our remix.
2. Some Ubuntu flavors does not depend on IBus. Users should install IBus or Fcitx individually.
So, these changes are huge benefits and low risk, I think.
| Iain Lane (laney) wrote : | #9 |
It's too late for main Ubuntu. For vivid you can continue to do changes in the remix and we can switch to fcitx at the start of the 15.10 cycle, so we have time to shake out any bugs/complaints.
Thanks, and sorry for the inconvenience.
| Changed in language-selector (Ubuntu): | |
| milestone: | none → later |
| Changed in im-config (Ubuntu): | |
| milestone: | none → later |
The attachment "language-
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]
| tags: | added: patch |
| Changed in language-selector (Ubuntu): | |
| assignee: | nobody → Gunnar Hjalmarsson (gunnarhj) |
| importance: | Undecided → High |
| milestone: | later → none |
| status: | New → Fix Committed |
| Changed in im-config (Ubuntu): | |
| importance: | Undecided → High |
| milestone: | later → none |
| status: | New → Triaged |
| Launchpad Janitor (janitor) wrote : | #11 |
This bug was fixed in the package language-selector - 0.144
---------------
language-selector (0.144) wily; urgency=medium
* data/pkg_depends:
Pull fcitx (the framework) for Japanese.
[ Ikuya Awashiro ]
* data/pkg_depends:
If a Japanese language is installed (or about to be installed),
pull the applicable Japanese fcitx IM engines (LP: #1439006).
-- Gunnar Hjalmarsson <email address hidden> Thu, 07 May 2015 20:00:00 +0200
| Changed in language-selector (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| Changed in im-config (Ubuntu): | |
| status: | Triaged → Fix Committed |
| assignee: | nobody → Aron Xu (happyaron) |
| Launchpad Janitor (janitor) wrote : | #12 |
This bug was fixed in the package im-config - 0.29-1ubuntu3
---------------
im-config (0.29-1ubuntu3) wily; urgency=medium
* Set fcitx to system-wide default for ja_JP (LP: #1439006).
-- Aron Xu <email address hidden> Sat, 09 May 2015 07:02:27 +0800
| Changed in im-config (Ubuntu): | |
| status: | Fix Committed → Fix Released |
| summary: |
- [FFe] Install Fcitx for Japanese users + Install Fcitx for Japanese users |
| Aron Xu (happyaron) wrote : | #13 |
@ikuya, I have a question when revisiting this bug, that is how do you evaluate the possibility of using mozc engine as default, rather than anthy? I'm not a user of either because I don't type in Japanese, but there's quite a few hints that show mozc is much more advanced than the aged anthy.
| Nobuto Murata (nobuto) wrote : | #14 |
@Aron,
I'm not sure about the future including Desktop Next or convergence, however I believe it's still worthy to have Mozc as default for the time being. The engine itself is well maintained by Google team as Mozc/Google Japanese Input(It's like a Chromium/Chrome relation) in upstream, and popular on Windows, Linux and Android with no doubt.
Up until now, we didn't bring Mozc to MIR because it has a wide dependencies. Now that fcitx is in main, a big remaining depedency is "gyp". It would be great if Desktop team is positive to maintain it.
@Ikuya, your input is more than welcome.
@aron, yes, it is true that Mozc conversion engine is the *best* for Japanese input.
I always use Mozc instead of Anthy.
Mozc is default conversion engine on Ubuntu Japanese Remix which is our team is released.
Anthy is stopped to develop for a long time.
But I think it is hard to pass MIR because Mozc has a lot of dependency.
http://
So I think libkkc is *better* than Anthy and it is not difficult to pass MIR rather than Mozc.
http://
fcitx-kkc is now in menters.debian.net as you know.
https:/
Thanks,
| Aron Xu (happyaron) wrote : | #16 |
Personally I don't think gyp would cause a lot trouble and the main problem would be the dependency to framework libraries. Would it be possible to split the package into two sources or something like that so we are able build only ibus/fcitx support from a source that's OK to MIR? I don't think we want to MIR all of the frameworks.
I'll have a look at kkc soon, but if mozc is preferred we'd better to find a solution rather than applying a work around, :)
| Nobuto Murata (nobuto) wrote : | #17 |
> Personally I don't think gyp would cause a lot trouble and the main problem would be the dependency to framework libraries. Would it be possible to split the package into two sources or something like that so we are able build only ibus/fcitx support from a source that's OK to MIR? I don't think we want to MIR all of the frameworks.
Just dropping uim support in Ubuntu by dropping d/p/uim-mozc.patch and build-depends:
[1] http://


What makes you think this is the right thing to do so close to the release?