[FFe] Install Fcitx for Chinese users

Please consider https://launchpad.net/bugs/1431337 when working with this bug.

Status changed to 'Confirmed' because the bug affects multiple users.

Japanese users prefer to use Fcitx, too.
By the way, please stop to add fcitx-ui-qimpanel or consider to use language-selector.
fcitx-ui-qimpanel makes Chinese menu by force on Japanese environment.

@Ikuya, you might want to talk to people on #ubuntu-desktop (alternatively discuss on ubuntu-desktop@l.u.c) about the preference of Japanese users, and we can work this out if there's an agreement.

For the menu stuff I'll open another report and get translations set up as soon as possible for fcitx-ui-qimpanel, it's written using Qt5 so it will work with Unity8 flawlessly.

im-config in Ubuntu is able to set preferred "auto" IM (which is default) by locale, it's implemented as described in Debian bug 780373[1]. Another patch that makes fcitx default for Chinese locales is prepared in the package, and can be enabled by adding it to debian/patches/series.

[1]http://bugs.debian.org/780373

Status changed to 'Confirmed' because the bug affects multiple users.

I have a couple of thoughts on the proposed im-config changes.

Shouldn't the new .conf file reside in /etc rather than /usr/share, or else possible user settings would be overwritten when the im-config package is updated?

Maybe theoretical, but: If LC_CTYPE is set explicitly, its value is not surrounded by quotes in the locale output.

I suppose the intention is to include a few Chinese (and maybe Japanese) entries in the Ubuntu version of the .conf file. But in that case, shouldn't the code in debian/rules be changed back to have ibus as default? Otherwise you'd make fcitx the default for everyone.

@gunnarhj,

1. I have proposed that on Debian BTS, but I don't want to make another conffile before reaching an agreement with Osamu. And it won't override user settings in any case, those part will only take effect when the selected IM is "auto".

2. Yes, should deal with no quotes in locale output, I'll update on that.

3. Yes, but I reverted the code removal because this FFe hasn't been approved (yet), making that change will led to some people's IM changes back to ibus on upgrade.

Hi Aron!

On 2015-03-13 10:54, Aron Xu wrote:
> 1. I have proposed that on Debian BTS, but I don't want to make
> another conffile before reaching an agreement with Osamu. And it
> won't override user settings in any case, those part will only take
> effect when the selected IM is "auto".

Right, but I didn't mean user settings via ~/.xinputrc. I got the impression that you were about to make it possible for a sysadmin to edit the new .conf file manually. Maybe I misunderstood.

> 3. Yes, but I reverted the code removal because this FFe hasn't been
> approved (yet), making that change will led to some people's IM
> changes back to ibus on upgrade.

It's worth mentioning that the first time a user opens Language Support, it sets the IM framework explicitly by creating ~/.xinputrc based on auto at the time, even if the user does not touch the IM setting.

On Fri, Mar 13, 2015 at 6:27 PM, Gunnar Hjalmarsson <
<email address hidden>> wrote:

> Hi Aron!
>
> On 2015-03-13 10:54, Aron Xu wrote:
> > 1. I have proposed that on Debian BTS, but I don't want to make
> > another conffile before reaching an agreement with Osamu. And it
> > won't override user settings in any case, those part will only take
> > effect when the selected IM is "auto".
>
> Right, but I didn't mean user settings via ~/.xinputrc. I got the
> impression that you were about to make it possible for a sysadmin to
> edit the new .conf file manually. Maybe I misunderstood.
>
>
Understood, in the new patch I renamed the file, to get rid of .conf
suffix. If Osamu agrees to make it system admin configurable it's easy to
change the path.

> > 3. Yes, but I reverted the code removal because this FFe hasn't been
>

> > approved (yet), making that change will led to some people's IM
> > changes back to ibus on upgrade.
>
> It's worth mentioning that the first time a user opens Language Support,
> it sets the IM framework explicitly by creating ~/.xinputrc based on
> auto at the time, even if the user does not touch the IM setting.
>

I suppose ~/.xinputrc should not be created if the user does not touch IM
settings.

On 2015-03-13 11:47, Aron Xu wrote:
> On Fri, Mar 13, 2015 at 6:27 PM, Gunnar Hjalmarsson
> <email address hidden> wrote:
>> It's worth mentioning that the first time a user opens Language
>> Support, it sets the IM framework explicitly by creating
>> ~/.xinputrc based on auto at the time, even if the user does not
>> touch the IM setting.
>
> I suppose ~/.xinputrc should not be created if the user does not
> touch IM settings.

Well, it is intentional.

Up to know the default (auto) has been determined by which IM framework(s) are installed. Take a multiuser system with only IBus installed. The purpose of the automatic creation of ~/.xinputrc is to prevent a surprise change for all users if a sysadmin installs e.g. fcitx. I assume it's preferable that the IM framework is only changed if the user requests so by changing the setting.

I think this reasoning is even more important now when auto may be determined by the locale. We don't want the IM framework be changed just because a user changes the display language, do we?

This is the language-selector code:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/language-selector/vivid/view/head:/LanguageSelector/ImConfig.py

> Maybe theoretical, but: If LC_CTYPE is set explicitly, its value is not surrounded by quotes in the locale output.

I actually hit this issue and opened an separate bug as LP: #1431862. If you guys intend to fix it in a series of this bug, please mark it as a duplicate.

On 2015-03-12 18:59, Aron Xu wrote:
> On 2015-03-12 17:00, Ikuya Awashiro wrote:
>> Japanese users prefer to use Fcitx, too.
>
> @Ikuya, you might want to talk to people on #ubuntu-desktop
> (alternatively discuss on ubuntu-desktop@l.u.c) about the preference
> of Japanese users, and we can work this out if there's an agreement.

@Aron: Please note that there is a Japanese remix with fcitx as default.
https://bugs.launchpad.net/indicator-keyboard/+bug/1363150/comments/8

So considering that debian/rules in im-config is about to be changed in 15.04, Ikuya's request has to be dealt with instantly. (Not much time for discussion.) The above speaks for adding a "ja_JP fcitx" entry to locale_prefs.

@Nobuto: Do you have any input on this?

On Sat, Mar 14, 2015 at 1:41 AM, Gunnar Hjalmarsson <
<email address hidden>> wrote:

> On 2015-03-12 18:59, Aron Xu wrote:
> > On 2015-03-12 17:00, Ikuya Awashiro wrote:
> >> Japanese users prefer to use Fcitx, too.
> >
> > @Ikuya, you might want to talk to people on #ubuntu-desktop
> > (alternatively discuss on ubuntu-desktop@l.u.c) about the preference
> > of Japanese users, and we can work this out if there's an agreement.
>
> @Aron: Please note that there is a Japanese remix with fcitx as default.
> https://bugs.launchpad.net/indicator-keyboard/+bug/1363150/comments/8
>
> So considering that debian/rules in im-config is about to be changed in
> 15.04, Ikuya's request has to be dealt with instantly. (Not much time
> for discussion.) The above speaks for adding a "ja_JP fcitx" entry to
> locale_prefs.
>
> @Nobuto: Do you have any input on this?
>
>
I don't have any objections on making fcitx default for Japanese users, it
should be up to their choice. Motivation behind this FFe is giving fcitx a
try in a wider range of audience before we can decide whether Ubuntu shall
switch to use it as default, and desktop team agreed on doing that for
Chinese users first.

So if @nobuto can tell that using fcitx as default is desired for Japanese
users, let's talk with other people on desktop team next week (preferably
on IRC). Even this makes me think about whether it's desirable for Korean
users, but if no one speak up let's leave it as is.

As regards Korean, and considering bug #1412036, I suspect that Korean users wish some change: Either the bug fixed or switch to fcitx.

> So if @nobuto can tell that using fcitx as default is desired for Japanese
users, let's talk with other people on desktop team next week (preferably
on IRC).

Well, fcitx-anthy(LP: #1356222) and fcitx-mozc are still in universe. No Japanese engine for fcitx to seed is available yet.

@ikuya, can you point out severe issues with ibus which justify to hurry migration in this cycle?

In my opinion the plan in this FFe description below sounds realistic to me.
> this FFe is a proposal to make Fcitx the default for Chinese locales this cycle, as a transition towards making Fcitx the default for all users next cycle.

@Nobuto: The fact that there is a Japanese remix with fcitx as default means that some Japanese users will be affected by the proposed 15.04 changes whether we like it or not.

Up to now, you have been able to decide the default IM framework per distro by having fcitx installed by default or not. fcitx has been installed by default in Ubuntu Kylin, and hence fcitx has automatically been the default IM framework. According to Ikuya the same is true for a Japanese remix.

As from 15.04 fcitx will be installed by default for all users, and thus it will no longer be possible to determine the default IM framework per distro in the same way.

I have no idea how many Japanese users install the Japanese remix and how many install standard Ubuntu, though.

On Mon, Mar 16, 2015 at 1:02 AM, Nobuto Murata <email address hidden>
wrote:

> > So if @nobuto can tell that using fcitx as default is desired for
> Japanese
> users, let's talk with other people on desktop team next week (preferably
> on IRC).
>
> Well, fcitx-anthy(LP: #1356222) and fcitx-mozc are still in universe. No
> Japanese engine for fcitx to seed is available yet.
>
>
fcitx-anthy's MIR is approved, it's still in universe because nothing in
main uses it at the moment (dependency or seed). If we decide to use it,
seeding will work.

What is the current proposed change? I don't think it's to seed fcitx* onto desktop as the merge proposal attached here is doing. Is it to add to pkg_depends in language-selector as in bug #1431337?

We just discussed this on #ubuntu-desktop - I think this is the plan

 - Add fcitx & friends to 'live' seed (dropping ibus-pinyin & others at the same time), so that it's installed in the live session (it needs to be started up before the session starts) but not in the target by default.
 - Add it to pkg_depends of language-selector (per #1431337), so that check-language-support -l zh_CN returns fcitx packages.
   + This will cause the installer to keep fcitx only when the selected language is Chinese, and remove it otherwise.
   + In installed systems, language-selector will prompt to install fcitx.
 - If necessary (not sure if it is), fix language-selector to select fcitx as IM for Chinese when there is no pre-existing configuration.
   + We don't try to change .xinputrc for existing users.

To test this effectively, we have to do the seed change - the rest can be done locally.

Not acking the FFe yet, but please (temporarily for now) go ahead with the above seed change.

Attached is a patch for language-selector (pkg_depends), so that check-language-support would return fcitx and related packages for all Chinese locales (zh_*).

The debdiff for setting fcitx as per locale default of zh_*, while restoring ibus as default for everyone else.

Gunnar, the FFe for this wasn't approved so language-selector shouldn't have been uploaded. We wanted to verify that the approach is sensible first.

Seems that it luckily is, so retrospectively granted, but please be aware in future.

The meta package itself is not related to pull in fcitx packages, but as ibus-pinyin is removed from desktop-recommends (in 1.333), mark as Fix Released.

Changes for im-config acked at #ubuntu-desktop.

On 2015-03-19 10:42, Iain Lane wrote:
> Gunnar, the FFe for this wasn't approved so language-selector
> shouldn't have been uploaded.

Sorry Iain, forgot that.

All changes have land in vivid, and the daily-live of March 20th contains all these changes.

@Ikuya, translations of qimpanel are made available on Launchpad yesterday, and it will be shipped on vivid's language pack update next week. The indicator menu items and default theme are still improving, please tell me what you think if you have time to give it a try.

As for the Japanese remix that uses Fcitx, I would recommend you to work out a decision on what to do with Japanese locales, and if it's fcitx, we can implement in the same way for Chinese (l-s pkg_depends + im-config locale_prefs). Fcitx is not preferred over ibus on non-zh locales anymore in vivid (we might do that again in vivid+1 if the transition is OK), otherwise live session users will always have fcitx enabled, that's not expected to happen in this cycle.

@Aron, I've finished to translate fcitx-qimpanel and test it in a short time.
fcitx-qimpanel does not suit on Japanese environment, I think.
Because it does not have status panel. Japanese IM like Anthy or/and Mozc have own IM status, e.g. direct input, Hiragana mode, and so on. And users can not recognize their status without status panel or click on indicator icon.
Also I cannot test it on Virtualbox VM due to an OpenGL issue. Is it another issue?

I will write a mail to ubuntu-desktop@l.u.c. It is hard for me to talk on IRC.

@Ikuya, thanks for the translations, and good to know your opinion.

About the status bar, I would recommend to consider dropping it as in OS X (verified default Japanese input method in it just now).

It's a long history that all Pinyin (the most popular way of inputing Simplified Chinese) engines have their own status bar, indicating some status information and let people be able to switch/toggle them by clicking on it. But in recent years its fading out, and on OS X they removed status bar for all languages altogether, not mentioning many Chinese input method vendors are discovering the possibility of halving the size of candidate box by making use of pre-edit extensively.

This is also true for most (if not all) languages in GNOME and KDE when we using their native implementations of input method UI (gjs-implemented UI, kimpanel plasma widget). So Unity desktop could be the last major one on Linux that's still displaying status bar, and it's a good chance of changing it at the same time of switching default input method framework.

@Aron
I send a mail to ubuntu-desktop@l.u.c.

I understand your opinion. You are correct. Status bar is outdated.
I don't know about OS X, but GNOME Shell shows IM status instead of IM icon. Please see attached screenshot.
If fcitx-qimpanel implemented the same look, Japanese users will be happy.
(Of course I don't like this style, I hope to show the status bar at right bottom on the Desktop. Yes, I know this is old-fashioned opinion.)

Fcitx is much better than Ibus. This is a good move.

However, fcitx-m17n is not working. IBus-m17n works as expected.

@Ikuya, I didn't see your message at ubuntu-desktop@, can you check?

@Ping-Wu, please help report your problem to Launchpad or fcitx upstream, thanks!

@Aron, I received a awaiting moderator approval mail.
I don't know what to do.

@Ikuya, you need to subscribe before posting to that list.

I was so stupid I send from an wrong mail address...
I am very sorry for bothering you.

Hi,

I just tested Vivid Beta2 for zh_TW locale. Here are some inputs:

1. After fresh installation, there is no traditional Chinese input method installed by default. However, we expect to have fcitx-chewing installed after the installation process by default.

It is not that intuitive for users to check themselves or wait for the prompt from Language Support which many users will just Skip/Neglect it.

2. Language Support will install fcitx-chewing for zh_TW locale which is great. However, the system does not prompt to re-login and nothing happens after the installation. You cannot see fcitix-chewing activated until you re-login. I believe many users might not figure out why they still don't get input methods ready after the installation.

Should I file bug reports for these issues? Or they should be treated as part of this bug report?

@Cheng-Chia Tseng: fcitx-chewing seems not to be in main yet, which I suspect might explain it.

According to bug #1356222 fcitx-chewing has been approved for main. Since it didn't end up in the desktop seed, as initially proposed, a developer may need to move it to main manually.