Bug 216100

Summary:	Chinese input should allow commit with Enter too
Product:	[Fedora] Fedora	Reporter:	Jens Petersen <petersen>
Component:	scim-pinyin	Assignee:	Peng Huang <phuang>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	aalam, eng-i18n-bugs, majain, mjd+redhat
Target Milestone:	---	Keywords:	FutureFeature, i18n, MoveUpstream, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-11-20 23:13:25 EST	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---
Bug Depends On:	214955
Bug Blocks:

Description Jens Petersen 2006-11-17 04:22:18 EST

+++ This bug was initially created as a clone of Bug #214955 +++

Description of problem:
Unable to commit characters in Chinese simplified (Wubi) when pressing Enter.
However, the same characters are committed using space.

Version-Release number of selected component (if applicable):
scim-tables-chinese-0.5.7-1.fc7
scim-1.4.4-35.fc6

How reproducible:
Everytime when trying to commit chars with "enter"

Steps to Reproduce:
1. Open gedit, select simplified chinese > wubi
2. press "l" & press "enter"
3. "l" is committed to gedit. Instead its chinese representation (国) should
have been comitted.
  
Actual results:
l

Expected results:
国

Additional info:

-- Additional comment from mjd-redhat@afork.com on 2006-11-11 03:12 EST --
This happens for pinyin entry method too.

I keep expecting Enter to work, since it does with the Windows IME.

-- Additional comment from cchance@redhat.com on 2006-11-12 20:24 EST --
FYI in Changjie, Space is used to be the commit Key.

I am not sure if there would be appropriate to trigger a feature request to
customize the commit key for scim-tables, or scim-tables-chinese.

-- Additional comment from petersen@redhat.com on 2006-11-12 20:41 EST --
Using space for commit is pretty standard for Chinese: I think it is
a matter of habit... :)

You could try requestinging upstream to have the commit keys be made configurable.
For scim-tables if you really want to override Space you can copy the table .txt to
your personal scim folder and change the commit key in the table file and recompile
the table with scim-make-table.


-- Additional comment from petersen@redhat.com on 2006-11-12 20:42 EST --
*** Bug 214957 has been marked as a duplicate of this bug. ***

-- Additional comment from mjd-redhat@afork.com on 2006-11-12 22:00 EST --
This is not about overriding Space as I don't want to change Space's function. 
I'm talking about what Enter does.

I'm proposing that Enter does a commit in addition to space, because the present
behaviour of Enter is not useful to anyone and violates the Principle of Least
Surprise.

Comment 1 Jens Petersen 2006-11-20 00:32:51 EST

We need to consider very carefully whether making such a change in
UI behaviour is a good for most Chinese users.

Comment 2 Peng Huang 2006-11-20 01:22:56 EST

I think different input methods have different keys layout. Scim input table
engine provides a way for developer to configure keys in the table when
developing. In the table, there are many KEYS can be configured, like
SPLIT_KEYS, COMMIT_KEYS, FORWARD_KEYS, SELECT_KEYS, PAGE_UP_KEYS,
PAGE_DOWN_KEYS, MODE_SWITCH_KEYS, FULL_WIDTH_PUNCT_KEYS and
FULL_WIDTH_LETTER_KEYS. If we add configure UI for all keys, it's too complex
for users. It will make users feeling chaos. It's not easy for using. I think
the good way is setting the keys correctly in developing time and keep the
system simple. We need not make all input methods have the same commit key. They
can be different, like famous Wubi in Windows use space key as commit key, so
Wubi in the Linux should respect Wubi users' habit. Maybe Japanese users like
return key as commit, we could configure Japanese table fellow Japanese's habit.
I think it makes sense.

Comment 3 Jens Petersen 2006-11-20 23:13:25 EST

Closing based on preceding comment.

Comment 4 Peng Huang 2006-11-21 03:15:33 EST

*** Bug 214955 has been marked as a duplicate of this bug. ***