No cross-platform CJK IME support

It is still an issue in 1.11 on my Mac. Unable to type with Chinese and Japanese IME.

Still an issue in 1.11.2, I would volunteer myself to be one of the testers if its ever needed. Chinese IME user on latest macOS (Sierra) here, I'm able to test both zhuyin (traditional chinese, used by Taiwan) and pinyin (simplified chinese, used in Mainland China).

Unfortunately it is still a problem on Mac (Minecraft version 1.11.2, MacOS Sierra 10.12.2).
Since the problem has been around for such a long long time, I do not see enough enthusiasm for fixing it from the developers. Very sad.

17w43a snapshot now uses LWJGL v3 (all former Minecraft versions used v2) and the Korean IME seems to work well on macOS High Sierra (10.13) finally.
The composition window is invisible, but at least now I can type Korean charcter-by-character without modding!

I'm not sure this is better, lol... I just tested it for Japanese.

If I hit 'T' and then type てすと, the characters appear nowhere. The IME window does pop up below the Minecraft window, seemingly in the right position even, and with the right contents. If I press Enter, I expect this to enter the text as it already is, but nothing is entered and it just closes the IME. If I press Space, it does correctly go into the IME choices, but pressing Enter from those doesn't input the resulting choice either.

Additionally, if Japanese input is enabled while you're not in the chat field, the IME triggers when it should probably be disabled, which results in a bit of comedy:

Is this still a issue in the latest version of the game(currently 1.13.1)?

If so, please add it to the affected versions, thanks!

For both 1.13.2 and 1.14, the problem still exists, but the other way around.

In chat, command block UI and sign UI at least. Even if the input method is enabled, special keys (BackSpace, Enter, Arrow keys, etc.) are still caught by Minecraft.
For normal gaming, all keys are caught by both input method and Minecraft.

I'm using Linux Mint 19.1 (MATE), HIME input method and Sun Java 1.8.0_201 to run Minecraft.

Thank you Michael Wobst for re-opening this issue. I would like to provide my input that this issue still exists on the latest Minecraft snapshot 19w41a on Xubuntu Linux 19.04 running Oracle Java Runtime "1.8.0_221". When I type using my IME the IME popup appears to show I'm typing in Japanese but once I go to send the input the Minecraft chat stays blank. Typing in another windows and then copying and pasting the text does work but it is an extremely annoying workaround.

Issue still exists in 19w44a.

Issue still exists in 1.15 pre-release 1. Also would it be possible to grant me ownership of the issue so I can update it with the new versions as affected? The user who opened the issue doesn't have any know activity on their activity feed after July 2018.

Is there any way to find out if this is being worked on or to just politely remind the right people that it exists? It's a bug that has existed since 2015 and greatly effects multi-language communities. I would be more than happy to work directly with one of the Minecraft developers to help fix this bug. I'm aware that you might not have anyone in the office with a Linux setup. I can provide contact information upon request.

Minecraft is a game that should be enjoyed by everyone together, regardless of location and language. Being able to play Minecraft with my friends in Japan is great and even more fun while I'm learning their language(Japanese) and they are learning mine(English). It's a burden though to not be able to type in Japanese in game chat though because the game doesn't handle my IME input properly. Minecraft is the only program I've ever encountered with this issue.

An issue is currently being worked on if its status is "In Progress".

I would have updated it to include the April fool's day snapshot for laughs but it doesn't matter since this bug will probably never get fixed anyways. 

I'll still keep doing my due diligence and update the bug report to include every snapshot and release versions affected until it does get fix though..... No matter how many years it takes.

Edit because I just saw the above comment by a mod

Thank you for the info but this bug has never been listed as "in progress" and it has existed since 2015

Updated to include 1.16.  This bug has existed for almost 5 years now. It's as if Mojang only cares about it's English speaking player base. Extremely disheartening.

The problem is, Mojang people probably have no idea where's the problem and how to fix it.
MC-2781 got resolved only because I looked into a (possibly) hack done by another Taiwan player and rephrased it here, and the Mojang person "fixed" it probably just did what I said. (I inspected the bytecode after the fix; they are not exactly the same logic but good enough to make it work.)
Quote the description:

I think the community users and Mojang should work together to completely resolve this issue.

Too bad I don't have any experience using LWJGL to develop games so I can't give much help other than spread the word.

Alright, so after hours of research into LWJGLv3 and GLFW and trying to trick the minecraft launcher to load compiled versions of the latest glfw git repo I made an accidental discovery. IME input technically does work. There's nothing wrong with it looking for the input per say it's just not accepting it for other reasons. I'll explain.

When you activate IME input you do so by pressing a key combination. In my case this is the FCTIX default of CTRL+SPACE. Minecraft sees you press these buttons and does nothing. When you use IME input mode you have two options to complete your input. You can either press ESC to escape back out of IME input mode(pressing the key combination again also works) and ignore the input, or you can press ENTER/RETURN to confirm the input and place it in the text area. Minecraft still handles these button inputs while IME input is enabled.   This IS the problem. 

I was able(as seen in the screenshot) to type in the world search using my IME because pressing ENTER on a search that has no results doesn't do anything. When you press enter in chat it sends the message, but when you are using IME input the message gets sent before the IME sends the text over.

Basically, the best solution is for Mojang Studios to add a configuration option in the settings to add your keyboard shortcut for your IME. When Minecraft sees you press this input, it should then ignore all keyboard presses until either ESC, ENTER/RETURN, or the IME Keyboard Shorcut is pressed/pressed again.

(Just FYI, I've now been using RIME on ibus as my IME for days.)

I have discovered the same thing as @Matthew Strelsky has. Pressing ENTER/RETURN keys does send your input from the IME. However, it also tells Minecraft to send whatever in the chatbox, which is nothing.

I noticed Adrian Östergård updated the severity of this bug report. Thank for doing that and thank you Octopus Tea for confirming my observation with a different IME.

Again, I fully understand if nobody on the dev team has access to a non-Windows machine to test the fix on. I would be more than happy to assist in testing bug fix implementations for this issue.

Long time no see. I appreciate that this issue is still being tracked and updated. 👍

I confirm that Matthew's analysis is correct and will lower the effort to address this issue, but would like to add one more thing:

• In the Korean IME, the completion of IME composition should also happen with the "loosing the focus" event (e.g., when clicking outside of the input field) and "auto-completion of the current word" event (e.g., when pressing the Tab key), not only ESC/RETURN/IME-switch keys.

  • I have experiences with some applications that had handled this incorrectly (e.g., instead of completing the input but cancelling it upon the focus lost event). For example, a few years ago, the Chromium project made a small mistake on this, and it took a quite while for Korean people to get a correctly working version again of all Chromium and Electron-based apps (e.g., Slack, Microsoft Teams, etc.) until the upstream patch was propagated to all subsequent applications. Yes, that was very painful.

  • Implementation mistakes in wrong completion/cancellation of composition usually happen with auto-completion features on input fields, either in the browser itself or by the Javascript event handlers, in the web world for example. This could also happen again with the Minecraft's chat command UI since it has support for command auto-completion. We need to keep an eye on it.

• As Matthew proposed, the Minecraft app itself should just let all details be handled by the OS IME in most cases by ignoring key presses as "game" inputs when an input field is active. But for the auto-completion feature, it usually requires a fined-grained interaction with the IME. So, to lower the implementation efforts, it would be also a good option to provide a configuration toggle to disable the auto-completion feature for "complex" IME users if it appears to interfere with the IME.

Mojangstas, please keep in mind the above detail if you go to implement the patch.

Thank you for the additional input! Hopefully we do get this fixed soon. It's been a problem for at least 5 years now and effects a large portion of the Minecraft user base. I'm surprised it hasn't been a higher priority for Mojang.

Updated to include 1.18 now that it is released. Hopefully this bug will be fixed some day. Even just implementing the workaround we suggested in the comments would be good enough but there's nothing the end user can do but wait for Mojang. It's been a long wait but I'm still hopeful.

Sadly, after a long wait of 7 years, Mojang has chosen to refuse to fix this bug to the detriment of the international community. 

Will a moderator please change the status to "refuse to fix". I'm tired of constantly updating the versions effected by this bug and am heartbroken but can no longer keep this bug report updated.

In that case the reporter can be changed to someone else willing to keep it updated. Unless you got an actual source of Mojang saying they won't fix this (not having fixed this != won't fix this), the report will stay open, especially since it has been triaged by Mojang.

Still an issue in 1.20. Mojang still marks the priority as "Important", but almost ignores it.