Home/ Questions/Q 8646681
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T12:52:36+00:00

I am working on a jQuery plugin for converting Latin characters to Japanese kana

  • 0

I am working on a jQuery plugin for converting Latin characters to Japanese kana symbols (live example) in real-time (auto-correct) and it works correctly if I’m not typing too fast.. Which is a problem.

For example:

wakarimasu -> わかります

However, when I type at my normal speed I get this:

wakarimasu -> わかりあすm (which is actually wakariasum, cursor between “す” and “m” in the end)

If I type it without “su”, I get this:

wakarima -> わかりあm (which is actually wakariam, cursor between “あ” and “m” in the end)

I figured out why and how this is happening. Basically, “ri – り” symbol is still converting from Latin to Japanese kana while I already typed “m” in and it finishes just a little bit before I manage to type “a” in. Since my function positions the cursor after each conversion, it positions the cursor between “ri” and “m” and that is where my “a” ends up.

This happens for other words as well, but I took this one as an example.

Is there a way I could track the cursor position in a smarter way or is there a way to update/convert/replace only parts of textfield without updating the whole textfield (the way it works now is it fetches what is in the textfield, replaces Latin with kana inside a variable inside the function, updates the textfield with the new string from a variable and then positions the cursor)? Telling visitors not to type too fast wouldn’t really be the way to go..

Legend: wa=わ ka=か ri=り ma=ま su=す a=あ

Source can be viewed at the link I provided. Thanks.

Edit: One more thing to think about is that a user might move cursor left and right to add or remove characters/symbols. This complicates positioning a little bit but it works at the moment.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    To close this one up, I managed to figure out that the problem was actually that the third character (“m” in this case) went into the same .keyup iteration as “ri” and not after it as I previously thought (same symptom, but different reason)..

    To fix this I just modified the .keyup code to add +1 to the offset to shift the cursor to the right for one position if after the conversion there is a latin (roumaji) character left in the string.

    • 0