Last modified: 2014-10-07 12:56:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T52631, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 50631 - VisualEditor: CE eats up syllables except a last syllable of a word in Korean IME
VisualEditor: CE eats up syllables except a last syllable of a word in Korean...
Status: ASSIGNED
Product: VisualEditor
Classification: Unclassified
Language (Other open bugs)
unspecified
All All
: High major
: ---
Assigned To: Editing team bugs – take if you're interested!
: i18n
Depends on: 57290
Blocks: ve-multi-lingual
  Show dependency treegraph
 
Reported: 2013-07-03 01:34 UTC by Ryu, Cheol
Modified: 2014-10-07 12:56 UTC (History)
16 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ryu, Cheol 2013-07-03 01:34:44 UTC
Korean input is not complete. 

I tried to input "한글 시험 합니다.". 
But it eats up some letters and produce "글 험 다.".

I tested with Chrome and Safari on Mac OSX. And it is all the same with Chrome on Windows XP.
Comment 1 Revi 2013-07-03 03:52:19 UTC
It also comes to Chrome on Win7.
Comment 2 Ed Sanders 2013-07-04 19:15:35 UTC
David and I may take a look at this over a cocktail.
Comment 3 Ed Sanders 2013-07-04 20:35:05 UTC
This looks quite a lot like an IME issue (at least with iBus Korean).
Comment 4 Ed Sanders 2013-07-04 22:11:38 UTC
Trying to type into an empty/slug paragraph causes all sorts of whacky behaviour and should probably be filed as a separate bug

The latin text in iBus Korean is:

gks rmf [SPACE] tl gja [SPACE] gkq sl ek

Typing just "gksr" the following events are fired:

compositionstart
g,k,s
compositionend
compositionstart
r
compositionend

with the final compositionend causing the second Hangul character to end prematurely.

Need to investigate if this a browser bug related to IME's which allow continuous typing across graphemes.
Comment 5 D Chan 2013-07-04 23:51:09 UTC
(In reply to comment #4)
> The latin text in iBus Korean is:
> 
> gks rmf [SPACE] tl gja [SPACE] gkq sl ek
> 
> Typing just "gksr" the following events are fired:
> 
> compositionstart
> g,k,s
> compositionend
> compositionstart
> r
> compositionend


I'm seeing slightly different behaviour on Chromium 25.0.1364.160-0ubuntu0.12.04.1 using ibus 1.4.1-3ubuntu1 and ibus-hangul 1.3.1-3build1.

If I start with an almost blank document (just the letter "A" with the cursor immediately after), then I can type "gksrmf tlgja gkqslek" and get exactly the expected characters ""한글 시험 합니다". The event sequence is as it should be (with the second compositionend only happening when I hit space).

However, if I then type the full stop, it goes *after* the cursor.
Comment 6 Ryu, Cheol 2013-07-05 06:20:32 UTC
This was feed backed to 
http://www.mediawiki.org/w/index.php?title=Thread:VisualEditor/Feedback/i_can%27t_type_a_east_asian_character

If you cannot resolve the problem in time, we'd better postpone the deployment on Korean Wikipedia or other Korean projects.
Comment 7 Ed Sanders 2013-07-05 11:48:45 UTC
Yes, lack of reliable IME support would be a show-stopper.
Comment 8 DangSunM 2013-07-13 00:37:57 UTC
I also tried to write some Korean words using visual editor
" 시 각 편 집 기 테 스 트 근데 잘 안되"
but it types 
" 시 각 편 집 기 테 스 트 근데 잘 안되 되도안아잘자ㅈ데근ㄱ트스ㅋ크스ㅅ테ㅌㅍ페기집지편펴가" see http://ko.wikipedia.org/w/index.php?title=%EC%82%AC%EC%9A%A9%EC%9E%90%3A%EB%B6%84%EB%8B%B9%EC%84%A0M&diff=11132326&oldid=11087937 for details
Comment 9 Ryu, Cheol 2013-07-14 02:02:42 UTC
I think VE team is working on this issue. Did you change the code related this?
I think so.
DangSunM's report is not what I got when I made the first report.

Now I tested on Chome of iPad. It is different also.
I input '한글 시험 합니다.', same as previous.
And now I have '한글 싷험 합닏다.', like the think 
http://en.wikipedia.org/w/index.php?title=User:Ryuch&curid=284811&diff=564158229&oldid=554104287
.

It duplicates the begining consonant of a syllable to the place of ending consonant of a syllable just before it in a word when the ending consonant is null.
Comment 10 Ellif d.a 2013-07-20 01:23:19 UTC
Now the problem seems something changed, but It is yet hard.

I input '한글 결과는 언제 나오나요'

but in the en wikipedia's visual editor @ chrome ,
it have 'ㄱㅡㄹ ㅏㄴㄴ 제 오요나나제언ㅇㅏ결겨ㄱㅡ'.

See http://en.wikipedia.org/w/index.php?title=User:Galadrien/sandbox&diff=564998163&oldid=549762292 .
Comment 11 Ryu, Cheol 2013-08-09 15:46:56 UTC
You fixed this? It works.

http://en.wikipedia.org/w/index.php?title=User%3ARyuch&diff=567832037&oldid=567831839

I tested with Chrome on Ubuntu at this moment.
Comment 12 Revi 2013-08-09 17:05:11 UTC
It also works on Chrome for WinXP/Win7/Android(though it is not supported).
Comment 13 Ed Sanders 2013-08-09 17:44:43 UTC
@Ryu not deliberately! Come to the VE lounge tomorrow (hackathon room) and speak to me and David.
Comment 14 Ryu, Cheol 2013-08-09 22:04:08 UTC
awesome. anyway.
Please make it opt-in on KOWP.

I will catch you guys at the lounge.
Comment 15 Ryu, Cheol 2013-08-15 08:00:11 UTC
==Test Cases==

글험 합니다. 다닏ㄴ합하험허시ㅅ (2013.8.14, Chrome of Windows XP)

글 험 다. (2013.8.14, Chrome of Mac OS X)

한글 시험 합니다. (2013.8.14, Chrome of Ubuntu, iBus 1.4.1)
Comment 16 D Chan 2013-08-19 18:15:41 UTC
I believe the following patch resolves the problem on those platforms where there still was one: https://gerrit.wikimedia.org/r/#/c/79451 . At least, the patch seems to fix the Korean ibus method on Ubuntu+Chromium. However it's hard to be sure because of the problems reproducing the bug.
Comment 17 Gerrit Notification Bot 2013-08-20 19:41:01 UTC
Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
Comment 18 Gerrit Notification Bot 2013-08-22 09:48:54 UTC
Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080
Comment 19 James Forrester 2013-08-22 20:12:46 UTC
Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!
Comment 20 Ellif d.a 2013-08-22 21:10:09 UTC
Sorry, but If you applied it on en.wikipedia. it yet not fixed.
Comment 21 Ed Sanders 2013-08-22 21:18:05 UTC
No, it hasn't been deployed to en.wiki yet.
Comment 22 Ellif d.a 2013-08-22 21:21:35 UTC
We can check on en.wikipedia or ko.wikipedia, only,
if the problem fixed.

So can you apply it on there?
Comment 23 Ed Sanders 2013-08-22 21:28:26 UTC
Yes. All code in master is eventually deployed during our scheduled deployments. If you want to test the code ahead of the deployment you will have to check it out locally.
Comment 24 James Forrester 2013-08-22 21:44:57 UTC
(In reply to comment #22)
> We can check on en.wikipedia or ko.wikipedia, only,
> if the problem fixed.
> 
> So can you apply it on there?

The code will be applied as part of the normal MediaWiki release cycle, which you can see here: [[mw:MediaWiki_1.22/Roadmap#Schedule_for_the_deployments]].

This code is tagged against the release that happened this morning ("wmf14") - this means that the code is available now on MediaWiki.org, and will be available on all Wikipedias (including the English and Korean Wikipedias) next Thursday, 29 August, at approximately 18:00 UTC.

If you want to test and confirm the code, you can edit pages on MediaWiki.org like [[mw:VisualEditor:Test]]. Also, all code is immediately available on the "Beta labs" testing site, which can also be edited (note that it uses a different account system to production "real" Wikipedias): http://en.wikipedia.beta.wmflabs.org/wiki/VisualEditor 

Hope this helps!
Comment 25 Ryu, Cheol 2013-08-26 07:13:55 UTC
(In reply to comment #16)
> I believe the following patch resolves the problem on those platforms where
> there still was one: https://gerrit.wikimedia.org/r/#/c/79451 . At least, the
> patch seems to fix the Korean ibus method on Ubuntu+Chromium. However it's
> hard
> to be sure because of the problems reproducing the bug.

David,

https://gerrit.wikimedia.org/r/#/c/79451 did not fix the problem even Chrome on Ubuntu, if the code is applied to MediaWiki.org as James said.

I found another thing, when the cursor is after Korean letters backspace does not work.
Comment 26 Andre Klapper 2013-08-26 09:23:16 UTC
(In reply to comment #25)
> https://gerrit.wikimedia.org/r/#/c/79451 did not fix the problem

Just to avoid misunderstandings: How did you test this? Do you run a private wiki with recent VisualEditor from git master?

> I found another thing, when the cursor is after Korean letters backspace does
> not work.

Please file separate bug reports for separate issues. Thanks! :)
Comment 27 Ryu, Cheol 2013-08-26 09:49:39 UTC
(In reply to comment #26)
> (In reply to comment #25)
> > https://gerrit.wikimedia.org/r/#/c/79451 did not fix the problem
> 
> Just to avoid misunderstandings: How did you test this? Do you run a private
> wiki with recent VisualEditor from git master?

Not on a private one, I ran on  MediaWiki.Org, specifically on  [[mw:VisualEditor:Test]].



> 
> > I found another thing, when the cursor is after Korean letters backspace does
> > not work.
> 
> Please file separate bug reports for separate issues. Thanks! :)

I think the space problem is caused by this bug. I suppose we need to fix error  of synchronization between DM and CE.

Thank you, too.
Comment 28 D Chan 2013-09-11 23:45:35 UTC
There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!
Comment 29 James Forrester 2013-09-12 04:07:59 UTC
Marking this as "FIXED" on the expectation that it's fixed - please re-open if you find that it is still occurring.
Comment 30 Ryu, Cheol 2013-09-25 01:46:32 UTC
(In reply to comment #29)
> Marking this as "FIXED" on the expectation that it's fixed - please re-open
> if
> you find that it is still occurring.

I am sorry. It is not fixed.  I tested on mediawiki.org.

I open it again.
Comment 31 James Forrester 2013-09-25 01:54:02 UTC
(In reply to comment #30)
> (In reply to comment #29)
> > Marking this as "FIXED" on the expectation that it's fixed - please re-open
> > if
> > you find that it is still occurring.
> 
> I am sorry. It is not fixed.  I tested on mediawiki.org.

:-(

> I open it again.

OK, we'll look at it urgently. Sorry for this.
Comment 32 heesub 2013-09-28 17:15:34 UTC
I am suffering from this issue, tested on the latest version from mediawiki's core.git: 217fd43. The odd thing is that it seems to work properly on Firefox which comes with Ubuntu 13.04 LTS distribution(, but not perfectly).

I've tried:
* IE on Windows 7 : not working
* Google Chrome on Windows 7 : not working
* Google Chrome on Ubuntu 13.04 : not working
* Safari on Mac OSX 10.8.5: not working
* Google Chrome on Mac OSX 10.8.5: not working
* Firefox on Ubuntu 13.04 : WORKING

I hope this information help you guys so that it gets fixed.
Comment 33 heesub 2013-09-28 17:41:42 UTC
(In reply to comment #32)
> I am suffering from this issue, tested on the latest version from mediawiki's
> core.git: 217fd43. The odd thing is that it seems to work properly on Firefox
> which comes with Ubuntu 13.04 LTS distribution(, but not perfectly).

I'd tested on VisualEditor.git: cba2935 and also with patchset v16 by David Chan. Not fixed.
Comment 34 James Forrester 2013-10-08 21:36:00 UTC
Would it be possible to test against current master? We believe that we have fixed this (or, at least, change the behaviour) since you tested it with cba2935 (thank you!).
Comment 35 heesub 2013-10-09 05:47:38 UTC
(In reply to comment #34)
> Would it be possible to test against current master? We believe that we have
> fixed this (or, at least, change the behaviour) since you tested it with
> cba2935 (thank you!).

I've tested the latest version and uploaded a video clip which shows what is happening on VisualEditor with Korean characters. You can find the video on this link: http://youtu.be/-Q8n4vNONm0

I am not a JavaScript or web programming expert, it seems that every browser out there has different behaviors on firing and processing compositionStart/End and keyDown events. Take a look at this document: http://joone4u.blogspot.kr/2010/07/composition-events-are-handled_27.html

After digging this issue, I found some combinations which avoid this issue:
 - Safari, Google Chrome (maybe every other browsers, but not tested) on Mac OS X. and change preference settings of Korean IME: set 'Input by' to 'Word' not 'Syllable' which is default.
 - Firefox on Ubuntu

Hope this helps!
Comment 36 D Chan 2013-10-09 21:25:45 UTC
Thanks very much for the video -- that's a great help!

I agree about the events. Actually I think it's every browser/OS/IME combination, so it's really troublesome.

As far as I can tell, there are actually two issues at the moment:

(1) Entering Korean text into an empty paragraph, and
(2) Entering Korean text into a non-empty paragraph.

Your video shows that case (1) is still broken. In order to test (2), would it be possible to try typing "hello", and then start typing Korean immediately after the "o" (i.e. without starting a new line/paragraph)?

I have done these sorts of tests, but I can't reproduce the behaviour you show in the video, presumably because of some slight difference between our test platforms.

Thanks again!
Comment 37 Revi 2014-09-14 13:24:50 UTC
I tried VE in [[en:User:Hym411/VETest]] with VE betafeatures enabled;

Input: "구글 크롬 안드로이드용 최신 버전"

Output: See the page above. - "국글 클롬 안들롱읻등용 쵯신 벚전"

I used latest release of Google Chrome for Android.

Also, comment 25 's 'backspace does not work' still happens to me.

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


Navigation
Links