There are problems with the UI translations in KDevelop (as a product; this probably also concerns the KDevPlatform project). Certain UI elements never show their translation, despite the fact that the .po files provide them. Examples (not intended to be an exhaustive list), observed during testing with the en_GB and fr translations using the current AppImage download and my own local build: - the "Color Theme" menu item - the "Analyze" menu with its menu items and settings dialog entries - the "Coloring" settings in Settings/User Interface Testing command: > env LANGUAGE=foo LANG=foo /path/to/kdevelop[.appimage] This is on Linux, but the situation is actually worse on Mac where translations are completely ignored as far as I can tell. On both platforms most other applications respect the UI language requested via the corresponding KCM and/or application-specific setting (in ~/.config/klanguageoverriderc).
Thanks for filing the issue here. Though it would be better to have individual symptoms filed separately, so they can be properly tracked. There might be several roots involved, which all will need individual treatments. (And a title "issues with translations" is very generic, could be anything and thus sadly rather useless when scanning the list of bugs). On recent master and 5.2 branch, after https://cgit.kde.org/kdevelop.git/commit/?h=5.2&id=5cba8f47dbcf9e4fa46909011e86a1d6725f75a7 , I cannot reproduce the issues listed here: "Color Theme" menu item and the "Coloring" settings in Settings/User Interface are translated using the strings from the catalogs matching the locale settings, either from env var or as stored in klanguageoverriderc. If you can still reproduce the issue mentioned here
(In reply to Friedrich W. H. Kossebau from comment #1) > If you can still reproduce the issue mentioned here ... please update with your current observation, otherwise please close as resolved. One related open issue which still can be seen, but which needs being filed with KDE Frameworks as provider of logic is that translations for Qt strings are by chance not respecting the custom language switching, due to race condition with Q_COREAPP_STARTUP_FUNCTION both being used by ecm_create_qm_loader's generated code and kswitchlanguagedialog's one :/
Until 2 minutes ago I was still seeing this issue, with parts of the interface being translated, other parts not - on Linux. No more such issue on Mac, which made me realise that my Linux rig has all KF5 stuff in a sub-prefix, and a Plasma4 desktop env. available via the root. Apparently the translation subsystem picks its data where it can be found without prioritising the own prefix. It does remain curious that not all applications are affected (as far as I can tell).
(In reply to RJVB from comment #3) > Until 2 minutes ago I was still seeing this issue, with parts of the > interface being translated, other parts not - on Linux. No more such issue > on Mac, which made me realise that my Linux rig has all KF5 stuff in a > sub-prefix, and a Plasma4 desktop env. available via the root. Apparently > the translation subsystem picks its data where it can be found without > prioritising the own prefix. Tranlation catalogs are looked up via QStandardPaths::locate(QStandardPaths::GenericDataLocation, QStringLiteral("locale/") + relpath); etc. so it should follow the priorities as listed in the respective env vars (like XDG_DATA_DIRS) or the default locations, and then pick the first version found. So same like with other external resources. Given translations are not commonly overwritten/themed/personalized :) it might make sense to prioritize/hardcode the prefix. Though this might be more a matter with wild development installs, and developers usually prefer non-hardcoded things for more control. In any case, something to discuss on ki18n-related channels rather, not kdevelop specific. Thanks for quick reaction, good to have --bugs :)