In D21872#481400, @davidedmundson wrote:

These translations doesn't belong to sddm

why do they belong here and not SDDM?

In T11054#188801, @hein wrote:

The work Geon and I did in GSoC had an fcitc5 backend with plans to add a second one.

I'll say firmly though that I don't like the "let's not solve our integration problems because we need to support all the things" position. If ibus has a bug, we should try to get the bug in ibus fixed. One of the problems with the Input Method community is this pattern of "there's a minor thing about XYZ that we don't like, so instead of working together we'll do our own thing". That way nothing ever gets great in the end! There's not enough manpower in this area to spread it so thinly.

T11054 should also be mentioned here, as input methods are also acting as a showstopper for certain users to even try out the Wayland.

In T11070#188649, @ltoscano wrote:

For the record: the Qt translation system is not generally used for KDE software. Even if a program does not use KI18n, the translation file is converted to the gettext format.

In T11054#188741, @bernieinnocenti wrote:

In T11054#188552, @pshinjo wrote:

I would object a stronger integration with IBus (or any of the single input method). Even within the "common" CJK input method framework, Chinese/Japanese and Korean input methods have different requirements, which is a common source of frustration why Korean IM is sometimes not working out-of-the-box.

How do Gnome users cope with these issues?

Development appears to have stalled in older IM frameworks, and thus they don't have to don't support Wayland and desktop portals. Keeping them working for a few more years might be feasible, but we might not want to focus our future efforts on them.

Shall we merge T11092 onto this or vice versa? I think those two have the same goal.

Shall we merge T11070 onto this or vice versa? I think those two have the same goal.

I would object a stronger integration with IBus (or any of the single input method). Even within the "common" CJK input method framework, Chinese/Japanese and Korean input methods have different requirements, which is a common source of frustration why Korean IM is sometimes not working out-of-the-box.

First of all, thanks for the work. Some things are passing through my mind, especially regarding classical Hangul and half-completed Hangul characters.