On 11.05.2012 11:05, Marguerite Su wrote:

oh I learn another smart tip. so do you mean,

1 ask coolo to add those IMs into ISO. 2 add Provides: locale(XXX) strings to them

Just for the record: step 2 obsoletes step 1, the DVD will pick (unless manually blocked) all locale provides for the supported locales. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

At Fri, 11 May 2012 17:05:49 +0800, Marguerite Su wrote:

On Fri, May 11, 2012 at 4:45 PM, Takashi Iwai wrote:

...

At Fri, 11 May 2012 16:09:08 +0800, Marguerite Su wrote:

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

       Me myself: fcitx, hime. zh_CN

       hillwood: fcitx zh_CN

       swyear: fcitx, ibus, gcin zh_TW

       tiwai: mozc, scim jp

       ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

      scim/ibus: they're the Chinese input methods in the old days.

      fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

      mozc: it's popular IM in Japan.

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

You don't need to uninstall the old IMs at all.  It's just a missing installation of the new IMs.  See below.

...

so I made a survey: https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

The biggest problem regarding mozc is that its development is closed. They accept no patch.  Thus some people don't want to take mozc as the default input method.  And, if we want other than mozc for Japanese, fcitx would be no option because it doesn't provide any other clients.

Hi, Takashi,

can you explain a little bit more about the "And..." sentence? I'm confused...

do you want to say, if mozc is the default for J, then fcitx will be uninstalled automatically?

No, I wrote "other than mozc". That is, mozc won't be the default IM for Japanese unless they change the development attitude. Sorry for unclearness. And I never wrote to "uninstall". As mentioned, the uninstallation isn't necessary at all. All what we need for fcitx is the adjustment of IM priority and the lack of automatic installation of fcitx.

but mozc now has fcitx patch and does not depend on fcitx. it can be run solely. so why not Japanese need fcitx package installed?

...

That being said, unfortuantely there is no single choice to satisfy the demands for all languages.

But, this is no big issue in practice.  Adjusting which IM to use as default is basically an easy task on openSUSE.

We have a priority list of IMs for each locale: see /etc/X11/xim.d/*. Adjust the priority of fcitx, gcin and others appropriately for your locale.  The priority symlinks are included in each package.

Then, modify the pattern list.  Put fcitx or whatever there.  But, also note that the packages including "Provides: locale(xxx)" are automatically selected when you choose the locale during the installation.  This is missing in fcitx, for example.  If it were, this package should have been automatically installed.

Basically that's all.  Of course, we can remove scim from the pattern, for example.  But this will be installed automatically via "Provides:locale()" mechanism, so it doesn't matter so much.

oh I learn another smart tip. so do you mean,

1 ask coolo to add those IMs into ISO. 2 add Provides: locale(XXX) strings to them 3 modify their xim.d to make sure they have priority over scim/ibus. 4 then they'll be the first choice when selecting that locale.

Correct.

but I still call for drop scim from DVD.

because, eg, it's for Chinese, and now zh_CN has fcitx and zh_TW has gcin.

Right.

then who'll installed it at the fist time from DVD. ibus still have some users,

scim, really it's time to let it retire...

Yes. From DVD, we can drop now. (But the migration is really a headache in this case...) Of course, the above procedure should be tested again. I remember that 12.1 broke this at some time, and hopefully this was fixed meanwhile. If it doesn't work, it should be handled in Bugzilla.

...

I don't know of the current situation of Korean language.  Hopefully someone can follow it up...

I know we have kr locale and translations. so may be I can add their l18n team coordinator to this thread?

Yeah, that sounds good. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

At Fri, 11 May 2012 19:35:07 +0800, Marguerite Su wrote:

On Fri, May 11, 2012 at 5:16 PM, Takashi Iwai wrote:

...

At Fri, 11 May 2012 17:05:49 +0800, Marguerite Su wrote:

...

On Fri, May 11, 2012 at 4:45 PM, Takashi Iwai wrote:

...

At Fri, 11 May 2012 16:09:08 +0800, Marguerite Su wrote:

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

       Me myself: fcitx, hime. zh_CN

       hillwood: fcitx zh_CN

       swyear: fcitx, ibus, gcin zh_TW

       tiwai: mozc, scim jp

       ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

      scim/ibus: they're the Chinese input methods in the old days.

      fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

      mozc: it's popular IM in Japan.

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

You don't need to uninstall the old IMs at all.  It's just a missing installation of the new IMs.  See below.

...

so I made a survey: https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

The biggest problem regarding mozc is that its development is closed. They accept no patch.  Thus some people don't want to take mozc as the default input method.  And, if we want other than mozc for Japanese, fcitx would be no option because it doesn't provide any other clients.

Hi, Takashi,

can you explain a little bit more about the "And..." sentence? I'm confused...

do you want to say, if mozc is the default for J, then fcitx will be uninstalled automatically?

No, I wrote "other than mozc".  That is, mozc won't be the default IM for Japanese unless they change the development attitude.  Sorry for unclearness.

And I never wrote to "uninstall".  As mentioned, the uninstallation isn't necessary at all.  All what we need for fcitx is the adjustment of IM priority and the lack of automatic installation of fcitx.

thanks. I'm a little slow in mind in the afternoon, XD.

then seems to raise another question(s):

what's the input method nowadays for your locale? what will be the input method then if scim/ibus or both is dropped from DVD?

since as you said, mozc can't be (while I still wonder, it's open source, if it's strong enough and popular, does it really matter that much if they accept patches?), and as I know, you need an input method.

and fcitx developer focus his concentration on mozc, fcitx-anthy became zombie for a while. of course I can ask him to keep developing it. (indeed he's listening to our thread, as he said this morning:" I'd be happy") but now you don't have an input method available.

Right. So, for Japanese, ibus is still the requirement on DVD. And, I don't think we go for dropping ibus from DVD, at least, for 12.2. 12.1 was the first version we take ibus as default, and in the next version already not on DVD? This doesn't sound right. I'm for dropping scim from DVD. (Possibly keeping in distro for old users, but at least we can get rid of the automatic installation of scim.) However, ibus is a different question.

...

...

but mozc now has fcitx patch and does not depend on fcitx. it can be run solely. so why not Japanese need fcitx package installed?

...

That being said, unfortuantely there is no single choice to satisfy the demands for all languages.

But, this is no big issue in practice.  Adjusting which IM to use as default is basically an easy task on openSUSE.

We have a priority list of IMs for each locale: see /etc/X11/xim.d/*. Adjust the priority of fcitx, gcin and others appropriately for your locale.  The priority symlinks are included in each package.

Then, modify the pattern list.  Put fcitx or whatever there.  But, also note that the packages including "Provides: locale(xxx)" are automatically selected when you choose the locale during the installation.  This is missing in fcitx, for example.  If it were, this package should have been automatically installed.

Basically that's all.  Of course, we can remove scim from the pattern, for example.  But this will be installed automatically via "Provides:locale()" mechanism, so it doesn't matter so much.

oh I learn another smart tip. so do you mean,

1 ask coolo to add those IMs into ISO. 2 add Provides: locale(XXX) strings to them 3 modify their xim.d to make sure they have priority over scim/ibus. 4 then they'll be the first choice when selecting that locale.

Correct.

...

but I still call for drop scim from DVD.

because, eg, it's for Chinese, and now zh_CN has fcitx and zh_TW has gcin.

Right.

...

then who'll installed it at the fist time from DVD. ibus still have some users,

scim, really it's time to let it retire...

Yes.  From DVD, we can drop now. (But the migration is really a headache in this case...)

Of course, the above procedure should be tested again.  I remember that 12.1 broke this at some time, and hopefully this was fixed meanwhile.  If it doesn't work, it should be handled in Bugzilla.

...

...

I don't know of the current situation of Korean language.  Hopefully someone can follow it up...

I know we have kr locale and translations. so may be I can add their l18n team coordinator to this thread?

Yeah, that sounds good.

I'm sorry but he left no email. and his bio is in Korean which I don't know.

do we still need to drag him in, given korean is of a so little user database and fcitx-hangul is available?

if so, I'll drag Karl in, he's the l18n admin, an coordinator must have an email.

OK, thanks. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marguerite Su writes:

can you help drag Korean coordinator into this thread?

I guess both our Korean community translators are no longer active; from the 'translators' file: Korean (ko) teheo Tejun Heo xein Yunseok Choi Thus I think all we can do, is to ask on opensuse developer lists. -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 11, 2012 at 9:04 PM, Marguerite Su wrote:

On Fri, May 11, 2012 at 8:56 PM, Karl Eichwalder wrote:

...

Marguerite Su writes:

...

can you help drag Korean coordinator into this thread?

I guess both our Korean community translators are no longer active; from the 'translators' file:

Korean (ko) teheo           Tejun Heo xein            Yunseok Choi

Thus I think all we can do, is to ask on opensuse developer lists.

-- Karl Eichwalder                              SUSE LINUX Products GmbH R&D / Documentation                          Maxfeldstraße 5                                             90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

the suse.de might be inactive, but naver.com must be in use. (naver is the most popular search engine, like google.)

so I cc-ed him. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, I'm fcitx's maintainer. For gnome https://live.gnome.org/ThreePointFive/Features/IBus Actually fcitx also have xkb support, named fcitx-keyboard (which is already in M17N), and I can confidently say it's provides more feature than ibus. It provides not only keyboard layout integration but also word predication and spell-checking for keyboard layout user. Maybe not so useful for native speaker, but will benefit language learner I think. One thing need to notice, that fcitx is the only input method support kcm in KDE. And it's already works. Fcitx can also works natively under gnome-shell, with this extension help: https://extensions.gnome.org/extension/261/kimpanel/. And I'm also the maintainer of kimpanel in KDE. (kimpanel is a general dbus protocol for input method UI, works with scim/ibus (kde upstream), fcitx (fcitx upstream). One of basic idea of fcitx, is to work seamlessly under all environment. And it's really following this path. Fcitx can support UI with both KDE plasma or gnome-shell, or it's native one, without user interaction. And it can also provides systemsetting integration under KDE, and gtk2/3 configuration UI. If anyone want to put a gnome-control-center entry of fcitx or even deeper integration, it will be also easy to accomplish. This is one of the feature that no existing input method could compare with. For Japanese, I will work on anthy support in the future (helps are welcome), maybe two or three month later (Since I need to finish my graduate paper for now). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 11, 2012 at 9:43 PM, Takashi Iwai wrote:

At Fri, 11 May 2012 21:20:26 +0800, Weng Xuetian wrote:

...

On Fri, May 11, 2012 at 9:04 PM, Marguerite Su wrote:

...

On Fri, May 11, 2012 at 8:56 PM, Karl Eichwalder wrote:

...

Marguerite Su writes:

...

can you help drag Korean coordinator into this thread?

I guess both our Korean community translators are no longer active; from the 'translators' file:

Korean (ko) teheo           Tejun Heo xein            Yunseok Choi

Thus I think all we can do, is to ask on opensuse developer lists.

-- Karl Eichwalder                              SUSE LINUX Products GmbH R&D / Documentation                          Maxfeldstraße 5                                             90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

the suse.de might be inactive, but naver.com must be in use. (naver is the most popular search engine, like google.)

so I cc-ed him. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, I'm fcitx's maintainer.

For gnome https://live.gnome.org/ThreePointFive/Features/IBus

Actually fcitx also have xkb support, named fcitx-keyboard (which is already in M17N), and I can confidently say it's provides more feature than ibus. It provides not only keyboard layout integration but also word predication and spell-checking for keyboard layout user. Maybe not so useful for native speaker, but will benefit language learner I think.

There is no doubt that fcitx is the more feature-rich and actively developed project :)  The action we need now is rather to contact with GNOME devs, tell the concerns regarding the integration and provide some patch if available.  They certainly should think of the support of multiple IMs, so the earlier is better than sticking with the hard-coded ibus support in GNOME.

...

One thing need to notice, that fcitx is the only input method support kcm in KDE. And it's already works. Fcitx can also works natively under gnome-shell, with this extension help: https://extensions.gnome.org/extension/261/kimpanel/. And I'm also the maintainer of kimpanel in KDE. (kimpanel is a general dbus protocol for input method UI, works with scim/ibus (kde upstream), fcitx (fcitx upstream).

BTW, this leads me to some questions.  What is the standard start-up procedure?  Is it supposed to be started from a startup desktop file?

Currently, we start a shell script in /etc/X11/xim.d/*, but this could be in a desktop file, too.  The start-up in that place seems sometimes racy with d-bus activation, for example.  12.2 would be a good chance for cleaning up this old stuff, but we need more inputs.

nope, the kcm is for configuration, see kcm-fcitx package in M17N. it integrates its settings into user "system settings". that's the first and only IM does so now. the gnome shell extension is kimpanel. provides the input panel for fcitx in Gnome shell. startup staff is still handled by fcitx main package itself. using shell scripts in xim.d but if you switched to other ways, he'll catch up in a flash.

...

One of basic idea of fcitx, is to work seamlessly under all environment. And it's really following this path. Fcitx can support UI with both KDE plasma or gnome-shell, or it's native one, without user interaction. And it can also provides systemsetting integration under KDE, and gtk2/3 configuration UI. If anyone want to put a gnome-control-center entry of fcitx or even deeper integration, it will be also easy to accomplish.

This is one of the feature that no existing input method could compare with.

For Japanese, I will work on anthy support in the future (helps are welcome), maybe two or three month later (Since I need to finish my graduate paper for now).

That'll be great.  Anthy is no active development, but it's fairly stable and solid, thus still good to take as default, until mozc really gets accepted by all FOSS people.

If you have any test patch available, let me know.

thanks,

Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 11, 2012 at 9:58 PM, Takashi Iwai wrote:

At Fri, 11 May 2012 21:49:26 +0800, Marguerite Su wrote:

...

On Fri, May 11, 2012 at 9:43 PM, Takashi Iwai wrote:

...

At Fri, 11 May 2012 21:20:26 +0800, Weng Xuetian wrote:

...

On Fri, May 11, 2012 at 9:04 PM, Marguerite Su wrote:

...

On Fri, May 11, 2012 at 8:56 PM, Karl Eichwalder wrote:

...

Marguerite Su writes:

> can you help drag Korean coordinator into this thread?

I guess both our Korean community translators are no longer active; from the 'translators' file:

Korean (ko) teheo           Tejun Heo xein            Yunseok Choi

Thus I think all we can do, is to ask on opensuse developer lists.

-- Karl Eichwalder                              SUSE LINUX Products GmbH R&D / Documentation                          Maxfeldstraße 5                                             90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

the suse.de might be inactive, but naver.com must be in use. (naver is the most popular search engine, like google.)

so I cc-ed him. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, I'm fcitx's maintainer.

For gnome https://live.gnome.org/ThreePointFive/Features/IBus

Actually fcitx also have xkb support, named fcitx-keyboard (which is already in M17N), and I can confidently say it's provides more feature than ibus. It provides not only keyboard layout integration but also word predication and spell-checking for keyboard layout user. Maybe not so useful for native speaker, but will benefit language learner I think.

There is no doubt that fcitx is the more feature-rich and actively developed project :)  The action we need now is rather to contact with GNOME devs, tell the concerns regarding the integration and provide some patch if available.  They certainly should think of the support of multiple IMs, so the earlier is better than sticking with the hard-coded ibus support in GNOME.

...

One thing need to notice, that fcitx is the only input method support kcm in KDE. And it's already works. Fcitx can also works natively under gnome-shell, with this extension help: https://extensions.gnome.org/extension/261/kimpanel/. And I'm also the maintainer of kimpanel in KDE. (kimpanel is a general dbus protocol for input method UI, works with scim/ibus (kde upstream), fcitx (fcitx upstream).

BTW, this leads me to some questions.  What is the standard start-up procedure?  Is it supposed to be started from a startup desktop file?

Currently, we start a shell script in /etc/X11/xim.d/*, but this could be in a desktop file, too.  The start-up in that place seems sometimes racy with d-bus activation, for example.  12.2 would be a good chance for cleaning up this old stuff, but we need more inputs.

nope, the kcm is for configuration, see kcm-fcitx package in M17N.

it integrates its settings into user "system settings". that's the first and only IM does so now.

the gnome shell extension is kimpanel. provides the input panel for fcitx in Gnome shell.

startup staff is still handled by fcitx main package itself. using shell scripts in xim.d

but if you switched to other ways, he'll catch up in a flash.

OK.  As long as the shell-script startup is OK, I'm fine. But, for example, with uim, we've got a problem with the startup of GNOME, D-bus and some panels.  It looks like a race since restarting later after the session up works fine.

if you don't wanna configure your settings, you do not even need kcm-fcitx or fcitx-config-gtk2(3). they're separate packages. package fcitx has a .conf file as its config, kcm and gtk are used to edit this file. they're just pure UI for better user experience. so no race problem at all. fcitx starts with system(after X11). then kcm reads the config file, since kcm/gtk is not even functional if desktop environment is not ready. Marguerite.

Takashi

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 11, 2012 at 9:58 PM, Takashi Iwai wrote:

At Fri, 11 May 2012 21:49:26 +0800, Marguerite Su wrote:

...

On Fri, May 11, 2012 at 9:43 PM, Takashi Iwai wrote:

...

At Fri, 11 May 2012 21:20:26 +0800, Weng Xuetian wrote:

...

On Fri, May 11, 2012 at 9:04 PM, Marguerite Su wrote:

...

On Fri, May 11, 2012 at 8:56 PM, Karl Eichwalder wrote:

...

Marguerite Su writes:

> can you help drag Korean coordinator into this thread?

I guess both our Korean community translators are no longer active; from the 'translators' file:

Korean (ko) teheo           Tejun Heo xein            Yunseok Choi

Thus I think all we can do, is to ask on opensuse developer lists.

-- Karl Eichwalder                              SUSE LINUX Products GmbH R&D / Documentation                          Maxfeldstraße 5                                             90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

the suse.de might be inactive, but naver.com must be in use. (naver is the most popular search engine, like google.)

so I cc-ed him. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, I'm fcitx's maintainer.

For gnome https://live.gnome.org/ThreePointFive/Features/IBus

Actually fcitx also have xkb support, named fcitx-keyboard (which is already in M17N), and I can confidently say it's provides more feature than ibus. It provides not only keyboard layout integration but also word predication and spell-checking for keyboard layout user. Maybe not so useful for native speaker, but will benefit language learner I think.

There is no doubt that fcitx is the more feature-rich and actively developed project :)  The action we need now is rather to contact with GNOME devs, tell the concerns regarding the integration and provide some patch if available.  They certainly should think of the support of multiple IMs, so the earlier is better than sticking with the hard-coded ibus support in GNOME.

...

One thing need to notice, that fcitx is the only input method support kcm in KDE. And it's already works. Fcitx can also works natively under gnome-shell, with this extension help: https://extensions.gnome.org/extension/261/kimpanel/. And I'm also the maintainer of kimpanel in KDE. (kimpanel is a general dbus protocol for input method UI, works with scim/ibus (kde upstream), fcitx (fcitx upstream).

BTW, this leads me to some questions.  What is the standard start-up procedure?  Is it supposed to be started from a startup desktop file?

Currently, we start a shell script in /etc/X11/xim.d/*, but this could be in a desktop file, too.  The start-up in that place seems sometimes racy with d-bus activation, for example.  12.2 would be a good chance for cleaning up this old stuff, but we need more inputs.

nope, the kcm is for configuration, see kcm-fcitx package in M17N.

it integrates its settings into user "system settings". that's the first and only IM does so now.

the gnome shell extension is kimpanel. provides the input panel for fcitx in Gnome shell.

startup staff is still handled by fcitx main package itself. using shell scripts in xim.d

but if you switched to other ways, he'll catch up in a flash.

OK.  As long as the shell-script startup is OK, I'm fine. But, for example, with uim, we've got a problem with the startup of GNOME, D-bus and some panels.  It looks like a race since restarting later after the session up works fine.

oh sorry, I see, you're talking about the gnome shell extension. I'm not so clear about it, since I never use GNOME. maybe weng can clarify it later. he's working on reading the code and open upstream bug report.

Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 11, 2012 at 4:50 PM, Vincent Untz wrote:

Hi,

Le vendredi 11 mai 2012, à 16:09 +0800, Marguerite Su a écrit :

...

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

I've absolutely no opinion on this, but I find it surprising that you're suggesting to drop ibus from dvd/cd while upstream GNOME is working on deeper ibus integration for the next version:  https://live.gnome.org/ThreePointFive/Features/IBus

Do you have any information on this?

Vincent

-- Les gens heureux ne sont pas pressés.

Hi, Vincent, in my survey there're user choices to "just let scim retire"...so the final proposal relies on users' choice, this is just my temporary proposal to act as a starting point. and my reason is: 1. does western locale needs ibus? 2. situation in C(stands for China), zh_CN people replace it with fcitx, zh_TW people replace it with gcin. so no one will use it(from current vote results, no Japanese vote now). it still has some users only because it's shipped by default. so if no one will use it if he has choices, then why let it be there holding position in DVD and installed by default? why not install the ones users really need? and about the GNOME thing, I have to say, no offense, they are outdated. when there're no alternatives in the old days, they do not make it better; now we have choices, they're making it. it's better say this is the previous slow reaction postponed to now, not the plan for "deeper integration". just a coincidence. it's time to free their hands and let them concentrate on something more important...of course we have to wait enough long to see it happen. PS: btw I think we both know we are talking about do not ship them by default in DVD/CD, not to kick them off entirely from openSUSE. users like them still can install from M17N and OSS repositories. if GNOME is making it better, still good. the decision should rely on numbers of the users uninstalled them at the first time vs. numbers of the users kept using them. then we can make most of our users happy and free from tweak work. according to Takashi, seems there's even a third way. marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

At Fri, 11 May 2012 11:56:37 +0200, Vincent Untz wrote:

Hi,

Le vendredi 11 mai 2012, à 17:36 +0800, Marguerite Su a écrit :

...

On Fri, May 11, 2012 at 4:50 PM, Vincent Untz wrote:

...

Hi,

Le vendredi 11 mai 2012, à 16:09 +0800, Marguerite Su a écrit :

...

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

I've absolutely no opinion on this, but I find it surprising that you're suggesting to drop ibus from dvd/cd while upstream GNOME is working on deeper ibus integration for the next version:  https://live.gnome.org/ThreePointFive/Features/IBus

Do you have any information on this?

Hi, Vincent,

in my survey there're user choices to "just let scim retire"...so the final proposal relies on users' choice, this is just my temporary proposal to act as a starting point.

and my reason is:

1. does western locale needs ibus?

2. situation in C(stands for China), zh_CN people replace it with fcitx, zh_TW people replace it with gcin. so no one will use it(from current vote results, no Japanese vote now). it still has some users only because it's shipped by default.

so if no one will use it if he has choices, then why let it be there holding position in DVD and installed by default? why not install the ones users really need?

and about the GNOME thing, I have to say, no offense, they are outdated. when there're no alternatives in the old days, they do not make it better; now we have choices, they're making it. it's better say this is the previous slow reaction postponed to now, not the plan for "deeper integration". just a coincidence. it's time to free their hands and let them concentrate on something more important...of course we have to wait enough long to see it happen.

PS: btw I think we both know we are talking about do not ship them by default in DVD/CD, not to kick them off entirely from openSUSE. users like them still can install from M17N and OSS repositories. if GNOME is making it better, still good.

My point is that if GNOME relies on ibus in GNOME 3.6, then openSUSE 12.3 will have ibus on the DVD again because of GNOME. Just something to keep in mind.

IMO, dropping ibus from DVD is very unlikely option for 12.2 (I guess you meant this? ;) Using other IMs for some locales as the default is of course a different question. However, I'm a bit worried how tightly GNOME will be bound with ibus. I don't know the detail at all, so I'm writing just from the sensational title line. But I guess no hard-dependency is introduced (hopefully), if it's only about the configuration changes of ibus per gnome-settings-daemon?

And if we're unhappy about GNOME going this way -- which is fine -- then now is the best time to raise objections upstream. But I can't do that since I don't enough about input methods.

If you know any development there, please let us know. At least, it'd be good if anyone can suggest these guys that lots of people are not using ibus but other IMs. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

At Fri, 11 May 2012 12:16:47 +0200, Vincent Untz wrote:

Le vendredi 11 mai 2012, à 12:04 +0200, Takashi Iwai a écrit :

...

At Fri, 11 May 2012 11:56:37 +0200, Vincent Untz wrote:

...

My point is that if GNOME relies on ibus in GNOME 3.6, then openSUSE 12.3 will have ibus on the DVD again because of GNOME. Just something to keep in mind.

IMO, dropping ibus from DVD is very unlikely option for 12.2 (I guess you meant this? ;) Using other IMs for some locales as the default is of course a different question.

However, I'm a bit worried how tightly GNOME will be bound with ibus. I don't know the detail at all, so I'm writing just from the sensational title line. But I guess no hard-dependency is introduced (hopefully), if it's only about the configuration changes of ibus per gnome-settings-daemon?

...

And if we're unhappy about GNOME going this way -- which is fine -- then now is the best time to raise objections upstream. But I can't do that since I don't enough about input methods.

If you know any development there, please let us know. At least, it'd be good if anyone can suggest these guys that lots of people are not using ibus but other IMs.

You might want to contact the person who's working on this upstream: Rui Tiago Cação Matos

Looking at https://live.gnome.org/ThreePointFive/Features/IBus I see that we now have some git branches for the work and this commit makes me believe it's going to be an optional build time dependency at least, if not a hard dependency: http://git.gnome.org/browse/gnome-settings-daemon/commit/?h=wip/input-sources&id=cdffffe6956f7805298e29aa26d53bf917bbc348

To be on the safe side, I think we would enable ibus in our packages so that'd be like a hard dependency...

Hrm, this makes me worry indeed. With this change, gnome-settings-daemon will be linked to libibus and hard-coded for ibus engine changes. This doesn't scale for other IMs. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 11, 2012 at 6:04 PM, Takashi Iwai wrote:

At Fri, 11 May 2012 11:56:37 +0200, Vincent Untz wrote:

...

Hi,

Le vendredi 11 mai 2012, à 17:36 +0800, Marguerite Su a écrit :

...

On Fri, May 11, 2012 at 4:50 PM, Vincent Untz wrote:

...

Hi,

Le vendredi 11 mai 2012, à 16:09 +0800, Marguerite Su a écrit :

...

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

I've absolutely no opinion on this, but I find it surprising that you're suggesting to drop ibus from dvd/cd while upstream GNOME is working on deeper ibus integration for the next version:  https://live.gnome.org/ThreePointFive/Features/IBus

Do you have any information on this?

Hi, Vincent,

in my survey there're user choices to "just let scim retire"...so the final proposal relies on users' choice, this is just my temporary proposal to act as a starting point.

and my reason is:

1. does western locale needs ibus?

2. situation in C(stands for China), zh_CN people replace it with fcitx, zh_TW people replace it with gcin. so no one will use it(from current vote results, no Japanese vote now). it still has some users only because it's shipped by default.

so if no one will use it if he has choices, then why let it be there holding position in DVD and installed by default? why not install the ones users really need?

and about the GNOME thing, I have to say, no offense, they are outdated. when there're no alternatives in the old days, they do not make it better; now we have choices, they're making it. it's better say this is the previous slow reaction postponed to now, not the plan for "deeper integration". just a coincidence. it's time to free their hands and let them concentrate on something more important...of course we have to wait enough long to see it happen.

PS: btw I think we both know we are talking about do not ship them by default in DVD/CD, not to kick them off entirely from openSUSE. users like them still can install from M17N and OSS repositories. if GNOME is making it better, still good.

My point is that if GNOME relies on ibus in GNOME 3.6, then openSUSE 12.3 will have ibus on the DVD again because of GNOME. Just something to keep in mind.

IMO, dropping ibus from DVD is very unlikely option for 12.2 (I guess you meant this? ;)  Using other IMs for some locales as the default is of course a different question.

nope, I don't care when it get dropped. just to say we do not need it any more. if it's dropped, pretty good for saving my 12.2 download bandwidth, if not, it does matter since we do not use it. yeah, I understand. different.

However, I'm a bit worried how tightly GNOME will be bound with ibus. I don't know the detail at all, so I'm writing just from the sensational title line.  But I guess no hard-dependency is introduced (hopefully), if it's only about the configuration changes of ibus per gnome-settings-daemon?

I think it won't be hard dependency, since they developers themselves are from European counties. if they're clever enough, they won't fill their disk full.

...

And if we're unhappy about GNOME going this way -- which is fine -- then now is the best time to raise objections upstream. But I can't do that since I don't enough about input methods.

If you know any development there, please let us know.  At least, it'd be good if anyone can suggest these guys that lots of people are not using ibus but other IMs.

actually we're talking about CJK in openSUSE, not in Linux. as I know, ibus is now developed by Fedora( why they always pick almost dead things and can't save them?). but they're not making progress. and Funny thing is, in Fedora, you have to open bug reports for package review, that package does even not exist on Fedora...hahahahaha and their reviewers are lazy, and only knows ibus(they are from European countries too). not like us, I'm the repo maintainer of M17N, so if I know fcitx is good, I drag it in and submit it to Factory. fcitx-related packages have been in waiting state on their bugzilla for almost two years. that's the background knowledge. so my point is, we can't hold GNOME developer back from integrate ibus into GNOME, and trust my instinct, ibus won't be hard dependency by default.(if I'm wrong, then it proves some of GNOME developers are fool, LOL, just a joke) because other distributions like Fedora has no alternatives like us. they have to endure ibus and its many bugs.(Weng, the fcitx man, even use our OBS to save them) http://fcitx-im.org/wiki/Distribution_Package_Status see this page. fcitx is almost SuSE specific input method now. weng has been pleasing us for long. so it's time for us to make him happy, XD.

thanks,

Takashi

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 11, 2012 at 5:15 PM, Michael Chang wrote:

On Fri, May 11, 2012 at 04:09:08PM +0800, Marguerite Su wrote:

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

       Me myself: fcitx, hime. zh_CN

       hillwood: fcitx zh_CN

       swyear: fcitx, ibus, gcin zh_TW

       tiwai: mozc, scim jp

       ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

      scim/ibus: they're the Chinese input methods in the old days.

      fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

      mozc: it's popular IM in Japan.

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

so I made a survey: https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

Isn't gcin older than scim ?

I'm not a fans of scim (although now I'm using it). We can retire it (not defalt) as it's upstream seems dead (or in zombie state) for a long time.

Thanks, Michael

yes, older, but still active. its developer even fight with hime developer on forums, XD. he's in his 40s and seems to be developing gcin in his 20s. I think it's like "career" to him now, "hard to forget and drop." -- from original fcitx developer. to scim, I know its developer, same family name as mine, "苏哲", "philosophy su" from Mainland China, he's now interesting in other things but still in IM field, he's making upstream of input methods like word split from sentence. even lack of maintenance for scim. so its really time to let scim retire as him.

...

Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, May 11, 2012 at 6:09 PM, Takashi Iwai wrote:

At Fri, 11 May 2012 17:47:08 +0800, Marguerite Su wrote:

...

On Fri, May 11, 2012 at 5:15 PM, Michael Chang wrote:

...

On Fri, May 11, 2012 at 04:09:08PM +0800, Marguerite Su wrote:

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

       Me myself: fcitx, hime. zh_CN

       hillwood: fcitx zh_CN

       swyear: fcitx, ibus, gcin zh_TW

       tiwai: mozc, scim jp

       ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

      scim/ibus: they're the Chinese input methods in the old days.

      fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

      mozc: it's popular IM in Japan.

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

so I made a survey: https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

Isn't gcin older than scim ?

I'm not a fans of scim (although now I'm using it). We can retire it (not defalt) as it's upstream seems dead (or in zombie state) for a long time.

Thanks, Michael

yes, older, but still active.

its developer even fight with hime developer on forums, XD.

he's in his 40s and seems to be developing gcin in his 20s.

I think it's like "career" to him now, "hard to forget and drop." -- from original fcitx developer.

to scim, I know its developer, same family name as mine, "苏哲", "philosophy su" from Mainland China, he's now interesting in other things but still in IM field, he's making upstream of input methods like word split from sentence. even lack of maintenance for scim.

Heh, James once worked at SUSE while he developed SCIM :)

Wow, seems every famous one worked us for a while. and another Su is rocking you again...if I could.

...

so its really time to let scim retire as him.

Well, we need to think of two things: A. Dropping the package completely from distribution   (can live in M17N repo, though) B. Just drop from DVD C. Drop "Provides" tag not to install automatically in addition to B.

I suppose C is a good option for now.  More aggresive option, A, is also possible, but a bit more care for the migration.

A is not possible, since still so many CJK projects provide support for scim, like libpinyin, libgooglepinyin, sunpinyin. It seems Jame's still rocking and scim still has some loyal users. maybe not here right now. but it'll be easier when they wanna have a try of openSUSE. I also think C is the best.

Takashi

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, May 12, 2012 at 11:00 AM, Xin Wang wrote:

2012/5/11 Marguerite Su :

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

      Me myself: fcitx, hime. zh_CN

      hillwood: fcitx zh_CN

      swyear: fcitx, ibus, gcin zh_TW

      tiwai: mozc, scim jp

      ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

     scim/ibus: they're the Chinese input methods in the old days.

     fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

     mozc: it's popular IM in Japan.

I do not familiar with IM area, and I'm just curious why is ibus an IM in the old days?

It's latest version is released at Feb. 2012. And the code is still actively maintained in https://github.com/ibus.

answer your question: KD3 see its last maintenance release on Nov.1, 2011. so is it a brand-new desktop environment?

...

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

so I made a survey: https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- Xin Wang (http://dram.me/) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, May 12, 2012 at 10:29 PM, Fuminobu TAKEYAMA wrote:

Hi all,

...

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

Sure, how can I do?

https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU... here's the form. please help me translate the introduction and options into Japanese, and send them to me. I'll modify the form then. btw, please help me add some sentence in Japanese to encourage use write the input method he's now using and would like to use. because in my options, there're only one Japanese method, mozc( I really have little knowledge of Japanese IM)

Although fcitx is much more popular and useful than IBus in Chinese community, in Japan, almost no one knows it, unfortunately. # I have a friend from Taiwan. He use ibus-chewing.

Honestly speaking for further improvement of fcitx, current released version (fcitx-mozc) does not have enough quality for daily use as far as I tried.

I think what you have to do for Japanese community is improving it so that you can explain how fcitx is superior than IBus in almost all point.

Yes, fcitx developer is also in this thread. one of the problems for fcitx J support is that the developer himself is a Chinese who don't understand Japanese. but as the anthy library is documented in English, it is not that important. the biggest one is nowadays users of mozc-fcitx are just some Chinese ACGers. they just use it to input Japanese word, not sentence, and not on a daily basis. so hard to detect bugs. and since mozc is close developed, FOSS communities does not accept it well, so it's not packaged so wide(only by debian and us). anyway, Japanese communities and users are a little far aways from fcitx developer, but he's willing to hear from them. maybe one or two. that's enough for him. he's about to implement fcitx-anthy(for sure, there's an early state package in home:opensuse_zh), fcitx-skk and fcitx-wnn(maybe), but he is now concentrating his graduation paper, so he can start 2 or 3 months later. any feedback or suggestion to him is appreciated.(eg, which input method backend is the most famous and successful in Japan, anthy? skk? wnn? or else?)

If you show this over quick proposal to Japanese users, it might give them bad impression.

You know, the reason we switch to IBus in 12.1 includes that IBus become as configurable as SCIM.

Yes, Takashi and I made an agreement to keep ibus for now. because no better choice. and Takashi didn't want mozc to be included as default IM for jp locale. because it's close developed and does not accept any patch. if one day it fails, japanese users will hate us because they don't know the details.

I agree with dropping some old IMs from automatically installed package. I have feature request related to this: https://features.opensuse.org/313412

I have already created requests to drop scim and bring fcitx/gcin in. in M17N

With regard to Mozc, it seems that the developers try to concentrate on IBus like the mozc_renderor feature. They will remove code for SCIM soon. We have to be careful.

I and many Japanese users want to put Mozc into the official repository as an exception for usability.

then it's another story. you can ask them to vote for mozc or any other favorite IM. anyway, user experience is much more important than patches. since there're already someone develop it, even they don't want our code work, they still welcome our feedback.

And... I'm watching the git repository of IBus and I think it is very active project.

yep. 9 persons. and it's the default method for fedora, there must be someone continues it. but to tell the truth, famous bugs are still there, like input in Firefox/Chromium, and etc. users already have bad impression on it. once they leave, it's harder to call them back than newbies. the only thing it's there is because it's shipped by default. in my survey, there're Taiwan users who are using ibus, but vote for gcin/hime.

Fuminobu TAKEYAMA

(12/05/11 17:09), Marguerite Su wrote:

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

       Me myself: fcitx, hime. zh_CN

       hillwood: fcitx zh_CN

       swyear: fcitx, ibus, gcin zh_TW

       tiwai: mozc, scim jp

       ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

      scim/ibus: they're the Chinese input methods in the old days.

      fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

      mozc: it's popular IM in Japan.

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

so I made a survey:

https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

Marguerite

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, May 12, 2012 at 11:49 PM, Fuminobu TAKEYAMA wrote:

...

please help me translate the introduction and options into Japanese, and send them to me. I'll modify the form then.

btw, please help me add some sentence in Japanese to encourage use write the input method he's now using and would like to use. because in my options, there're only one Japanese method, mozc( I really have little knowledge of Japanese IM)

 - Why "IM" and "IM engine" are mixed?  - There are a lot of unneeded sentences make it more simple

oh sorry, feel free to correct any tech fault. I'm not good at it. although you treat me as a packager, but indeed I'm no better than a tech newbie. yes. you can fully control your version.

...

any feedback or suggestion to him is appreciated.(eg, which input method backend is the most famous and successful in Japan, anthy? skk? wnn? or else?)

Bug reports written in Japanese are acceptable?

# If fcitx supports canna and separated key settings for IM-on/off, # I'll consider to use fcitx. Note that this is just for me :)

well, I'll ask Weng Xuetian. but I think if the description in Japanese is really plain enough, he can read it in Google Translate. but he can't reply in Japanese. that's where the problem is. so do you mean Canna is popular in Japan? like Fcitx in China? anthy is Japanese scim? then he really needs to reconsider about the priority of anthy... does every input method can be easy switched off using ctrl+space? every Chinese IM has this "feature", it's so common that can't be called a feature any more. Weng is fighting with GNOME people about the compulsory hard coded IBus. I'll bring him in here.

...

and Takashi didn't want mozc to be included as default IM for jp locale. because it's close developed and does not accept any patch. if one day it fails, japanese users will hate us because they don't know the details.

My suggestion is you should write documents about fcitx. Some Japanese community members are googling but they cannot find how it is.

in Japanese? fcitx.org is the wiki site. and has english versions. we're making it better and more detailed.

...

but to tell the truth, famous bugs are still there, like input in Firefox/Chromium, and etc.

users already have bad impression on it. once they leave, it's harder to call them back than newbies.

Could you show me URLs to bugzilla of Novell or other distributions?

okay, Weng has his hands full with this. He must like to show off such bugs as the medal of his success.

...

in my survey, there're Taiwan users who are using ibus, but vote for gcin/hime.

How many users? I heard he would not use gcin since it is too old. I don't know fcitx-chewing is OK for him.

Not too much. 4 - 5. but only 15 or more votes now. yes, old. if you ask him again, he might be using hime now. it's a fork of gcin. and if ibus-chewing is ok for him, fcitx-chewing will be beyond. because weng develops it according to ibus-chewing, XD.

Fuminobu TAKEYAMA

...

...

(12/05/11 17:09), Marguerite Su wrote:

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

       Me myself: fcitx, hime. zh_CN

       hillwood: fcitx zh_CN

       swyear: fcitx, ibus, gcin zh_TW

       tiwai: mozc, scim jp

       ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

      scim/ibus: they're the Chinese input methods in the old days.

      fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

      mozc: it's popular IM in Japan.

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

so I made a survey:

https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

Marguerite

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, May 15, 2012 at 1:05 AM, Fuminobu TAKEYAMA wrote:

Sorry, I lost what you want to do while translating the input form.

Could you summarize what you will do before important change?

Hi， Fuminobu, here are the simple version of my poll summary: Hi, everyone, I know you drop Distribution Default IM and use yours, like I do. so I wonder why we poll your top choice out and make it default? because the replacement is actually easy. (some IMs' introduction) don't worry too much about the DVD size, because we have enough size.:) and the options: do you use IM? yes/no/just show my support, I'm not SuSE user, but I support you. where are you from? China/JP/Hongkong/Taiwan/Singapore/outside world ...(the last two are jokes.) which IM do you use? what about the drop? both/scim/ibus/no replacement (the last two are jokes) what we should ship in DVD? (the last one is a joke) other better suggestion ?(text field) are you human/computer? human/computer. (we can't trust computer's vote)

Well, the purpose of the survey is to know what input method frameworks and engines should be in official repository (ISOs) and not for deciding the default frameworks and engines, right?

for Japan, YES. because MOZC, we all know. for Chinese, we'll replace scim/ibus or both with users' top choice. but for Japan, eg, we'll ship MOZC in DVD, but default still IBus.

Are you trying to change the default IMs and engines? "Default" does not mean automatically installed. A default input method is one that is available after installation.

then, no. I'm trying to change C/K automatically installed ones. if in DVD, it's available, right? the for J, FCITX/IBUS/MOZC will all be there.

...

so do you mean Canna is popular in Japan? like Fcitx in China? No, it is an old Japanese conversion engine but I used it for a Canna-compatible conversion engine. Canna is not supported by IBus. Then, I'm implementing ibus-canna.

...

anthy is Japanese scim? No.

Fcitx, IBus, SCIM, UIM and ... are called input method framework. # also called, environment, platform. Anthy, Mozc, Canna, ... are input method (conversion) engines. These frameworks connect engines to Qt, Gtk and XIM.

IBus is now most common input method framework and widely used on major distributions including openSUSE, Ubuntu, Fedora, ... de-facto standard? It replaced SCIM because SCIM could not support Gtk3.

The default input method and engine on 12.1 for Japanese is ibus-anthy, which means connector for Anthy and IBus.

scim-anthy was used until 11.4.

oh I see. thanks.

...

does every input method can be easy switched off using ctrl+space? In IBus and SCIM, we can assign, for example, "Henkan" to turning on IM and "Muhenkan" to turning off, not toggling.  # like Mac OS X :D

oh. that's easy. can be done in FCITX too.

# I will enhancement and bug reports directly to fcitx project. # Let's discuss there! (in English)

okay, big hug and thanks! I'll keep improving the EN docs.

...

...

Some Japanese community members are googling but they cannot find how it is.

in Japanese?

and in English. I think you need more and more information to spread fcitx on the website. I also have not understand the benefit yet.

...but we don't know Japanese. maybe we can find someone knows in Chinese Community. and you J community modified after because it'll not be so precise due to languages obstacles.

...

...

How many users? I heard he would not use gcin since it is too old. I don't know fcitx-chewing is OK for him. Not too much. 4 - 5. but only 15 or more votes now. yes, old. if you ask him again, he might be using hime now.

I asked him last week, so... It might be normal input method for zh_tw on Ubuntu?

yes....default and forced...like what GNOME is planning to do... users had hard times to replace it. users are crazy on Lauchpad...

(2012/05/13 1:25), Weng Xuetian wrote:

...

fcitx-chewing is developed by a Taiwan developer. And some of Taiwan user are using it, AFAIK there is no much problem about it. (snip)

...

Some additional info, the fcitx-chewing developer used to be a hime developer.

I'll ask him about gcin/hime/chewing/fcitx-chewing again.

Fuminobu TAKEYAMA

(2012/05/13 1:11), Marguerite Su wrote:

...

On Sat, May 12, 2012 at 11:49 PM, Fuminobu TAKEYAMA  wrote:

...

...

please help me translate the introduction and options into Japanese, and send them to me. I'll modify the form then.

btw, please help me add some sentence in Japanese to encourage use write the input method he's now using and would like to use. because in my options, there're only one Japanese method, mozc( I really have little knowledge of Japanese IM)

 - Why "IM" and "IM engine" are mixed?  - There are a lot of unneeded sentences make it more simple

oh sorry, feel free to correct any tech fault. I'm not good at it. although you treat me as a packager, but indeed I'm no better than a tech newbie.

yes. you can fully control your version.

...

...

any feedback or suggestion to him is appreciated.(eg, which input method backend is the most famous and successful in Japan, anthy? skk? wnn? or else?)

Bug reports written in Japanese are acceptable?

# If fcitx supports canna and separated key settings for IM-on/off, # I'll consider to use fcitx. Note that this is just for me :)

well, I'll ask Weng Xuetian.

but I think if the description in Japanese is really plain enough, he can read it in Google Translate.

but he can't reply in Japanese. that's where the problem is.

so do you mean Canna is popular in Japan? like Fcitx in China? anthy is Japanese scim?

then he really needs to reconsider about the priority of anthy...

does every input method can be easy switched off using ctrl+space? every Chinese IM has this "feature", it's so common that can't be called a feature any more.

Weng is fighting with GNOME people about the compulsory hard coded IBus.

I'll bring him in here.

...

...

and Takashi didn't want mozc to be included as default IM for jp locale. because it's close developed and does not accept any patch. if one day it fails, japanese users will hate us because they don't know the details.

My suggestion is you should write documents about fcitx. Some Japanese community members are googling but they cannot find how it is.

in Japanese?

fcitx.org is the wiki site. and has english versions. we're making it better and more detailed.

...

...

but to tell the truth, famous bugs are still there, like input in Firefox/Chromium, and etc.

users already have bad impression on it. once they leave, it's harder to call them back than newbies.

Could you show me URLs to bugzilla of Novell or other distributions?

okay, Weng has his hands full with this.

He must like to show off such bugs as the medal of his success.

...

...

in my survey, there're Taiwan users who are using ibus, but vote for gcin/hime.

How many users? I heard he would not use gcin since it is too old. I don't know fcitx-chewing is OK for him.

Not too much. 4 - 5. but only 15 or more votes now.

yes, old. if you ask him again, he might be using hime now.

it's a fork of gcin.

and if ibus-chewing is ok for him, fcitx-chewing will be beyond.

because weng develops it according to ibus-chewing, XD.

...

Fuminobu TAKEYAMA

...

...

(12/05/11 17:09), Marguerite Su wrote:

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

       Me myself: fcitx, hime. zh_CN

       hillwood: fcitx zh_CN

       swyear: fcitx, ibus, gcin zh_TW

       tiwai: mozc, scim jp

       ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

      scim/ibus: they're the Chinese input methods in the old days.

      fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

      mozc: it's popular IM in Japan.

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

so I made a survey:

https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

Marguerite

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, May 15, 2012 at 4:45 PM, Satoru Matsumoto wrote:

Marguerite Su wrote:

...

On Tue, May 15, 2012 at 1:05 AM, Fuminobu TAKEYAMA  wrote:

...

...

...

...

Some Japanese community members are googling but they cannot find how it is.

in Japanese?

and in English. I think you need more and more information to spread fcitx on the website. I also have not understand the benefit yet.

That's the point. I've installed and used fcitx for a while, but to be honest, I couldn't find its advantages against IBus and felt that it isn't mature enough, at least for now. ATM, it may be good for Chinese, but not so good for Japanese.

yes, for now. to be honest. that's why we keep ibus for J. and I'm happy to see so many J people here like to try fcitx and baby sit it to grow in J support.

Marguerite, you say 'SCIM, IBus, gcin ... are old', but 'old' doesn't always mean 'bad'. I think you haven't enough explained yet, what are the advantages of using fcitx and disadvantages of using other IM frameworks except old or new.

old doesn't mean bad at all. all of them are old.(fcitx is "old" too, it launched 1.0 in 2004) and still work on KDE (SCIM not work for GTK3) some of them are still being maintained upstream (IBUS & GCIN & FCITX). here I'll cite Weng's word to give you a summary of their technically details: SCIM nothing to say. James Su is the best in his era. SCIM is best in its era. but that era has passed. IBUS. introduced module concept. but just a try. it didn't think too much on low-level design. so its layers are not abstract enough to implement features that easy. like if you want to implement some IMF(Input Method Framework) level features, actually, you have to hack every single engine/tables it used, like anthy/canna/blabla...every one of them. FCIX. modular and abstract. if you want to implement cross-over features, do it in framework. all engines will catch up automatically. and their maintain status: SCIM: no more. IBUS: its father left to Google. like James Su left SuSE. now its maintained by Red Hat/Fedora guys. and they're few to change low-level framework( to talk about IM, only you and us, I mean quite few developers in C and J community know what an IM really are, but unlikely not in FH/F, even SuSE. if you know James and ask him, the answer is yes. it sounds small, but actually a huge system, almost in every detail in low-level. so if you design a system without take IM into consideration, it's hard to change later. that's why we Chinese developers strongly against GNOME' idea to integrate IM into desktop) . so can only maintain comparability between framework and engines, distributions. it means it can be used for now, but what if a brand new engine comes that has much more features for users and much more requirements on engines? IBus can't catch up. because in low-level they didn't think that much. FCITX: well its features are solid (fcitx-anthy is actually experimental, fcitx-mozc just see its second release in our distro), and still under development. so it has many possibilities in future. so if you try it( of course, now you have no mature J support to try, but it'll come quickly in the coming month), you'll like it. Features: SCIM: no need to say much since it dead. IBUS: you're the user. FCITX: in engines, they're the same. so technically, if you "feel" mature IBUS-anthy well, you will at least feel the same well of fcitx-anthy. and it has much more user-oriented features. (later I can wiki it on fcitx wiki. although I don't know Japanese, but maybe I could use some "video tutorials" to show what these features are... and I'll add such details to our wiki, for distro packagers, not me, nor you, nor tiwai or ftake, but for newcomers who'll take over our maintainership in the future. to catch up with brief knowledge/basic introductions/required respects to maintain an IM.

If you just want to provide much more easy way to select IM framework (not IM engine, here I say...) to users, I don't raise an objection. For example:

- fcitx and related packages will be included in install DVD - (ATM) only when users select Chinese language during installation,  these packages will be automatically installed (is this technically  available?).

according to coolo and tiwai, if I didn't understand wrong. yes. and available.

- in that case, symlink of fcitx will be put in /etc/X11/xim.d/zh_*  directories as 30-fcitx

... is this what you want?  If yes, Japanese and Korean users won't be affected by the change tentatively, and once they will recognize the benefit of fcitx, they will be easily able to transit from IBus to fcitx. :-)

yes. that's what I'll do. Ja is still ibus by default. and I'll ship mozc in DVD too. (it's not openly developed. so Takashi suggested not to set it as default IM) so you can install mozc manually. but if you didn't select anything, it'll be ibus-anthy. technically I seems have to write a start-up script and set its priority 60 or 70 (IBUS is 50)

However, one thing we have to remember is, IIRC, if fcitx will be included in install DVD, that means it would be included in main OSS repo. As you may know, packages in main OSS repo shouldn't be easily upgraded unless security holes or bugs are found and should be fixed. IE, if you want to provide up-to-date packages to users constantly, a development branch repo for that (maybe M17N repo?) is also needed anyhow.

oh yes. I understand. actually, I didn't learn the maintain procedure part of OBS. but I'll. and if fcitx has a low-level (not compile time) bug, I'll transfer to weng, and he can fix it in 2/3 hours maybe. the I'll push that patch to update. but I won't think that'll happen too often. because fcitx is 4.2.3 now and 8 years old in Simplified Chinese. and has become default IM for debian SC in maybe 2007 or 2008. history proves it does not have that much bugs.

Best,

-- _/_/     Satoru Matsumoto - openSUSE Member - Japan _/_/ _/_/  Marketing/Weekly News/openFATE Screening Team _/_/ _/_/ mail: helios_reds_at_gmx.net / irc: HeliosReds _/_/ _/_/                http://blog.zaq.ne.jp/opensuse/ _/_/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, May 15, 2012 at 6:36 PM, Takashi Iwai wrote:

At Tue, 15 May 2012 14:14:04 +0800, Marguerite Su wrote:

...

...

Well, the purpose of the survey is to know what input method frameworks and engines should be in official repository (ISOs) and not for deciding the default frameworks and engines, right?

for Japan, YES. because MOZC, we all know.

for Chinese, we'll replace scim/ibus or both with users' top choice.

but for Japan, eg, we'll ship MOZC in DVD, but default still IBus.

In the current situation, we don't have mozc on DVD but only on online repos.  The situation regarding mozc should be discussed again in opensuse-ja ML.

Takashi

yes, I only sent 3 SRs to M17N. 1. drag GCIN into DVD (accepted by lin) 2. drop scim from DVD (main-package) Takashi, do I have to remove every Provides: locale(scim: ja/zh/kr) thing from scim sub-packages based on scim? 3. drag fcitx main package into DVD the last two are in waiting state. since the poll doesn't finished yet in SC/TC area. it's still growing. and I just do some prediction work... and I'm glad to hear any news from opensuse-ja...but apparently it's in Japanese...so if any good news...tell me... Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, May 15, 2012 at 9:17 PM, Takashi Iwai wrote:

At Tue, 15 May 2012 21:12:11 +0800, Marguerite Su wrote:

...

On Tue, May 15, 2012 at 6:36 PM, Takashi Iwai wrote:

...

At Tue, 15 May 2012 14:14:04 +0800, Marguerite Su wrote:

...

...

Well, the purpose of the survey is to know what input method frameworks and engines should be in official repository (ISOs) and not for deciding the default frameworks and engines, right?

for Japan, YES. because MOZC, we all know.

for Chinese, we'll replace scim/ibus or both with users' top choice.

but for Japan, eg, we'll ship MOZC in DVD, but default still IBus.

In the current situation, we don't have mozc on DVD but only on online repos.  The situation regarding mozc should be discussed again in opensuse-ja ML.

Takashi

yes, I only sent 3 SRs to M17N.

1. drag GCIN into DVD (accepted by lin) 2. drop scim from DVD (main-package)

Takashi, do I have to remove every Provides: locale(scim: ja/zh/kr) thing from scim sub-packages based on scim?

If we want to drop the automatic installation of scim, then yes. OTOH, installing scim doesn't hurt except for some disk spaces once when you adjust the priority of other IMs correctly.

So, I'd suggest to keep it until other tasks are done.

Takashi

so maybe I should take it carefully. like just removing all zh strings from Provides....so it won't hurt and in DVD(because ja/ko still Provides), old users can select then. but like you said. keep it until other tasks are done. even if one single Chinese vote for SCIM, I have to keep all the zh strings... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, Marguerite and all, You said:

for Chinese, we'll replace scim/ibus or both with users' top choice.

but it is inconsistent with:

...

Are you trying to change the default IMs and engines? then, no.

I'm trying to change C/K automatically installed ones.

I strongly suggest that you should not change default IMs and engines for locales that you are not familiar with, including ja, zh_tw, ko. I mean ibus-chewing and ibus-hangul should continue to be default. The reason is as we discussed in this thread. # again, for the future of fcitx Such change might be acceptable if you get enough answers of the survey *from the statistic view point*; other distributions change them; or there is no other solution. I think it is no problem that both Fcitx and IBus is automatically installed as long as Fcitx have lower precedence than IBus for those locale.

here are the simple version of my poll summary:

Hi, everyone, I know you drop Distribution Default IM and use yours, (snip) don't worry too much about the DVD size, because we have enough size.:)

and the options:

You should just say "We would like know which IM are used, should be available and installed."

what about the drop? both/scim/ibus/no replacement (the last two are jokes) This question is not needed. And please do not write jokes; I would not translate them.

Add new question like: What IMs are you using? IM framework list - Fcitx - IBus - SCIM - ... (snip) - Other (free input) - None IM Engine and integrated IM list - Anthy - ... (snip) - Gcin - Mozc - Pinyin - Other (free input)

what we should ship in DVD? (the last one is a joke) Here, the same list above.

Add another question: Which IM should be default for your locale? The same list above. Of course, you must include IBus. Fuminobu TAKEYAMA (2012/05/15 15:14), Marguerite Su wrote:

On Tue, May 15, 2012 at 1:05 AM, Fuminobu TAKEYAMA wrote:

...

Sorry, I lost what you want to do while translating the input form.

Could you summarize what you will do before important change?

Hi， Fuminobu,

here are the simple version of my poll summary:

Hi, everyone, I know you drop Distribution Default IM and use yours, like I do.

so I wonder why we poll your top choice out and make it default? because the replacement is actually easy.

(some IMs' introduction)

don't worry too much about the DVD size, because we have enough size.:)

and the options:

do you use IM? yes/no/just show my support, I'm not SuSE user, but I support you.

where are you from? China/JP/Hongkong/Taiwan/Singapore/outside world ...(the last two are jokes.)

which IM do you use?

what about the drop? both/scim/ibus/no replacement (the last two are jokes)

what we should ship in DVD? (the last one is a joke)

other better suggestion ?(text field)

are you human/computer? human/computer. (we can't trust computer's vote)

...

Well, the purpose of the survey is to know what input method frameworks and engines should be in official repository (ISOs) and not for deciding the default frameworks and engines, right?

for Japan, YES. because MOZC, we all know.

for Chinese, we'll replace scim/ibus or both with users' top choice.

but for Japan, eg, we'll ship MOZC in DVD, but default still IBus.

...

Are you trying to change the default IMs and engines? "Default" does not mean automatically installed. A default input method is one that is available after installation.

then, no.

I'm trying to change C/K automatically installed ones.

if in DVD, it's available, right? the for J, FCITX/IBUS/MOZC will all be there.

...

...

so do you mean Canna is popular in Japan? like Fcitx in China? No, it is an old Japanese conversion engine but I used it for a Canna-compatible conversion engine. Canna is not supported by IBus. Then, I'm implementing ibus-canna.

...

anthy is Japanese scim? No.

Fcitx, IBus, SCIM, UIM and ... are called input method framework. # also called, environment, platform. Anthy, Mozc, Canna, ... are input method (conversion) engines. These frameworks connect engines to Qt, Gtk and XIM.

IBus is now most common input method framework and widely used on major distributions including openSUSE, Ubuntu, Fedora, ... de-facto standard? It replaced SCIM because SCIM could not support Gtk3.

The default input method and engine on 12.1 for Japanese is ibus-anthy, which means connector for Anthy and IBus.

scim-anthy was used until 11.4.

oh I see. thanks.

...

...

does every input method can be easy switched off using ctrl+space? In IBus and SCIM, we can assign, for example, "Henkan" to turning on IM and "Muhenkan" to turning off, not toggling. # like Mac OS X :D

oh. that's easy. can be done in FCITX too.

...

# I will enhancement and bug reports directly to fcitx project. # Let's discuss there! (in English)

okay, big hug and thanks! I'll keep improving the EN docs.

...

...

...

Some Japanese community members are googling but they cannot find how it is.

in Japanese?

and in English. I think you need more and more information to spread fcitx on the website. I also have not understand the benefit yet.

...but we don't know Japanese. maybe we can find someone knows in Chinese Community. and you J community modified after because it'll not be so precise due to languages obstacles.

...

...

...

How many users? I heard he would not use gcin since it is too old. I don't know fcitx-chewing is OK for him. Not too much. 4 - 5. but only 15 or more votes now. yes, old. if you ask him again, he might be using hime now.

I asked him last week, so... It might be normal input method for zh_tw on Ubuntu?

yes....default and forced...like what GNOME is planning to do...

users had hard times to replace it.

users are crazy on Lauchpad...

...

(2012/05/13 1:25), Weng Xuetian wrote:

...

fcitx-chewing is developed by a Taiwan developer. And some of Taiwan user are using it, AFAIK there is no much problem about it. (snip)

...

Some additional info, the fcitx-chewing developer used to be a hime developer.

I'll ask him about gcin/hime/chewing/fcitx-chewing again.

Fuminobu TAKEYAMA

(2012/05/13 1:11), Marguerite Su wrote:

...

On Sat, May 12, 2012 at 11:49 PM, Fuminobu TAKEYAMA wrote:

...

...

please help me translate the introduction and options into Japanese, and send them to me. I'll modify the form then.

btw, please help me add some sentence in Japanese to encourage use write the input method he's now using and would like to use. because in my options, there're only one Japanese method, mozc( I really have little knowledge of Japanese IM)

- Why "IM" and "IM engine" are mixed? - There are a lot of unneeded sentences make it more simple

oh sorry, feel free to correct any tech fault. I'm not good at it. although you treat me as a packager, but indeed I'm no better than a tech newbie.

yes. you can fully control your version.

...

...

any feedback or suggestion to him is appreciated.(eg, which input method backend is the most famous and successful in Japan, anthy? skk? wnn? or else?)

Bug reports written in Japanese are acceptable?

# If fcitx supports canna and separated key settings for IM-on/off, # I'll consider to use fcitx. Note that this is just for me :)

well, I'll ask Weng Xuetian.

but I think if the description in Japanese is really plain enough, he can read it in Google Translate.

but he can't reply in Japanese. that's where the problem is.

so do you mean Canna is popular in Japan? like Fcitx in China? anthy is Japanese scim?

then he really needs to reconsider about the priority of anthy...

does every input method can be easy switched off using ctrl+space? every Chinese IM has this "feature", it's so common that can't be called a feature any more.

Weng is fighting with GNOME people about the compulsory hard coded IBus.

I'll bring him in here.

...

...

and Takashi didn't want mozc to be included as default IM for jp locale. because it's close developed and does not accept any patch. if one day it fails, japanese users will hate us because they don't know the details.

My suggestion is you should write documents about fcitx. Some Japanese community members are googling but they cannot find how it is.

in Japanese?

fcitx.org is the wiki site. and has english versions. we're making it better and more detailed.

...

...

but to tell the truth, famous bugs are still there, like input in Firefox/Chromium, and etc.

users already have bad impression on it. once they leave, it's harder to call them back than newbies.

Could you show me URLs to bugzilla of Novell or other distributions?

okay, Weng has his hands full with this.

He must like to show off such bugs as the medal of his success.

...

...

in my survey, there're Taiwan users who are using ibus, but vote for gcin/hime.

How many users? I heard he would not use gcin since it is too old. I don't know fcitx-chewing is OK for him.

Not too much. 4 - 5. but only 15 or more votes now.

yes, old. if you ask him again, he might be using hime now.

it's a fork of gcin.

and if ibus-chewing is ok for him, fcitx-chewing will be beyond.

because weng develops it according to ibus-chewing, XD.

...

Fuminobu TAKEYAMA

...

...

(12/05/11 17:09), Marguerite Su wrote: > > > > Hi, last night I asked coolo about how to replace input methods in > ISOs. he said all I have to do is to make proposal here and cc-ed to > related parts like maintianers of those input methods and users > interested in. > > Here're the names I found from OBS. they're package maintainers. below > are their packages and locales. > > Me myself: fcitx, hime. zh_CN > > hillwood: fcitx zh_CN > > swyear: fcitx, ibus, gcin zh_TW > > tiwai: mozc, scim jp > > ftake: mozc jp > > and if everyone feel affected or involved in this issue, please feel > free to join. > > (because those input methods also support other languages besides CJK, > although such support is minor.) > > and Here're the packages involved: > > scim/ibus: they're the Chinese input methods in the old days. > > fcitx/gcin/hime: they're the Chinese input methods in modern > Linux. > > mozc: it's popular IM in Japan. > > of course they're both for Linux, and both open source works. > > and the situation is, when I freshly installed openSUSE, the first > thing I do is uninstall those old-time input methods and install new > ones. so I wonder if this situation is common, and if it is common, > why not replace them by default instead of leaving works to our users? > > so I made a survey: > > > > https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU... > > and posted on G+, forums. the temporary result I've got is this > situation is common in Chinese Community. > > (tiwai or ftake, can you please translate to Japanese and spread it > out to Japanese Community?) > > (since we do not have active Korean developers here, so no way to hear > from them. so only C and J here.) > > and my proposal is: > > 1. drop scim/ibus from DVD/CD. (they're really old and react slow to > bugs and have famous bugs) > 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's > another issue, it has a small user database) > > so guys what do you think? > > Marguerite

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, May 12, 2012 at 11:49 PM, Fuminobu TAKEYAMA wrote:

...

please help me translate the introduction and options into Japanese, and send them to me. I'll modify the form then.

btw, please help me add some sentence in Japanese to encourage use write the input method he's now using and would like to use. because in my options, there're only one Japanese method, mozc( I really have little knowledge of Japanese IM)

- Why "IM" and "IM engine" are mixed? - There are a lot of unneeded sentences make it more simple

...

any feedback or suggestion to him is appreciated.(eg, which input method backend is the most famous and successful in Japan, anthy? skk? wnn? or else?)

Bug reports written in Japanese are acceptable?

Well yes. I don't really mind non-English language bug report.

# If fcitx supports canna and separated key settings for IM-on/off, # I'll consider to use fcitx. Note that this is just for me :)

...

and Takashi didn't want mozc to be included as default IM for jp locale. because it's close developed and does not accept any patch. if one day it fails, japanese users will hate us because they don't know the details.

My suggestion is you should write documents about fcitx. Some Japanese community members are googling but they cannot find how it is.

...

but to tell the truth, famous bugs are still there, like input in Firefox/Chromium, and etc.

users already have bad impression on it. once they leave, it's harder to call them back than newbies.

Could you show me URLs to bugzilla of Novell or other distributions?

...

in my survey, there're Taiwan users who are using ibus, but vote for gcin/hime.

How many users? I heard he would not use gcin since it is too old. I don't know fcitx-chewing is OK for him.

fcitx-chewing is developed by a Taiwan developer. And some of Taiwan user are using it, AFAIK there is no much problem about it. And fcitx-libpinyin will provide better experience than chewing, though usage is not exact same with chewing. (All based on bopomofo, like pinyin on Chinese mainland)

Fuminobu TAKEYAMA

...

...

(12/05/11 17:09), Marguerite Su wrote:

...

Hi, last night I asked coolo about how to replace input methods in ISOs. he said all I have to do is to make proposal here and cc-ed to related parts like maintianers of those input methods and users interested in.

Here're the names I found from OBS. they're package maintainers. below are their packages and locales.

Me myself: fcitx, hime. zh_CN

hillwood: fcitx zh_CN

swyear: fcitx, ibus, gcin zh_TW

tiwai: mozc, scim jp

ftake: mozc jp

and if everyone feel affected or involved in this issue, please feel free to join.

(because those input methods also support other languages besides CJK, although such support is minor.)

and Here're the packages involved:

scim/ibus: they're the Chinese input methods in the old days.

fcitx/gcin/hime: they're the Chinese input methods in modern Linux.

mozc: it's popular IM in Japan.

of course they're both for Linux, and both open source works.

and the situation is, when I freshly installed openSUSE, the first thing I do is uninstall those old-time input methods and install new ones. so I wonder if this situation is common, and if it is common, why not replace them by default instead of leaving works to our users?

so I made a survey:

https://docs.google.com/a/marguerite.su/spreadsheet/viewform?formkey=dDdoMmU...

and posted on G+, forums. the temporary result I've got is this situation is common in Chinese Community.

(tiwai or ftake, can you please translate to Japanese and spread it out to Japanese Community?)

(since we do not have active Korean developers here, so no way to hear from them. so only C and J here.)

and my proposal is:

1. drop scim/ibus from DVD/CD. (they're really old and react slow to bugs and have famous bugs) 2. add fcitx/gcin/mozc in. (hime is just another fork of gcin. it's another issue, it has a small user database)

so guys what do you think?

Marguerite

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marguerite Su wrote:

On Sat, May 12, 2012 at 10:29 PM, Fuminobu TAKEYAMA wrote:

...

With regard to Mozc, it seems that the developers try to concentrate on IBus like the mozc_renderor feature. They will remove code for SCIM soon. We have to be careful.

I and many Japanese users want to put Mozc into the official repository as an exception for usability.

then it's another story. you can ask them to vote for mozc or any other favorite IM.

anyway, user experience is much more important than patches. since there're already someone develop it, even they don't want our code work, they still welcome our feedback.

Well, I think stability is as important as user experience, in particular for our DEFAULT choice. I also recognize the superiority of mozc and use it for my daily work, but still I'm not positive toward making it as the _DEFAULT_ IM for Japanese. Mozc developers only consist of Google employees, that is, the development of it can be very much affected by Google's will and strategy. It will be a risk, if we will too much depend on such a software. You say 'they still welcome our feedback', but I'd like to add 'as long as the feedback is comply with their strategy'. ;-) And one of the negative effects caused by their reject of patches from third parties is, that each distribution and project has to prepare and maintain needed patches by themselves, even if the purpose of patches is fixing small problems. An important thing is, that upstream developers don't know and take care of such patches. This may cause some problems every time upstream releases a new version. If there are and will be responsible maintainers for that, there might be no problem. But if there isn't, this will be also a risk. Note, I also value users' freedom of choice. If we can provide a good way to choose favorite IM much more easily, that will be nice and may be the solution of this discussion. :-) Best, -- _/_/ Satoru Matsumoto - openSUSE Member - Japan _/_/ _/_/ Marketing/Weekly News/openFATE Screening Team _/_/ _/_/ mail: helios_reds_at_gmx.net / irc: HeliosReds _/_/ _/_/ http://blog.zaq.ne.jp/opensuse/ _/_/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marguerite Su wrote:

On Sun, May 13, 2012 at 1:14 AM, Satoru Matsumoto wrote:

...

Marguerite Su wrote:

...

I also recognize the superiority of mozc and use it for my daily work, but still I'm not positive toward making it as the _DEFAULT_ IM for Japanese.

Mozc developers only consist of Google employees, that is, the development of it can be very much affected by Google's will and strategy. It will be a risk, if we will too much depend on such a software. You say 'they still welcome our feedback', but I'd like to add 'as long as the feedback is comply with their strategy'. ;-)

yes, that's what we worried about. and one of the reason why FOSS people are hard to accept it as Real Free Software.

One point I would want to make is Picasa's case, which is still fresh in our minds. Refer to: http://en.wikipedia.org/wiki/Picasa#Linux "On April 20, 2012 Google announced that they were deprecating Picasa for Linux and will no longer maintain it on that operating system." Some may say the situation of mozc is different from that of Picasa because the sources of mozc are open under New BSD License anyway. But if Google will devotes less and less resources for mozc in the future for some reasons, it will be difficult for Non-Google guys to help the project under this closed development style. Best, -- _/_/ Satoru Matsumoto - openSUSE Member - Japan _/_/ _/_/ Marketing/Weekly News/openFATE Screening Team _/_/ _/_/ mail: helios_reds_at_gmx.net / irc: HeliosReds _/_/ _/_/ http://blog.zaq.ne.jp/opensuse/ _/_/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org