More of that stuff
- Emoji support
- Steps to configure desktop environments for IME support (GNOME has top-notch out-of-the-box support by having integrated IBus, KDE can be a right b*tch to set up correctly with either IBus or Fcitx but works almost perfectly afterwards, and I don't know enough about how well other DEs support IMEs)
- Some info on XIM
- Some info on GTK's "simple" unicode input support via
- Some info on how to properly set up shortcuts for changing IME input modes (e.g. from Hiragana to Katakana in the Japanese IMEs). This one is really important, but I personally still haven't found a solution to gracefully resolve the conflicts with the various DEs' global shortcuts, or to emulate some needed keyboard keys present in non-Latin keyboards without affecting text input when the IME is inactive (see e.g. Mozc#Use_CapsLock_as_Eisu_toggle_key_on_ASCII_layout_keyboard)
- When I first Googled how to switch between Hiragana and Katakana, I saw (Windows?) users saying it's generally F6/F7. I was wonderfully surprised to find this worked out the box with mozc in both fcitx and ibus. I didn't have any DE shortcuts on these keys (I'm on Cinnamon). Note, this isn't the same as changing your "input mode" to START typing in hiragana/katakana (which you can do elsewhere). F6/F7 will convert the word you're busy typing, you can press the other key to convert back. F6 - Hiragana, and F7 - Katakana.
- I'm aware of these shortcuts, but unfortunately they conflict with shortcuts in very common applications like Firefox, Chromium or Libreoffice, so that makes them kind of unusable. In the meantime I think I've found a good solution to add emulation for Eisu, Muhenkan, Hiragana, Katakana and other specialized keys by utilizing XKB (which is the modern, display server agnostic way of modifying keyboard layouts instead of the deprecated and X11-only Xmodmap that is mentioned in Mozc#Use_CapsLock_as_Eisu_toggle_key_on_ASCII_layout_keyboard) but I've not mentioned it anywhere yet because I'm currently in the process of thinking how all the various localization pages should be organized and which pieces of information should reside where, in order to both avoid duplication and make it easy for a new and totally clueless user to find whatever they may be looking for in the place they'd expect to find it.
- P.S. I hope you don't mind that I moved your comment below mine, as per the talk page guidelines (in practice, so we can reply to each other without messing up the conversation flow).
Not all IMEs work by romanisation
So basically, I added Wikipedia:Cangjie_input_method into the table a month ago. Now I suddenly realise the existence of this statement:
- The IME does this through a process called romanization, which is the transliteration of non-Latin language sounds into the Latin equivalents that most closely resemble them.
Which is totally wrong: in Wikipedia:Input method, Cangjie is considered an IME, but it doesn't use romanisation. Saying that an IME
takes Latin characters that you type on your keyboard and outputs them on your screen as non-Latin characters is also incorrect in my opinion as users are indeed typing Chinese characters — radicals — to create Chinese characters. (For more info on how Cangjie works, read the wiki I linked.) And if you are wondering, it is practically using its own keyboard layout. I'm not sure about the technical details.
In conclusion, we either need to remove that definition, or need a redefinition. I am adding Template:Accuracy there, let me know what you think.
- Cangjie does not work by typing Chinese characters and it doesn't use its own keyboard layout, it works by typing standard Latin characters on a standard QWERTY keyboard using a standard US layout, and then these Latin characters are intercepted by the IME, matched to their equivalent Cangjie radicals, and combined to form the hanzi that is finally outputted to the screen. In other words this is still a textbook case of romanization, it's just that it doesn't rely on spoken sounds but rather on written shapes.
- The inaccuracy here is not in the parts you highlighted, but rather that I described romanization as using only sounds (because it's by far the most common case) where in practice it's a more generic method that can actually use other stuff like e.g. shapes, as in this case. So the last part "...which is the transliteration of non-Latin language sounds into the Latin equivalents that most closely resemble them" could be written more generically as something like "...which is the transliteration of non-Latin language sounds into letters of the Latin alphabet", and then the example section could be expanded to also showcase the non-sound-based methods like Cangjie.
- Ah, so you mean that one can use a Cangjie-specific keyboard layout that directly outputs the Cangjie radicals without an intervening IME? OK, I didn't know that. And well, if Wikipedia doesn't consider Cangjie as a romanization-based input method, then who am I to disagree; so I stand corrected.
- So we could have the section changed to read something like "input method editors mainly work via romanization which is the transliteration of sounds etc etc, with the exception of some cases like the Cangjie method which instead work with character shapes like so etc etc". And then remake the Japanese example as the showcase for sound based methods, and add an equivalent Cangjie example as the showcase for shape-based methods.
- The thing is, every key is "binded" to a radical when you are using Cangjie. I can accept that it is using qwerty and may type English character (since most IMEs support it and I don't see any that doesn't do that), but I don't accept that it's using romanisation. :D
- "input method editors mainly work via romanization which is the transliteraion of sounds ..." — We can skip the part of the exception thing since we are showcasing it as an example later in the article.
Regarding the Mozc packages
fcitx-mozc packages in the community repo are IMHO not properly packaged, in that they bundle both the Mozc-specific components and the Fcitx-specific components, which makes them unable to be installed and used alongside their
emacs-mozc counterparts (which utilize a separate, independent package to provide the Mozc parts) due to file conflicts.
Also, the two community packages are not updated regularly; the last update was on February 3rd, with the previous one having been back in May 2021, and that was only after I prodded things by posting about this on the AUR mailing list.
I'm all for finding a proper solution to this issue, but for the time being I'm against using the two community packages as default and have reverted the change by @TheDukeofErl until we can discuss it a bit more.