[Fedora-i18n-bugs] [Bug 435880] [si_LK] ibus-gtk requires surrounding-text support for si-wijesekera.mim

bugzilla at redhat.com bugzilla at redhat.com
Tue Aug 24 01:49:50 UTC 2010

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


--- Comment #55 from fujiwara <tfujiwar at redhat.com> 2010-08-23 21:49:49 EDT ---
(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.

Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the i18n-bugs mailing list