Status in Connection Details hangs

[Ralph Scharpf]

$ lsb_release -rd
Description: Ubuntu Trusty Tahr (development branch)
Release: 14.04

$ apt-cache policy plasma-nm
plasma-nm:
  Installed: 0.9.3.3-0ubuntu1
  Candidate: 0.9.3.3-0ubuntu1
  Version table:
 *** 0.9.3.3-0ubuntu1 0
        500 http://de.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status

When configuring the connection on (new) network manager interface (via system tray) to use a static IPV4 address and then do a disconnect /connect the status in the Detail page is reported as "preparing to connect" while the nm-tool says that the connection is established. I would expect that the connection status is reflected as "connected".

A little issue I investigated while switching my system to English in order be able to give a better bug report:

I switched my system from German to English by selecting in locale settings "Country" to UK and on the "Languages" page I selected "British English" as the first language beside german. After logging out and in again the applications were in English but the Plasma wasn't. Then I tried update-locale to switch the locale and rebooted. Even this did not change the language! Only by removing German from the options in the "Languages" page I was able to get a fully English desktop.

I can not figure where to report this bug. Perhaps you can help addressing it. Sorry for that.

[Harald Sitter (apachelogger)]

Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. While we appreciate your issue, it would be better if it was tracked at https://bugs.kde.org, so that the KDE developers can deal with this speedily and have direct communication with you as the reporter for more effective debugging.

ALSO

The language thing I am going to explain as follows: en_GB in KDE is a distinct language, meaning if something is not translated to en_GB the list of configured languages will be searched until a language provides a translation. Failing to find a translated language it would then fall back to en_US.

So what happens is:
- looks for translation in en_GB
- not translated in en_GB, trying next in list
- looks for translation in de
- de translated, using de translation

This is very much expected behavior right now. If you want to make sure that you get english text, I suggest you use en_US as that is the base language used for all strings in the actual source code (i.e. en_US is always complete).