Barotrauma
Barotrauma copied to clipboard
Chinese Input method cannot pop up candidate box
Disclaimers
- [X] I have searched the issue tracker to check if the issue has already been reported.
- [ ] My issue happened while using mods.
What happened?
Look at this mod,please! None of the Chinese player can bother the problem because we need the candidate box to spell words. Without the box to spell Chinese Character is like to input English words but you can't see what you print before you finish your sentences. https://steamcommunity.com/sharedfiles/filedetails/?id=2789811877 IT IS A VERY SEVERE PROBLEM.
In fact , someone told me that he has issue the problem earlier last year, so it is very strange that you still hadn't fixed the problem today.
Reproduction steps
No response
Bug prevalence
Happens every time I play
Version
0.18.12.0
-
No response
Which operating system did you encounter this bug on?
Windows
Relevant error messages and crash reports
No response
Thank you for the report!
I'm not entirely sure I understand the issue, is thid somehow different from https://github.com/Regalis11/Barotrauma/issues/6509 (the candidate box not popping up)?
Slight different. (All of the Chinese input method can not pop up candidate box) You may ask another Chinese about it, he can tell you detailly what the problem is. My English is not good, so I can hardly describe the problem. As Chinese has many characters that has the same voice (like homophone in English), and we spell a Chinese character by its voice, we need the candidate box to choose what character to use.
Thank you for the extra info! I'm not familiar with Chinese input methods, so I assumed the old issue was about some rare problem that only affects a small portion of the player base (especially when we'd gotten only that one report about it, and hadn't heard of anyone else having these kinds of issues). But if it is something that affects all Chinese input methods, this is a much more high-priority issue than I thought. Thank you for letting us know about this!
Internal note: some possible options for implementing this
- https://github.com/ryancheung/MonoGame.IMEHelper
- https://steamcommunity.com/sharedfiles/filedetails/?id=2789811877 (implementation by @zhu-rengong, with the caveat that it only works on Windows?)
https://steamcommunity.com/sharedfiles/filedetails/?id=2789811877 This mod only works on Windows, because i'm not familiar with other operating systems. However, according to our investigation, the Chinese input method works fine when running games on linux and mac os, so at present this problem only exists on windows.
Internal note: some possible options for implementing this
* https://github.com/ryancheung/MonoGame.IMEHelper * https://steamcommunity.com/sharedfiles/filedetails/?id=2789811877 (implementation by @zhu-rengong, with the caveat that it only works on Windows?)
Maybe https://github.com/ryancheung/MonoGame.IMEHelper is a more suitable implement? The author support DesktopGL after restart this project
Have you fix this problem? It is a really sever problem, because if you change to Chinese input method, when playing the game you press AWSD or other to oprate, these character you printing will gathered together in the input method, and finnally cause game crash. I haven't played the test version, but in 0.18 the bug hadn't been fixed.
@Regalis11
Thank you for the reminder! We finally got around to addressing this (commit in our private repo https://github.com/Regalis11/Barotrauma-development/commit/d33dc0a1a3bd43537b7c3cc805d422dcf94718f5).
When we get the fix included in the unstable branch, it'd be much appreciated if you could give it a test and let us know if it works the way you expect - as I'm not familiar with this input method, I'm not completely sure the way it's implemented adheres to all the best practices and such.
OK, I'm glad to test it.
On Thu, Sep 29, 2022, 23:44 Joonas Rikkonen @.***> wrote:
Thank you for the reminder! We finally got around to addressing this (commit in our private repo @.*** https://github.com/Regalis11/Barotrauma-development/commit/d33dc0a1a3bd43537b7c3cc805d422dcf94718f5 ).
When we get the fix included in the unstable branch, it'd be much appreciated if you could give it a test and let us know if it works the way you expect - as I'm not familiar with this input method, I'm not completely sure the way it's implemented adheres to all the best practices and such.
— Reply to this email directly, view it on GitHub https://github.com/Regalis11/Barotrauma/issues/9509#issuecomment-1263172695, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARGU7WIYAXBER2IKBCH5A3LWA2D4PANCNFSM52PE7TJQ . You are receiving this because you modified the open/close state.Message ID: @.***>
A more detailed version of my response from #10515
I'm not very familiar with Chinese, so I'm unsure of how similar these issues are beyond characters from both languages being invisible. However, native Korean characters don't require any sort of "candidate box". After attempting to type in v0.20.7.0 today, I found that the invisible character issue persisted (albeit in a different form) and a new issue arose involving the interaction these characters have with what I'm assuming to be the candidate box (a smaller text box beneath the primary one).
1. Invisible Characters
In 0.19.14.0, characters would remain invisible until the syllable block was completed, the return key was pressed, or the spacebar was pressed. This makes typing very cumbersome since syllable blocks are not always filled when typing words. In v0.18.11.0, the first character typed will be invisible, but any further characters will reveal the entire syllable block. However, if the characters in the block return to 1, that character will again become invisible.
2. "Candidate Box" Interaction
In v0.18.11.0, Korean characters will initially appear in a smaller text box beneath the primary one. When a syllable block is complete, return is pressed, or the spacebar is pressed, they are then moved into the primary text box. If this is done while inputting into a chat box, the contents of both the smaller and primary text box will be posted into chat. If backspace is pressed while typing in the secondary text box, it will delete data from both the primary and secondary box. I included these interactions incase it helps figure out issues with a language that requires the use of an auxiliary text field, it is unnecessary for typing native Korean characters and its removal would solve this issue.
There hasn't been any reported issues of this since the latest patch release and I think if new issues comes up there's more likely going to be a new ticket for that issue so I don't see the need to keep this ticket open much longer. Closing.