Chinese, Japanese and Korean (and probably other IME entered languages) characters not working (fixed for Windows)

I know they can access the API, but Minecraft doesn't use a generic textbox. How would that interface with it?

Not being able to type in your native language is actually a pretty big issue to have. Particularly if your language is big on homonyms...

The issue here is not 'How do I build an IME?' but 'How do I do IME-friendly input in Java/lwjgl?' Some m18n best practices documents should help shed some light on this. Evidently, at least two people have found a way to fix this for minecraft (nihongoMOD and MinecraftIM), so this is not an unsolvable problem.

There are other input issues that deserve attention (the old release of lwjgl packaged with minecraft has some IME related bugs affecting at least linux) but IME support in vanilla minecraft would be a very, very nice thing to have, as nobody should have to mod minecraft just to be able to communicate.

Yeah, It still not work in Minecraft 1.4.7

In 13w16a:
*You can't type if you don't select from the list
*You can type if you select from the list, but only the first character will appear

The summary of this bug should be changed since this is an IME related issue and also affects Japanese and other languages which uses IME.
The same bug with Japanese is reported in the comments.

To check if this is an LWJGL bug I wrote a simple program which prints characters obtained by Keyboard.getEventCharacter().
https://github.com/jetkiwi/LWJGL-Input-Test
Using this program, I was able to check that LWJGL does pass on IME input.

I also checked the decompiled 1.5.1 source and I found that in net.minecraft.src.GuiScreen,
handleKeyboardInput() uses Keyboard.getEventCharacter() to obtain the keyboard input.
So Minecraft is receiving IME input from LWJGL but seems to loose it somewhere.

In the 1.6.2, the input is lost when using Microsoft Japanese and Korean IMEs
When using Sogou Wubi IME for entering text, only the first character of the phrase is printed. For example, in Sogou Wubi, you can enter "你好" by entering "wqvb". But in Minecraft, only "你" is printed.

The cause of this bug is in GuiScreen#handleKeyboardInput().

Keyboard#getEventKeyState() returns false for non-keyboard input.
Since IME inputs are treated as non-keyboard input this cause Minecraft to reject most of the IME input.
Replacing this to "true" solves the problem (probably causes other problems but it still solves the IME issue).
Checked it with the decompiled 1.6.2 using MCP 8.04.

With the latest nightly builds of LWJGL, users on Mac/OS X should be able to type any Unicode characters (including Chinese, Japanese and Korean).

This bug is fixable via applying patches to minecraft.jar
basically people have been doing this for ages in order to type these foreign language in minecraft.
The affected files are:
avk.class (bypassing the server motd display limitations)
awb.class (add input method support)
axv.class (bypassing Signs input limit)
jz.class (bypassing the server side Signs display limitations)
v.class (unlocked colored characters)

1.6.4 patch: https://www.dropbox.com/s/l10xfirssjxvnch/mc1.6.4%20chinese%20input.zip
1.6.2 patch: https://www.dropbox.com/s/sy96ucah8tcxhn3/mc1.6.2%20chinese%20input.zip

if someone just open these classes and take a look at what they've changed. that'll fix the problem.

Bug is still reproducible in 1.7.2 release.
Tested with lwjgl 2.9.0 (original) and lwjgl 2.9.1 nightly (2013/10/28) in Windows 8.

reproducible in 1.7.2 release. with window 7
i can only type couples characters but certainly not all characters like when i use the patch.

@Calvin Lai Hi there! In one of your posts, you posted a link to two files, for Minecraft 1.6.2 and 1.6.4 to enable the input of characters. They work great! Did you make these patches, or did you get them from a public link? I can't find a version for 1.7.2. Do you know if any exists? But I wish Mojang fixed this bug, if it is this easy to fix!

P.S: Sorry, I wouldn't be able to do it myself, I have no idea of how to edit .class files, what program to use, and which parts of .class files to edit (the code is all 'Double-Dutch' to me).

@ZambiblaisanOgre No, i didn't make it. It's from a Chinese forum. The author is probably waiting for the 1.7.2 MCP in order to fix the bug. For now, we can't type chinese on 1.7.2 minecraft and most of the people can't type english. 🙂

For what it's worth, the jd-gui decompiler will let you read those .class files. They don't look particulary scary; someone with access to minecraft source should be able to figure out where the patches have been made, roughly what those were and get a solid lead on what needs to be done to fix keyboard input in minecraft.

It still not work in Minecraft 1.7.4/14w02c

It still not work in Minecraft 14w03a/14w03b

It still not work in Minecraft 14w08a/1.7.5

Doesn't work in latest build(14w11b)

When can fix this bug?

@unknown, this bug will only get fixed when Mojang understands that bug is a major problem among CJK users.
Please try to persuade others to vote for this bug. If we get enough votes, Mojang might feel like fixing this bug.

Mojang , minecraft start to be very famous in Japan , and many japanese dońt speak english , so it´s why its very usely for chinese and other too i think ...

Maybe enable multi-byte input?
(thinking originally from the mod "inputfix")

I bump this issue again, as Minecraft Realms became available world-wide.
Minecraft supports display of Unicode characters very well, but still we cannot type CJK languages.
I think the fix should be done in coordination with LWJGL because Minecraft uses it and LWJGL does not provide any IME-related APIs.

In my private server, I use a IRC-Minecraft mediator bot to translate English keystrokes to Korean characters to run the vanilla server and clients.
In Realms, we need to use 3rd party mods for the clients. 😞
Moreover, such mods typically support only one layout (2-bulsik) out of two standard Korean keyboard layouts (2- and 3-bulsik) because they are implemented as a pure Java-based automaton manually and thus supporting both increases efforts and time for mod developers.
If we allow direct use of OS-provided IME, the layout problem will just go away.

I don't believe LWJGL needs to provide any IME-related APIs, because Java already supplies a platform independent one. Minecraft's custom textbox shouldn't be a problem either. I think the biggest barrier to making progress on this is simply that there probably isn't anybody at Mojang who is familiar with IMEs or CJK languages. Unicode support in Minecraft has been improving, however. The recent internal changes to chat functionality should also make this easier to implement.

I just tried using the Microsoft IME in Windows 7, and it prevents Minecraft from responding to the letter keys on the keyboard, and yet still doesn't work for entering CJK text. Considering that the movement controls default to WASD, that's kind of an issue.

Minecraft + LWJGL can handle CJK text properly.
What it can't do is to handle IME input properly

Run Minecraft 1.7.9 and leave it on chat mode, and paste the following on Windows PowerShell.
"これはテストです" will be displayed in the chat input.

[void] [System.Reflection.Assembly]::LoadWithPartialName("'Microsoft.VisualBasic")
[Microsoft.VisualBasic.Interaction]::AppActivate("Minecraft 1.7.9")

[void] [System.Reflection.Assembly]::LoadWithPartialName("'System.Windows.Forms")
[System.Windows.Forms.SendKeys]::SendWait("これはテストです")

How input from the Windows PowerShell script and the IME are handled in LWJGL can be easily checked with my small test program.
LWJGL-Input-Test
Change the PowerShell script from "Minecraft 1.7.9" to "Game".

--- exec-maven-plugin:1.2.1:exec (default-cli) @ LWJGL_Test ---
true :こ
true :れ
true :は
true :テ
true :ス
true :ト
true :で
true :す
false :あ
false :い
false :え
false :む
false :い
false :ー

While "これはテストです" is from PowerShell, "あいえむいー" is from the IME.

The boolean shown on the left is the value of Keyboard#getEventKeyState() from LWJGL.

GuiScreen#handleKeyboardInput() in net.minecraft.client.gui discards inputs if Keyboard#getEventKeyState() is false.
This is preventing IME input from being handled properly.

So this could be trivial to fix, if it can be shown that ignoring the result of Keyboard#getEventKeyState() does not cause other problems.

Thanks for testing ja731j. 🙂
It needs more considerations however.

I think if the following requirements are satisfied, it will be perfect.

• At least, Minecraft should recognize CJK characters just like when typed in notepad.

• It will be much better if Minecraft supports "on-the-spot" composition of CJK characters. (Please have a look at http://www-archive.mozilla.org/projects/intl/input-method-spec.html )

• Minecraft should explicitly disable/enable IME. Please, please, enable IME only when a text field has the focus. It will prevent WASD from not working when non-English IME is active, because disabling IME will pass all keystrokes "as-it-is". For example, Windows provides an API to do this: http://support.microsoft.com/kb/171154/en-us & http://msdn.microsoft.com/en-us/library/windows/desktop/dd318171%28v=vs.85%29.aspx, and I guess Java has a method to do this (but LWJGL doesn't – see http://lwjgl.org/forum/index.php?topic=4129.0).

FYI: Using ja731j's test program and a Korean IME (with LWJGL 2.9.1 downloaded inside .minecraft/libraries directory and Java natives in .minecraft/versions/1.7.9/1.7.9-natives), the result is:

false :한
false :글
false :입
false :력
false :도
false : 
false :잘
false : 
false :되
false :나
false :요
false :?

Note that copy-and-paste Korean texts from notepad works fine. (Of course it's prohibitly inconvenient as Minecraft shows the game menu whenever it losts the focus...)

I found that getEventKeyState() function returns false if the key is not pressed down when the function is called.
For IME-input strings, this becomse false because Windows' default window procedure converts IME-related window messages to WM_CHAR after finishing composition of characters, according to http://msdn.microsoft.com/en-us/library/windows/desktop/dd374062%28v=vs.85%29.aspx . In this case, Windows implicitly builds an external window (root window) to show composition of characters. Since the location of caret in Minecraft and the location of this composition window differs significantly, the users may be confused when typing CJK characters.

Generally, checking/polling the key state (down or not) using DirectInput or jinput is useful for in-game control keys (e.g., WASD) but NOT useful for text inputs. It should not be used for implementation of text inputs. The concept of "text" is much more sophisticated than just delivering keystrokes to the application. It involves translation of keystrokes into abstract symbols and interpretation of the sequence of symbols using automata, and etc. Unless game developers want to implement all of these steps manually, they should allow interaction with OS-provided IMEs. Please have a look at a custom Korean IME: http://moogi.new21.org/en/ngs/index.htm & http://moogi.new21.org/ngs_menu2.htm to glimpse how complex the process is.

"Keyboard Input (Windows)" from MSDN explains what kind of Windows Messages are sent from the IME.

I haven't figured out how Messages are handled in LWJGL, but these are the classes that actually handle them.
https://github.com/LWJGL/lwjgl/blob/55bfecf5149cf79aa4f8fc1293001986cfae3a2b/src/java/org/lwjgl/opengl/WindowsDisplay.java
https://github.com/LWJGL/lwjgl/blob/849511784b7651bd30ab35e0ff10c023f28cca9a/src/java/org/lwjgl/opengl/WindowsKeyboard.java

Somehow the Keyboard class can access the information. I do not know how.
https://github.com/LWJGL/lwjgl/blob/bafa7a1972718abf0f2304124a46ae3fa67be7df/src/java/org/lwjgl/input/Keyboard.java

So I suggest following steps to fix this issue:

1. A very quick fix: accept characters with getEventKeyState() = false in the text fields and sign/book inputs.
This seems to allow CJK users to type CJK characters with "root-window" style IME pop-ups. It should be fine on the windowed mode but may interfere with the full-screen mode. The CJK users have to switch the IME mode manually whenever closing the chat window, but at least they will be able to chat in their languages on Windows. Not sure about other platforms though.

2. More decent fix: create an IME text input layer in either Minecraft or LWJGL. The problem is that implementing it correctly for all platforms (Linux, Mac, and Windows) might require huge efforts. Unfortunately I know some basics of IME handling on Windows (I've contributed to implementation of on-the-spot composition support in PuTTY. See iPuTTY project and related source code.) but none on other platforms.

I'm also hoping that a fix for this is implemented in the near future as I would love to be able to type Japanese. I'm also working on my own game which I want to support additional languages, so perhaps if I come across a solution I might post some information regarding how to fix the issue.

Is there any progress to this issue?
I'm wondering what is the perspective of Mojang on this issue, e.g., Are they waiting for somebody to come up with full implementation? Are they waiting for testing of ignoring false return value of getEventKeyState()? Are they waiting for more comments and responses? Does this issue have low priority because Minecraft's primary market is Western area? I simply do not know the sales statistics of Minecraft in the East Asian region, but I undestand that Mojang may not have enough motivation to look in this issue if it affects only 0.1% or less users. If so, please let us know to find other solutions and make progress!

I believe the current concern is the interface. They'd rather not depend on a floating, external window for character selection/conversion, which means they'd have to implement an interface themselves. And I don't think anyone on the Minecraft team has much, if any, experience with IMEs or the languages that require them.

The current method of fixing 1.7.x as follow.
Mojong can simply implement this to minecraft.
https://github.com/zlainsama/InputFix
or
https://github.com/zlainsama/MoLanguage

@Torabi, I think just "not ignoring false return value of getEventKeyState()" will be a good starting point for Mojang even though they do not have experiences on IMEs. @Calvin's links do the same thing, but have different methods to patch Minecraft class files.

Floating/external windows are implemented by IMEs, not by Minecraft. If you use standard text inputs for your Java application, you do not have to think anything about IMEs. It's OS-provided function. For Minecraft, the root cause of this problem is that it uses "custom" text inputs that processes only single (English) key strokes. Just allowing IMEs to pass their composition results to the text inputs will work, and the first step is not to ignore the key events when getEventKeyState() returns false.

Googling shows me two more similar patches.

https://bitbucket.org/ChickenBones/notenoughitems/pull-request/9/fixed-the-input-problem-with-cjk/diff
https://bitbucket.org/ChickenBones/notenoughitems/pull-request/12/by-this-way-can-slove-the-problem-of-input/diff

Mojang, please apply and release the quick fix as a snapshot to allow testing by the public, the CJK users in particular.
If it causes problems to other features, you can simply rollback the changes as many times before. I think snapshots are the perfect place to do such public tests.
If it resolves the input problem to some extent, we could discuss and make decision to close this issue or not.
If you, Mojang, have enough money, then please consider (temporarily) employ CJK Java developers to fix this problem.
Please be agile on this issue.

An in-game composition window would be preferable, but if external floating windows are what foreign language users are used to, in Minecraft or other software, then it may not be as much of a problem as @unknown believes it to be.

There's an interesting comment here about the use of getEventKey(), specifically that the LWJGL documentation recommends this instead:

(Keyboard.getEventKey()==Keyboard.KEY_NULL) ? Keyboard.getEventCharacter() : Keyboard.getEventKey()

The same information is present on issue 59 at the LWJGL bug tracker. This may also fix the issue of Minecraft ignoring keyboard input when an IME is enabled.

The comments in MC-30704 contain some more information and code to fix the problem for other non-English keys, and may also fix this issue as well.

Thanks a lot, @Torabi! 🙂
Yes, I agree that floating IME windows may be invisible or look ugly in the full-screen mode. (We could test and see using the snapshots!)
However I belive that being able to type our native languages is much more important than use of the full-screen mode because Minecraft works and performs well with the default windowed mode.

Ultimately in-game composition window will be the best solution, but it involves huge efforts to modify LWJGL and Minecraft itself.
I think allowing non-ASCII/IME-delivered keyboard inputs is the most cost-effective solution currently.

I am a native english speaker but I still think this should be implemented as soon as possible. Just my opinion.

Played around with this today, might be fixed.

@Grum I'm glad to hear that.

Can any other one confirm this fix? I have tried 14w34c on my Mac, but I still cannot type any Chinese or Japanese characters. No IME window is shown at all, and only English letters are printed out.

I am using Mac OSX 10.9.4, Java 1.6.0_65 64bit, Google Japanese IME

UPDATE:
I just tried again with Mac OSX built-in Zhuyin IME. Indeed the Chinese "alphabet" (Zhuyin) was printed out directly, but there was no chance for me to select a real Chinese character.

For Chinese (and Japanese Kanji), one pronunciation is mapped to many characters, that is why there is a need of IME for the user to select the final printed character. The problem of Minecraft now seems to be that the IME window is completely unusable.

So I do not think this issue can be called fixed for the current snapshot.

I neither confirm this issue fixed on Windows version (8.1 64bit, Java 1.7, with the vanilla launcher).
Korean IME does not use extra "selection" windows unlike Chinese/Japanese IMEs and just need the composition results to be delivered to the application.
I'll try Mac version and Linux versions soon.

Not fixed in 14w34d.
Windows 8.1 64 bit, Java 1.7.0, vanilla launcher, Microsoft IME 2012 using Japanese.

Just checked and it doesn't work.
Windows 8.1 64 bit, Java 1.8_20, MC Launcher

Perhaps you can take a look into MinecraftIM at http://forum.minecraftuser.jp/viewtopic.php?t=153 It does appear to work, although you can't type in fullscreen and you have to disable the ime to play. Additionally it's outdated, last version was for 1.6.2.

This mod work for 1.7.10 , you need forge , but you can type in fullscreen (japanese IME work)
here is the link ! http://mcc.mcsv.jp/IntelliInput
and not fixed in 14w34d for me D:

I've tested 14w34d on a Mac (OS X Mavericks, Java 1.6, OS-default Korean IME) and it did not work completely.
Only the first consonant syllables were typed. (Most Korean characters are composed of two or three syllables, combining consonants and vowels.)

Please add Linux Platform into the Environment list...

On Linux there are no mod workaround for it.

1.8 prerelease on Windows 8.1 does not work with IME. Is it postponed to next minor releases?

Windows 7 64bit, Japanese IME: The composition window appears when typing, whether the chat input is open or not. Thus, the game doesn't respond to the controls. Characters are not inserted into the chat box when it's open either.

@Torabi,
The reason that the composition window appears regardless of chat input is open or not: Minecraft does not disable IME while text input is not open. As I mentioned above, automatic disabling/enabling IMEs depending on whether the focus is at text input is another important feature for CJK users. Gameplay keys must NOT go through IMEs (just like now) whereas text inputs MUST go through IMEs.

As I mentioned above again, Windows automatically fall-backs to OS-provided UI (the composition window you see) if the application does not explicitly call IME-related APIs to control rendering of intermediate results of character composition. In such cases, WM_CAHR window message delivers the composition results and LWJGL seems to pass them to Minecraft but the event key state says "not pressed" and thus Minecraft ignores them.

For native Windows application like notepad, the OS-provided text input control internally manages IMEs and character composition process.

In Mac, LWJGL seems to deliver only the first component of the character being composed.
I don't know how IME works on Mac/Linux platform.

BTW, I believe that even a partial solution for Windows users would be much appreciated by CJK users.
I really want to stop copy-and-pasting texts from notepad (or installing 3rd party mods just to play the vanilla version – you know, I have to wait them to update when the new version comes out)!

@Torabi,
So I suggest the first-step solution (at least for Windows users):

• When a text input UI is open and active: Accept any key input even if the event key state says "it's not pressed".

• Otherwise: Ignore them just like now.

Unfortunately LWJGL does not have any kind of IME-related APIs, such as enabling/disabling IME. It just delivers WM_CHAR messages like key strokes. We need to collaborate with LWJGL developers to solve this issue ultimately.

@Joongi Kim,
Agreed!
A partial solution for Windows will at least show that Mojang is working on to improve Minecraft's internationalization support.
Even though that Mac/Linux users like me can't benefit from it (and it will probably partially close this issue), but it will be really appreciated from all of the CJK users.

checked for 1.8-pre2
still can't use

I just checked out 1.8-pre2 on Windows 8.1 + Java 1.7, but it still completely ignores IME-based character inputs on the chat input.

1.8pre3 looks same regarding this issue.

I (and probably other CJK users) want even a partial solution (for Windows) to be applied before the official release of 1.8, and expect fundamental fixes in collaboration with the LWJGL community in a foreseeable future. (A good example is SDL's text input APIs: https://wiki.libsdl.org/Tutorials/TextInput . IME implementation was a part of community participation in Google Summer of Code 2010.)
The current status of LWJGL can be seen at link #1 and link #2. 😞
I hope I too have some time to study LWJGL/Java/cross-platform IMEs and design + implement LWJGL's IME APIs, but unfortunately I do not have enough time to do it.

People use this patch to fix the bug by putting this into minecraft.jar. Hopefully it can help you(developer).

John Chen, this is a bugtracker, not a mod hosting site. Feel free to host the mod else-where and link to it, but it does not belong as an attachment for this issue.

i'm sorry for add an mod attachment. i only want to help developers to fix the bug

Please update BUG-version to add minecraft 1.8.1and pre-1.8.1-4.

@all: Please stop the off topic discussion about any translation.

1.8.2-pre6 still not fixed

There is a post on 巴哈姆特 (One of the biggest gaming forum in Taiwan) a few months before this bug created:

http://forum.gamer.com.tw/C.php?page=1&bsn=18673&snA=35796 (Traditional Chinese)

The op provided class file replacement (for release versions) which when patched (using the old-school replace-file-in-jar method), this problem is fixed. This post is continuously updated with new releases, currently providing fixes for 1.7.2 through 1.8.2-pre4 before the post was locked by board mod when other users replying to this three-year-old post. He posts later updates on his user page of that site:

http://home.gamer.com.tw/homeindex.php?owner=a0918430588 (Also Traditional Chinese)

Recently I finally got some time to work out what he did to the class to fix the problem. Here is what I found.

Take the 1.8.3 patchfile he provided for example: The method he changed in axv.class is l(). This method is roughly like this:

public void l()
{
	if(org.lwjgl.input.Keyboard.getEventKeyState())
	{
		this.a(org.lwjgl.input.Keyboard.getEventCharacter(), org.lwjgl.input.Keyboard.getEventKey());
	}
	this.j.Z();
}

(I javap'ed the class file and recreated the method from bytecode by myself; fortunately this method is very small – only ten bytecode instructions. For the same reason, the class name / method name is the obfuscated name except the calls to LWJGL.)
He changed this method to become:

public void l()
{
	char ch = org.lwjgl.input.Keyboard.getEventCharacter();
	if(ch >= 32 || org.lwjgl.input.Keyboard.getEventKeyState())
	{
		this.a(ch, org.lwjgl.input.Keyboard.getEventKey());
	}
	this.j.Z();
}

(Again, this is recreated from javap result by myself. ch is using a local register to store, so I reckon he had a local variable for it; the name ch is arbitrarily chosen.)

This fixed the problem.

I havn't used LWJGL before, so I don't really know why this fixed the problem; my guess is that since we need multiple keystrokes to enter one character, the event getting the character is different from the keystroke event. (I have a wild guess here: in this case, LWJGL only get the final character event; the intermediate keystroke events are eaten by IME. I don't know if this is true or not.) Since the character event is not associated with any key, its getEventKeyState() return value is meaningless and probably LWJGL just return false in these case, which then causes l() to discard this event.

Hope this information can help Mojang developers to fix this problem once and for all.

Can we get word from someone up top about whether this will be considered to be fixed by 1.9? Chat functionality is a very basic bug that affects tons of people without a voice to complain. It's been four years since chat broke!!

Tried implementing the above-mentioned fix. Though that path was never reached when getEventKeyState() returned false, does now with some extra changes.

Please check it in the next snapshot 🙂

Thank you Grum! I always were very frustrated that I can't type Japanese directly into Minecraft. You made my day, can't wait for next snapshot ^^

i really really appriciate grum thank u
i did wrote many articles to korean communities,reddit and messaged skype friends, for vote spur this bug

i'm crying ㅠㅠ

Finally 15w43a on Windows works well with Korean IME!
The Mac version, however, has some issues on composition of Korean characters and behaves differently with different OS X IME plug-ins. This is what I have expected already, and I think that should be fixed along with lwjgl.

Anyway, thanks a lot!

Sadly, it still does not work on Mac OSX 10.10.5. Neither Chinese nor Japanese IME work. If the developer need any other information (such as log file), please let me know.

Confirming that Japanese at least still doesn't work on Mac OS X 10.11. It behaves the same as before - latin characters come out even if I'm not using the English input method.

For a better solution, we need to patch LWJGL as well.
I created a separate issue to continue discussion on that: MC-91132

Traditional Chinese IME on Windows is confirmed fixed as well.
As Joongi Kim pointed out, Mac issue is in another way; in fact, since the patches in the link I provided above also not working on Mac, those patches may aimed at Windows users only.

Anyway, many thanks to Grum on fixing this bug! 😃

I find it hard to call this "fixed" when it still doesn't work for many people...

Maybe change your wording to "thanks to Grum for fixing this bug for some of us". The rest of us will continue waiting and expect a fix some time before 2035. 😞

@@unknown: There is alread a new ticket for this: MC-91132

@Kumasasa I know (I'm already watching it). I was addressing someone who claimed that this bug has been fixed, when it has not actually been fixed yet.

When fix for Mac?

There are no fix in linux by using gcin, and no other third party solution now.
currently I just could use copy and paste to type chinese in the chat.