Bug 174144 - default IME used should depend on app locale
Summary: default IME used should depend on app locale
Alias: None
Product: Fedora
Classification: Fedora
Component: scim   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
Keywords: FutureFeature, i18n
Depends On:
Blocks: SCIM
TreeView+ depends on / blocked
Reported: 2005-11-25 04:22 UTC by Lawrence Lim
Modified: 2014-03-26 00:52 UTC (History)
3 users (show)

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

Attachments (Terms of Use)

Description Lawrence Lim 2005-11-25 04:22:11 UTC
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 05:42:29 UTC
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 06:47:46 UTC
> Interesting observation that this feature already exist, however, only with OOo

Is that using XIM?

Comment 3 James Su 2006-01-11 04:17:21 UTC
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 05:14:09 UTC
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 05:23:21 UTC
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 05:30:08 UTC
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 06:52:11 UTC
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 07:42:30 UTC
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 14:44:50 UTC
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.