Bug 174144 - default IME used should depend on app locale
default IME used should depend on app locale
Product: Fedora
Classification: Fedora
Component: scim (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jens Petersen
: FutureFeature, i18n
Depends On:
Blocks: SCIM
  Show dependency treegraph
Reported: 2005-11-24 23:22 EST by Lawrence Lim
Modified: 2014-03-25 20:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-24 09:44:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lawrence Lim 2005-11-24 23:22:11 EST
Description of problem:
At the moment, if the initial IME for the desktop is ja's Anthy and the user
switch to another IME ko's Hangul, when activating scim in a new Input Context,
it will be Hangul. Even when the application is explicitly started with
LANG=zh_CN.UTF8, the IME activated will still be Hangul. It will be nice if the
default IME can be

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.log in with ja locale, ja's Anthy should be the default IME 
2.start gnome-terminal
3.activate scim, switch to ko's Hangul using ctrl-SPACE repeatedly
4.start another application, LANG=zh_CN.UTF-8 gedit
5.activate LE
Actual results:
still ko's hangul

Expected results:
default zh_CN IME

Additional info:
Comment 1 Lawrence Lim 2005-11-25 00:42:29 EST
Interesting observation that this feature already exist, however, only with OOo
, openoffice.org-core-2.0.1-, if I start oowriter with LANG=zh_TW,
Array30 will be loaded and if I start with LANG=zh_CN, Pinyin will be loaded. 
Comment 2 Jens Petersen 2005-11-25 01:47:46 EST
> Interesting observation that this feature already exist, however, only with OOo

Is that using XIM?
Comment 3 James Su 2006-01-10 23:17:21 EST
scim remember the default input method for each system language. You change the
default input method for ja to a hangul input method in one application, then
scim thinks that you want to use it by default for ja system language, so this
hangul input method will be the default one for other applications running under
ja language.
Comment 4 Warren Togami 2006-02-06 00:14:09 EST
I personally am satisfied with this designed behavior of SCIM.  Is there any
disagreement that it should be different?  Otherwise we can close this bug.
Comment 5 Lawrence Lim 2006-02-06 00:23:21 EST
I still think otherwise. If user starts an application with ja_JP explicitly,
you would want the IME to be consistent with the locale. I think this is a
clever feature which would enhance the user experience.
Comment 6 Warren Togami 2006-02-06 00:30:08 EST
Hmm, on second thought you are correct.

However what should be the default input language if your current LANG is not
listed (like en_US)?  I personally want it to default to the last used input
language in such cases.  This must be the reason why I like the current
behavior.  I do however now understand why it should behave differently for the
supported IM languages.
Comment 7 Jens Petersen 2006-02-07 01:52:11 EST
Ok, the rfe should be weakened to be "overriding the current IME
when starting in an app in a non-default locale"?  But I guess that
is not a very common usage case.
Comment 8 Warren Togami 2006-02-08 02:42:30 EST
What about the case like this:
1) Login in ja_JP mode.
2) Use Pinyin input in thunderbird.
3) Run firefox.

Do you expect Anthy to override the current setting of Pinyin?  I personally
wouldn't expect it to change when I'm already using SCIM in another application.
 Maybe this is OK for only the first application, but not subsequent.
Comment 9 Jens Petersen 2006-02-24 09:44:50 EST
Well if users change the IME to different IME then scim remembers that
and uses it: IMHO the current behaviour is good enough and optimal
in most cases, so closing for now.

Note You need to log in before you can comment on or make changes to this bug.