Both Xorg and Wayland compositors use libinput, so it's probably more to do with lack of decent configuration support in your DE or WM. You can always configure libinput manually. Sway just lets you add libinput configs inline inside your sway config.
[edit]
This is probably not relevant (assuming correct wayland libinput config), since this is not where mult-lingual input transformations live. libinput just handles the physical keyboard mapping and behaviour.
On more careful reading of the parent this sounds more like a buggy input method editor.. or maybe an issue with switching between X and wayland apps.
NO! my mistake, I latched onto keyboard input and didn't think about multi-lingual. I'm guessing you mean things like pinyin, I think that's a dbus thing, which is still a thing on wayland but I don't really know anything about this... I'll get my coat.
That still boils down to a Wayland design issue, since Wayland requires each individual DE/WM to get support for such features while X only needs them in Xorg.
More like do a thing and do it once. If every WM and DE needs to do it, you have some that don't, or you have issues that are handled correctly by some DEs and not others, etc.
Snark aside, it's still orthogonal to my question. I wasn't questioning whether it should be done centralized, but why it's supposed to be part of the display server protocol/compositor.
Because the "display" server is also responsible for window management and input. Does it have to be this way? Perhaps not - but seperating window management and input is also not trivial.
Note that more complex input methods do somewhat bypass the display server and communicate via dbus instead.
Did you miss the do it well part? Nearly every unix tool does more than one thing, the alternative would be a usability nightmare.
* grep, which primarily does pattern matching has dozens of file traversal related flags that could be handled by calling it from find
* find, a tool supposed to find files for some reason has dozens of flags related to executing applications which could probably be done by using xargs
* did you know that xargs can do pattern matching and replacement on its input string? there are probably dozens of unix tools that are specialized for that
X11 eventually punted the whole thing to each individual application. For input methods like Fcitx or IBus to work reliably on modern X11 programs, you need to set envvars like the following [0]:
That seems weird complaint about Wayland, Wayland requires every server to support these features, just like X11 also requires every server to support them? Sure, there weren't that many X11 server implementations so maybe it was not so apparent, but as a protocol they seem pretty much equal in this regard.
The criticism is that Wayland duplicates a lot of effort in multiple compositors. The compositor does work that happens in Xorg and in the WM. Whereas lots of common functionality gets implemented in Xorg that WMs and DEs don't need to duplicate.
It's not a weird complaint when on X11 when something is added it generally works for everyone whereas for Wayland the different implementators are still squabbling how to accomplish basic functionality people expect from their desktop computer.
Or in other words, your comparison is like saying food and shit are basically the same thing because both are made up of similar elements.
But wayland merges more components into one server than X11 did. Therefore, there is a need for more wayland server then there was a need for X11 servers.
[edit]
This is probably not relevant (assuming correct wayland libinput config), since this is not where mult-lingual input transformations live. libinput just handles the physical keyboard mapping and behaviour.
On more careful reading of the parent this sounds more like a buggy input method editor.. or maybe an issue with switching between X and wayland apps.