SUMMARY The new merged language and regional options KCM requires "locale-gen" to handle translations. However, some distribution do not have a "locale-gen" binary available. For example, openSUSE ships all locales already generated in a specific package. This would affect also all distributions which handle locales in the same manner. That would not be a problem per se, however the need of "locale-gen" is hardcoded in the KCM. OBSERVED RESULT The KCM depends on "locale-gen" to handle locale generation. EXPECTED RESULT The KCM should not hardcode the need for "locale-gen" and should use already generated locales if available.
It's not hardcoded though, is it? you just need to add a distro specific handler, like already exists for ubuntu.
If "/etc/locale.gen" doesn't exists, the KCM doesn't call "locale-gen". Which is the case for fedora. I don't know about open SUSE, but I assume distros that come with locale pre-generated will not ship the "locale.gen" file.
(In reply to hanyoung from comment #2) > If "/etc/locale.gen" doesn't exists, the KCM doesn't call "locale-gen". > Which is the case for fedora. I don't know about open SUSE, but I assume > distros that come with locale pre-generated will not ship the "locale.gen" > file. I confirm that locale.gen is not present here. The problem is that to use glibc-based locales you need to enable support for locale-gen, which in turn enables polkit support for it via the helper. This may be undesirable if not needed (it hasn't gone through any security review, has it? Not saying it needs one, but that some may not want it). Currently you either disable glibc support altogether, or you install the helper. Of course, if all the "glibc support" does once enabled is running locale-gen, downstreams can just disable it if needed. Can you confirm or deny it is the case?
(In reply to Harald Sitter from comment #1) > It's not hardcoded though, is it? you just need to add a distro specific > handler, like already exists for ubuntu. I don't think it should be done like this, but this discussion is better suited for plasma-devel and not a bug report.
Fixed with the commits in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1891.