I found that this problem can be solved when gedit or evolution is started like
GTK_IM_MODULE=scim gedit
or
GTK_IM_MODULE=scim evolution

NOTE:- Sinhala community requested to add si-wijesekera.mim in m17n-db-sinhala
package. Currently we are manually removing it in SPEC. 
   Changes need to test si-wijesekera.mim on rawhide is to 
1)mv /usr/share/m17n/si-wijesekera.mim  /usr/share/m17n/si-wijesekera-preedit.mim
2)open /usr/share/m17n/si-wijesekera-preedit.mim and replace line
(input-method si wijesekera)
to
(input-method si wijesekera-preedit)
3) manually copy si-wijesekera.mim to /usr/share/m17n/ from upstream tarball
http://www.m17n.org/m17n-lib-download/m17n-db-1.5.1.tar.gz
4) then scim-restart
5) use testcase given in initial comment.

Could attach some screenshot for this bug? Thanks.

Created attachment 296723 [details]
sinhala-testcase-incorrect-rendering.png

incorrect rendering with sinhala keymaps when started gtk application without 
GTK_IM_MODULE=scim

Created attachment 296724 [details]
sinhala-testcase-correct-rendering.png

correct rendering with sinhala keymaps when started gtk application with
GTK_IM_MODULE=scim

Phuang,
 sorry for step1 in comment#2 it should be
1)mv /usr/share/m17n/si-wijesekera-preedit.mim  /usr/share/m17n/si-wijesekera.mim

Created attachment 296988 [details]
modified si-wijesekera-preedit.mim

Created attachment 296989 [details]
modified si-wijesekera.mim

And this used to work for some older versions of scim-bridge, is that right?

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

Ping Parag

Parag?

requested by Jens Petersen (#27995)

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

scim-bridge and ibus do not support surrounding-text.  We should probably clone a bug for ibus.

Hash, could you give some explicit examples/testcases to better understand the problem, please?

Hi Jens,

Sinhala input using the Wijesekera keyboard layout involves typing in decomposed form and storing in composed form. Typing A, B, C, D would be stored as B, E where E is the composed form of A, C, D. When editing the document, after the buffer has been committed, backspace should delete the letters in reverse decomposed order. i.e. D, C, B, A.

Example A:
1) <f><l><d><a> should output කෝ.
2) Press the space bar to commit the buffer.
3) Press the backspace key 4 times. 
4) The remaining output should be ෙ .

Example B:
1) <f><l><d><a> should output කෝ.
2) Press the space bar to commit the buffer.
3) Press the backspace key 3 times
4) Prease <a>
5) The remaining output should be කේ.

cya,
#

my comments on bug summary

> Additional info:
> Test cases
> a)Select m17n si-wijesekera (non-preedit):
>  1)TYPE: fkda (incorrect): ෙනා්

I tested in both scim as well in ibus

This is happening since si-wijesekera (non-preedit) doesnt have any intelligence inbuild. It is not doing any reordering (like it is happening w-preedit version, i think its pushback method pushing k first)

therefore si-wijesekera (non-preedit) giving fkda as it is for rendering.
fkda = U+0dd9 U+0db1 U+0dcf U+0dca

and it is providing above result as U+0dd9 is matra and should be after consonant

> > a)Select m17n si-wijesekera (preedit):
>  2)TYPE: fkda (correct): නෝ

here preedit one doing reordering before giving ip to renderer,
so fkda is getting converted into 
fkda = U+0dd9 U+0db1 U+0dcf U+0dca

is converted into

kfda = U+0dd9 U+0ddd  and giving correct o/p


one can verify same by giving 
fkda or kfda to w-preedit it will give same o/p

while giving both to w-non-preedit will give different o/p since no reordering is happening there

so IMHO whatever is happening is correct and working as per rules written in mim file, there is nothing to do with surrounding text.

(In reply to comment #18)
> Hi Jens,
> 
> Sinhala input using the Wijesekera keyboard layout involves typing in
> decomposed form and storing in composed form. Typing A, B, C, D would be stored
> as B, E where E is the composed form of A, C, D. When editing the document,
> after the buffer has been committed, backspace should delete the letters in
> reverse decomposed order. i.e. D, C, B, A.

yeah, as you written

here input method is intelligent and reordering input given by user as per required by rendered (sometime its bit easy to writing for user )
so ABCD is getting converted into BACD  (ACD = E)
so its BE

so here actual we see after preedit commit is BE
and while back spacing, since backspace is working on committed thing i.e

BE decomposed BACD , its first deleting D then C then A, and we are getting remaining thing is B same in example its consonant U+0d9a

so whatever happening is right

if input method give i/p as it is to renderer then it will produce wrong o/p.

Reassigning to Hash who are volunteered to work on this in his spare cycles. :)

(In reply to comment #19)

Hello, this is the upstream.

> I tested in both scim as well in ibus

> This is happening since si-wijesekera (non-preedit) doesnt have any
> intelligence inbuild. It is not doing any reordering (like it is happening
> w-preedit version, i think its pushback method pushing k first)

I assure you, Jens.  si-wijesekera (non-preedit) DOES reordering using surrounding text.  Try to use scim-gtk, which supports surrounding text, instead of scim-bridge, which doesn't.

I think there is need to improve bug summary

xx combinatoin working in scim with surrounding text and same not working in ibus i.e (if possible screen shot)

> I assure you, Jens.  si-wijesekera (non-preedit) DOES reordering using
> surrounding text.  Try to use scim-gtk, which supports surrounding text,
> instead of scim-bridge, which doesn't.  

Yep :)

Takahashi-san, is there any way that si-wijesekera.mim and si-wijesekera-preedit.mim could be merged?

> Takahashi-san, is there any way that si-wijesekera.mim and
> si-wijesekera-preedit.mim could be merged?  

I think I can do it.  I am rather busy now, so I will put it on my todo list.  Give me some time.

(In reply to comment #25)
I have merged si-wijesekera.mim and si-wijesekera-preedit.mim.  The new si-wijesekera.mim checks whether surrounding text is supported or not.
Please check the CVS version in various environments.

Note that some applications may answer "yes" to the above-mentioned check although they do not support surrounding text.  For this reason, surrounding text support is disabled in ta-lk-renganathan.mim although it works both in preedit mode and in surrounding text mode.

Hi Takahashi,

What are the applications that claim to support surrounding text even when they do not?

cya,
#

(In reply to comment #27)

> What are the applications that claim to support surrounding text even when they
> do not?

Iceweasel 3.0.12 is one of them.  Qt applications and Evolution were also reported to return a false answer, at least in 2008.  Openoffice and GTK applications seem to work fine.

(In reply to comment #26)
> I have merged si-wijesekera.mim and si-wijesekera-preedit.mim.  The new
> si-wijesekera.mim checks whether surrounding text is supported or not.

Thank you very much that is great news! :)

I did a quick test of the merged wijesekera file using scim-gtk (up-to-date F11) and typed the keys "fkda":

gedit (GTK): detected
lyx (QT): detected
oowriter: detected
firefox: not detected
evolution (TO/SUBJECT): detected
evolution (message pane): not detected (strange/unpredictable behaviour)

* "detected" means that the input string was displayed correctly. i.e. The input string should trigger surrounding text support.
* "not detected" means that the input string was displayed incorrectly. i.e. The application presumably claimed to support surrounding text but actually did not.

(In reply to comment #26)

Hi Takahashi,

> Note that some applications may answer "yes" to the above-mentioned check
> although they do not support surrounding text.  For this reason, surrounding
> text support is disabled in ta-lk-renganathan.mim although it works both in
> preedit mode and in surrounding text mode.  

Thanks for merging the two MIM files into one, it will make it easier for the end users. I've given this some thought, could you please disable surrounding text support for the merged Wijesekera MIM too? Otherwise it will cause too much confusion when the displayed output on some applications are unpredictable. We can re-enable it when surrounding text support is advertised correctly. Also, you may want to delete the preedit version. Having only one Wijesekera MIM will make it easier for the end users.

Thanks,
#

(In reply to comment #31)

> Thanks for merging the two MIM files into one, it will make it easier for the
> end users. I've given this some thought, could you please disable surrounding
> text support for the merged Wijesekera MIM too?

> Also, you may want to delete the preedit version. 

Both done.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I guess this was already fixed in upstream right?
Closing as CURRENTRELEASE

oops I thought its still asking for scim.
Let me re-open this.

Can we have again what things need to be fixed here?

The current status is that si-wijesekera.mim has been modified by Takahashi to
not require surrounding text support. Which addresses this particular bug.
AFAIK, IBus still does not support surrounding text.

Assigning to Ueno-san who has been doing some work on this I believe.

That's good news! I'll be happy to test surrounding text support once it is in IBus.

FYI, I recently posted patches for ibus & ibus-m17n to:

http://code.google.com/p/ibus/issues/detail?id=778

Harshula and Takahashi-san, could you test these patches when you have time?  I'm not familiar with languages in which surrounding-text is worth supporting.  If they are usable, I'll ask ibus & ibus-m17n upstream to include them in the future releases.

Hi, Any chance you could build some test RPMs that include your patches?

OK, just put the RPMs:

http://ueno.fedorapeople.org/ibus-surrounding-text/

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

It seems there is a patch.
Transferring to the engineer.

Hi, I tested the ibus & ibus-m17n RPMs with gedit and oowriter using the si-wijesekera.mim layout (first enabling the surrounding text check in the MIM file). The quick test showed that surrounding text support was active and seemed to be working well.

I talked this problem with the maintainers.
The suggestion is to use preedit instead of surrounding.
Currently CJK input method engines uses preedit. If other engines could move to preedit feature, it would reduce the significant developments/maintenance costs.

There are some concerns to support the surrounding feature.
 - like xim, and some widgets may not support surrounding text
 - It is difficult to sync the surrounding text between application and engine
As you know, in ibus, many messages are async

All the fix could be resolved in each engine with this suggestion.

I would like to know if the preedit approach is acceptable for native speakers of languages in which surrounding-text is desired, including Sinhala, Thai, Korean, and Vietnamese.

I guess Vietnamese users are fine with the preedit approach since in that language each word is seperated by spaces and that can be used as a trigger of preedit commit.

However, Sinhala/Thai/Korean have no such rule (i.e. they are agglutinative languages) and users need to type extra Return to commit the preedit.

Harshula and Takahashi-san, any thoughts?

Hi,

I appreciate that Input Method design and implementation is CJK centric for various reasons. Pre-edit is a viable workaround till surround text support can be enabled. In my view, surrounding text support MUST be enabled eventually. A Wijesekera keyboard layout using pre-edit can result in unexpected encoding errors when editing an existing text in a document. A non-technical user will be very confused by such errors.

I suggest surrounding text support be a tick-box option in IBus/engine preferences which is turned-off by default till the infrastructure components improve.

BTW, in modern Sinhala, words are also separated by a space. The problem is once the buffer has been committed and a user goes to edit a syllable. e.g. a syllable "koo" might need to be changed to "kee" and should require only two backspaces and al-lakuna key presses. But without surrounding text support you need 4 backspaces followed by 3 more key presses. The worst case scenario is if the user does the logical set of steps (2 backspaces and 1 al-lakuna) it will result in an encoding error.

Regards,
Harshula

I also believe surrounding text shall be supported eventually.

Some input methods lets you type characters in the order "as you handwrite"; those input methods reorder the input characters when they are committed to satisfy the Unicode character order specification.

If you use such input methods with preedit, you may need to behave differently to change the same string, depending on whether it has already been committed or not.  This is an confusing situation.

Thanks for the comments.

(In reply to comment #49)
> BTW, in modern Sinhala, words are also separated by a space. The problem is
> once the buffer has been committed and a user goes to edit a syllable. e.g. a
> syllable "koo" might need to be changed to "kee" and should require only two
> backspaces and al-lakuna key presses. But without surrounding text support you
> need 4 backspaces followed by 3 more key presses. The worst case scenario is if
> the user does the logical set of steps (2 backspaces and 1 al-lakuna) it will
> result in an encoding error.

In preedit, I would expect not to use any backspace keys if you need to change "koo" to "kee". I feel it would be one space and enter key.
It would be great if you could explain why it's important to support the already committed text since I don't identify the usage to the actual hand-writing.

In the preedit mode, I mean preedit buffer would be similar to the writing mode. Once the text is committed in preedit mode, using backspace keys on computer could be similar to using an eraser on paper.
So if you try to modify the already committed text in surrounding mode, it would be similar to using an eraser on paper to me.

(In reply to comment #50)
> If you use such input methods with preedit, you may need to behave differently
> to change the same string, depending on whether it has already been committed
> or not.  This is an confusing situation.

The previous suggestion means to support the previous chars belonged to a word without supporting already committed text.
It would be great if you could explain why it's important to support the already committed text since I don't identify the usage to the actual hand-writing.

Hi,

I was pointed to this bug where surrounding text support is being discussed. I'd say the most natural Thai input method needs surrounding text support. Other existing approaches appear not smooth to Thai users, such as preediting in some recent scim-m17n, or plain table lookup in scim-table.

Thai input method may be less complicated than that of Indic scripts because Thai is not encoded in the so-called 'logical order', but it requires sequence validation. When editing already committed text, the new input character must be validated with the current text whether it's composible.

Note that while Thai encoding scheme is closer to Latin than Indic, its combining characters are never composed into pre-composed forms. They are encoded in separation from the base characters. And only limited number and order of combining characters are allowed. Some rules have been defined as described in [1]. So, the committed text is still open for editing just like when it's in preedit stage. No difference. And thus surrounding text support is required to determine the validity of the input character, or even to modify the surrounding text to let it in in some implementations.

[1] http://linux.thai.net/~thep/th-xim/

(In reply to comment #51)
> In preedit, I would expect not to use any backspace keys if you need to change
> "koo" to "kee". I feel it would be one space and enter key.

I do not see how "one space and enter key" changes "koo" into "kee".

If you are using si-wijesekera in the preedit mode, you type "flda" to get the "koo" syllable in the preedit buffer.  To change this "koo" into "kee" before committing it, you type BS, BS, "a".  The first BS changes "koo" into "ko" and the second BS changes "ko" into "ke".  Then the "a" key changes "ke" into "kee".

On the other hand, when you change an already committed "koo" into "kee", you first move the cursor after the "koo" and type BS, BS, "fla".  The first BS changes "koo" into "k" and the second BS removes the syllable entirely.  Then the key sequence "fl" inserts a new "ke" and the final "a" changes that "ke" into "kee".

I recommend you to type the above sequences in gedit to see how "koo", "kee", etc. are represented in Sinhala.

> The previous suggestion means to support the previous chars belonged to a word
> without supporting already committed text.

Sorry, I do not understand this sentence.

> It would be great if you could explain why it's important to support the
> already committed text since I don't identify the usage to the actual
> hand-writing.

As I described above, the key sequence to change "koo" into "kee" is different for the preedit buffer and for committed text.  Don't you think it is confusing?

(In reply to comment #51)

> In preedit, I would expect not to use any backspace keys if you need to change
> "koo" to "kee". I feel it would be one space and enter key.
> It would be great if you could explain why it's important to support the
> already committed text since I don't identify the usage to the actual
> hand-writing.

I already explained this 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=435880#c18

(In reply to comment #53)
> (In reply to comment #51)
> > In preedit, I would expect not to use any backspace keys if you need to change
> > "koo" to "kee". I feel it would be one space and enter key.
> 
> I do not see how "one space and enter key" changes "koo" into "kee".
> 
> If you are using si-wijesekera in the preedit mode, you type "flda" to get the
> "koo" syllable in the preedit buffer.  To change this "koo" into "kee" before
> committing it, you type BS, BS, "a".  The first BS changes "koo" into "ko" and
> the second BS changes "ko" into "ke".  Then the "a" key changes "ke" into
> "kee".
> 
> On the other hand, when you change an already committed "koo" into "kee", you
> first move the cursor after the "koo" and type BS, BS, "fla".  The first BS
> changes "koo" into "k" and the second BS removes the syllable entirely.  Then
> the key sequence "fl" inserts a new "ke" and the final "a" changes that "ke"
> into "kee".

Thanks for that practice.
Actually I also would think that usage but I could not explain the key type
because I don't know that key sequence itself. The my point was that it might
be possible to cover the surrounding feature with preedit or something.
I.e. an engine could remember the previous key sequences 'flda' and if you type
BS, BS, 'a', the engine could output the right word for 'fla'.

The point was, if you need two BS keys and al-lakuna key with surrounding, it
would be replaced with the same way with preedit or something.

> 
> I recommend you to type the above sequences in gedit to see how "koo", "kee",
> etc. are represented in Sinhala.
> 
> > The previous suggestion means to support the previous chars belonged to a word
> > without supporting already committed text.
> 
> Sorry, I do not understand this sentence.

I mean to support the word sequences only before you commit the word but not
support to modify the already committed sentence.
E.g. above preedit feature could be applied to the modifying the text before
the text is committed. But it's not applied to already committed text.
But I would think a reconvert feature with preedit also could convert the
already committed text.

Hope somebody could reply my question.
> > It would be great if you could explain why it's important to support the
> > already committed text since I don't identify the usage to the actual
> > hand-writing.
>

(In reply to comment #55)

> I.e. an engine could remember the previous key sequences 'flda' and if you type
> BS, BS, 'a', the engine could output the right word for 'fla'.

Imagine the following situation.  You write a message in Sinhala that contains "koo" and send it to me by email.  I read it want to change the "koo" to "kee".  How can my IM understand the the existance of the "koo" syllable without surrounding text support?

(In reply to comment #55)
> The point was, if you need two BS keys and al-lakuna key with surrounding, it
> would be replaced with the same way with preedit or something.

I think the current BS behaviour under Wijesekera is considered
optimal for users and the same behaviour is desired when editing
committed text and that could be provided by surrounding text.

> But I would think a reconvert feature with preedit also could convert the
> already committed text.

Interesting idea - that might help, but probably users prefer not
to leave the keyboard just to edit committed text.

> Hope somebody could reply my question.
> > > It would be great if you could explain why it's important to support the
> > > already committed text since I don't identify the usage to the actual
> > > hand-writing.

I think some came up earlier: avoiding illegal text sequences from
partial deletion of text, consistency of BS and input behaviour and
avoiding the need for preedit, I think.

(In reply to comment #56)
> > I.e. an engine could remember the previous key sequences 'flda' and if you type
> > BS, BS, 'a', the engine could output the right word for 'fla'.
> 
> Imagine the following situation.  You write a message in Sinhala that contains
> "koo" and send it to me by email.  I read it want to change the "koo" to "kee".
>  How can my IM understand the the existance of the "koo" syllable without
> surrounding text support?

I would expect it's same with Japanese. You erase the words and type "kee" again.
In CJK, Once you committed a string on computer, modifying the string would mean to erase some chars with BS and type a new word.
In CJK, Once you write a string on paper, modifying the string would mean to erase some chars with an eraser and type a new word.
They are same behavior between computer and paper in CJK. I would guess it's also true in Indic.
Why do you need the different behavior using surrounding on computer in Indic?
In CJK, users would not feel a stress without covering that case.

Or I would think a reconvert feature with preedit to satisfy that usage.
I would think it might be a kind of workaround but that's why I ask the reason:
Hope somebody could reply my question.
> > It would be great if you could explain why it's important to support the
> > already committed text since I don't identify the usage to the actual
> > hand-writing.

(In reply to comment #57)
> > The point was, if you need two BS keys and al-lakuna key with surrounding, it
> > would be replaced with the same way with preedit or something.
> 
> I think the current BS behaviour under Wijesekera is considered
> optimal for users and the same behaviour is desired when editing
> committed text and that could be provided by surrounding text.

Hmm.., I would expect the input way is same between preedit(or something) and surrounding in this case.
In this case, I don't suppose the already committed text.
I don't think the current implementation of m17n and probably would need furthermore developments but would not effect ibus.

> I think some came up earlier: avoiding illegal text sequences from
> partial deletion of text, consistency of BS and input behaviour and
> avoiding the need for preedit, I think.

Yes, I also would think those cases however my question means why that usages are important?
In CJK, if a string is committed, we use BS to erase chars and general users don't feel stress without surrounding because that way would be similar to the hand-writing on paper.

(In reply to comment #58)
> In CJK, Once you committed a string on computer, modifying the string would
> mean to erase some chars with BS and type a new word.
> In CJK, Once you write a string on paper, modifying the string would mean to
> erase some chars with an eraser and type a new word.
> They are same behavior between computer and paper in CJK. I would guess it's
> also true in Indic.
> Why do you need the different behavior using surrounding on computer in Indic?

Because Sinhala users requested that.  So did Tamil users.

> Or I would think a reconvert feature with preedit to satisfy that usage.

Would you elaborate on that point?

> Hmm.., I would expect the input way is same between preedit(or something) and
> surrounding in this case.

Exactly.

> > I think some came up earlier: avoiding illegal text sequences from
> > partial deletion of text, consistency of BS and input behaviour and
> > avoiding the need for preedit, I think.

> Yes, I also would think those cases however my question means why that usages
> are important?

Only Sinhala users can answer that question.  Unfortunately, I am not.

OK, thanks for the discussion. Probably we could get a bunch of opinions.
I'll return to this bug again after I talk with upstream maintainers again (maybe today or tomorrow).

It may be good to know other platforms, e.g. MS-Windows.

Created attachment 446824 [details]
Patch for ibus-m17n engine.c

http://github.com/fujiwarat/ibus/commit/ddc1242bf37ac525faaec57bd8c22214044ec5ab

Revised the patches:
 - ibus surrounding-text is enabled when only when ibus_engine_retrieve_surrounding_text() is called.
 - Moved internal struct members from ibus to ibus-m17n

As we discussed last week, The IBus maintainer agreed with having surrounding-text feature in IBus.

Now probably it's good to have the ability in f14.
I'm thinking which patch is better for Fedora feature patches as we would think the current patch could be enhanced in the future.
The above patch would be a suggestion from mine.

Added the scratch build for ibus:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2463589

Today I had a chance to talk about my patch.
My patch would have a potential problem when the machine resources are tight since it would depend on the async functions as I don't see any actual problems in my test.

If we will fix my concerns, probably the use of ibus capability would be a solution.
Probably it could be enhanced later so currently I'm thinking to integrate Ueno-san's patch.

Integrated the ibus patch into f14:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2465882

Currently I won't integrate it into f13 until va_list issue is fixed.
http://koji.fedoraproject.org/koji/taskinfo?taskID=2465786

Python update

f14:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2466580

f13 scratch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2466544

ibus-m17n-1.3.1-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ibus-m17n-1.3.1-2.fc14

ibus-m17n-1.3.1-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ibus-m17n'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ibus-m17n-1.3.1-2.fc14

ibus-m17n-1.3.1-3.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ibus-m17n-1.3.1-3.fc14

ibus-m17n-1.3.1-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/ibus-m17n-1.3.1-4.fc14

ibus-m17n-1.3.1-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.