Changing country leads to invalid locale

[Dimitris Kardarakos]

New installation of Kubuntu 14.04 and upgraded via kubuntu-ppa. Initially, country is set to "United States". The locale settings are the following:

~/.kde/env$ cat setlocale.sh
export LANG=en_US.UTF-8
export LANGUAGE=en:el:en
export LC_NUMERIC=en_US.UTF-8
export LC_TIME=en_US.UTF-8
export LC_MONETARY=en_US.UTF-8
export LC_PAPER=en_US.UTF-8
export LC_IDENTIFICATION=en_US.UTF-8
export LC_NAME=en_US.UTF-8
export LC_ADDRESS=en_US.UTF-8
export LC_TELEPHONE=en_US.UTF-8
export LC_MEASUREMENT=en_US.UTF-8

Then, I change Country to Greece, via System Settings. Locale changes as follows:

export LANG=en_GR.UTF-8
export LANGUAGE=en:el:en
export LC_NUMERIC=en_GR.UTF-8
export LC_TIME=en_GR.UTF-8
export LC_MONETARY=en_GR.UTF-8
export LC_PAPER=en_GR.UTF-8
export LC_IDENTIFICATION=en_GR.UTF-8
export LC_NAME=en_GR.UTF-8
export LC_ADDRESS=en_GR.UTF-8
export LC_TELEPHONE=en_GR.UTF-8
export LC_MEASUREMENT=en_GR.UTF-8

As far as I know, en_GR.UTF-8 is not a valid entry. A severe loss of functionality is that accents cannot be set properly to greek vowels. Changing manually setlocale.sh to:

export LANG=el_GR.UTF-8
export LANGUAGE=en:el:en
export LC_NUMERIC=el_GR.UTF-8
export LC_TIME=el_GR.UTF-8
export LC_MONETARY=el_GR.UTF-8
export LC_PAPER=el_GR.UTF-8
export LC_IDENTIFICATION=el_GR.UTF-8
export LC_NAME=el_GR.UTF-8
export LC_ADDRESS=el_GR.UTF-8
export LC_TELEPHONE=el_GR.UTF-8
export LC_MEASUREMENT=el_GR.UTF-8

solves the issue.

My version:

Qt: 4.8.6
KDE Development Platform: 4.13.1
KDE Daemon: 4.13.1

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04 LTS
Release: 14.04
Codename: trusty

[Harald Sitter (apachelogger)]

Invalid country language combinations lead to invalid locales.

[Dimitris Kardarakos (dimkard)]

Regional settings for Greece (time, numeric, monetary) but English translation seems pretty valid to me. And it is something that worked in Kubuntu 13.10.

[Orasis (orasisdimensional)]

Various fresh installations of Kubuntu 14.04 LTS x64 lead to the same problem.
After install followed by system update (and reboot), I change nothing other than the region to "Greece".
Everything else is left to "US English", keyboard layouts etc. And reboot again.
Then if I open a terminal I get this:

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_GR.UTF-8
LANGUAGE=en
LC_CTYPE="en_GR.UTF-8"
LC_NUMERIC=en_GR.UTF-8
LC_TIME=en_GR.UTF-8
LC_COLLATE="en_GR.UTF-8"
LC_MONETARY=en_GR.UTF-8
LC_MESSAGES="en_GR.UTF-8"
LC_PAPER=en_GR.UTF-8
LC_NAME=en_GR.UTF-8
LC_ADDRESS=en_GR.UTF-8
LC_TELEPHONE=en_GR.UTF-8
LC_MEASUREMENT=en_GR.UTF-8
LC_IDENTIFICATION=en_GR.UTF-8
LC_ALL=

As mentioned by Dimitris, notice above, the en_GR -- this does not exist in fact. There is el_GR or en_GB but not en_GR.
Now if I add "Greek" to the languages and reboot the systm becomes Greek/English -- a mix of English and Greek (most Greek), although Greek is not 1st in the list.

The only solution (except editing setlocale.sh manually), is to add "British English" and set it 1st in the list.
Only then, after reboot, I get:

$ locale
LANG=en_GB.UTF-8
LANGUAGE=en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_TELEPHONE=en_GB.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION=en_GB.UTF-8
LC_ALL=

But that causes other problems when using ssh to remote computers.
It appears that setlocale.sh file, is generated (or edited) wrongly by the script that runs when changing locale settings through gui. In a way Kubuntu 14.04 so far does not "like" American English" to be 1st in the list of languages when the Country is set to "Greece" or some other (I haven't tested).

[Dimitris Kardarakos (dimkard)]

Find below the relative KDE bug, since I initially considered the issue as a KDE one:

https://bugs.kde.org/show_bug.cgi?id=335301

[Nikola Snele (n-schnelle)]

I use regional settings for Serbia and English translation and I am experiencing the same bug.

[Volkan Gezer (volkangezer)]

I also have the same problem. Using Turkish for both locale and the regional settings.

[Jonathan Riddell (jr)]

Reopening as we shouldn't allow it to set incorrect combinations if those give errors

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[pfoo (pfoo)]

This IS a bug, not an "Invalid country language combinations".
This issue is only happening when using american english as default ("preferred") language.
Using british english language while leaving country to what you want (France in my case) fix the issue

KDE locale gui settings are as follow :
- country define regional settings (time format, numeric, monetary symbol,, etc)
- languages define ... language

[Achim Bohnet (allee)]

In the case of language = ab and Country = XY I would suggest to set LC_VARIABLES as follow

a) Someone in his home country, how want's englisch as language or b)
englisch as native tongue form country AB in a foreign country):

LANGUAGE=en:xy
LANG=xy_XY.UTF-8 # e.g. el_GR or de_DE
LC_MESSAGES=en_<AB>.UTF-8 # AB one of US, GB, ...

Some LC_* would be different for case a) and b). E.g. LC_TIME but for KISS I would suggest to only set LC_MESSAGES to
english. In KF5 the is a complete new situation: each LC_* varialbe can be 'chosen/set' in the system center directly.

Note: LANG is the default for all LC_* (except LC_ALL) variables, so we only have to set LC_* that should have a value different from LANG. When not all LC vars are set explicitly, the sysadmin can supply different defaults in /etc/environment (e.g. in
the above mentioned case of LC_TIME).

Achim

[Thomas Winteler (Win-Soft) (thomi)]

Hey all

i also have that problem: using english as system language and switzerland as country.. This problems are after upgrade from 13.10 to 14.04. I compared with a 13.10 system and got it working with setting LC_* vars which have problems (thanks to Achim).

Now /etc/default/locale:

LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8

And after a restart KDE Session (also restarted lightdm):

locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_CH.UTF-8
LANGUAGE=en
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_CH.UTF-8
LC_TIME=en_CH.UTF-8
LC_COLLATE="en_CH.UTF-8"
LC_MONETARY=en_CH.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_CH.UTF-8
LC_NAME=en_CH.UTF-8
LC_ADDRESS=en_CH.UTF-8
LC_TELEPHONE=en_CH.UTF-8
LC_MEASUREMENT=en_CH.UTF-8
LC_IDENTIFICATION=en_CH.UTF-8
LC_ALL=

Hope this helps others too...

regards
thomi

[Netsurfar (minumegamail)]

I suffer from it too - LANG=en_EE.UTF-8 instead of LANG=et_EE.UTF-8. And Chrome & Chromium seem to be unable to make special characters that english alphabet doesnt have, might this be related to this issue?

[m.eik michalke (m.eik)]

same here, updating to recent PPA packages for 4.13.1 disabled l10n, most KDE applications are in english now. i was also made a new desktop folder ("Arbeitsfläche") with distorted umlaut characters. this is a serious bug.

not *all* KDE programms are affected (e.g., RKWard still starts up in german!).

[joneall (joneall-alumni)]

Same here, in France, since latest dist-upgrade.

[Ruman Gerst (mrboese)]

I'm affected, too. If I set setlocale.sh manually, only GNOME/GTK programs are german (And my date and time formats are correct) - but all Strings are on english.

Very critical bug!

[Miharu Amakase (miharu-amakase)]

Not quite sure if my problem is connected to this one, as I DO NOT WANT to have anything set to English, neither the system language, nor the country, thus no mixed environment.

However, when I updated my Kubuntu Trusty Tahr (64 bit) with the latest updates from the Kubuntu repositories here on Launchpad and rebooted afterwards, my entire KDE, including all applications, was changed to English all of a sudden!

When I opened System Settings -> Locale, I got the following error message:

"You have the language with code 'ja' in your list of languages to use for translation but the localization files for it could not be found. The language has been removed from your configuration. If you want to add it again please install the localization files for it and add the language again."

Following this, only "American English" was left in the language list on the right.

I've then tried to add Japanese again, and while the adding itself seemed to work and it appeared in the list on the right, when I clicked the "Apply" button, I got exactly the same error as above, and Japanese was removed again from the list.
I've rebooted after that and tried adding Japanese once more, but nothing changed: the adding itself worked, but clicking on "Apply" once more got me the error message from above, and Japanese was removed again, leaving me with "American English" only.

I've also tried manually editing /etc/default/locale - but that didn't do anything.

Trying to reinstall the "locales" package in Synaptic got me some error messages:

Get:1 http://archive.ubuntu.com/ubuntu/ trusty-updates/main locales all 2.13+git20120306-12.1 [2695 kB]
Fetched 2695 kB in 1s (1603 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en",
        LC_ALL = "",
        LC_PAPER = "en_JP.UTF-8",
        LC_ADDRESS = "en_JP.UTF-8",
        LC_MONETARY = "en_JP.UTF-8",
        LC_NUMERIC = "en_JP.UTF-8",
        LC_TELEPHONE = "en_JP.UTF-8",
        LC_MESSAGES = "en_JP.UTF-8",
        LC_COLLATE = "en_JP.UTF-8",
        LC_IDENTIFICATION = "en_JP.UTF-8",
        LC_MEASUREMENT = "en_JP.UTF-8",
        LC_CTYPE = "en_JP.UTF-8",
        LC_TIME = "en_JP.UTF-8",
        LC_NAME = "en_JP.UTF-8",
        LANG = "en_JP.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 173420 files and directories currently installed.)
Preparing to unpack .../locales_2.13+git20120306-12.1_all.deb ...
Unpacking locales (2.13+git20120306-12.1) over (2.13+git20120306-12.1) ...
Processing triggers for man-db (2.6.7.1-1) ...
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up locales (2.13+git20120306-12.1) ...
Generating locales...
  en_AG.UTF-8... up-to-date
  en_AU.UTF-8... up-to-date
  en_BW.UTF-8... up-to-date
  en_CA.UTF-8... up-to-date
  en_DK.UTF-8... up-to-date
  en_GB.UTF-8... up-to-date
  en_HK.UTF-8... up-to-date
  en_IE.UTF-8... up-to-date
  en_IN.UTF-8... up-to-date
  en_NG.UTF-8... up-to-date
  en_NZ.UTF-8... up-to-date
  en_PH.UTF-8... up-to-dat...

[m.eik michalke (m.eik)]

still broken in the 4.13.2 packages

[pfoo (pfoo)]

Just to make it clear, it is not a kde bug but a kubuntu bug. Updating kde won't fix it.
The incriminated file is ~/.kde/env/setlocale.sh (for those who want to manually hotfix it for now)

[m.eik michalke (m.eik)]

today the 4.13.1-0ubuntu0.1 packages seem to have arrived in the standard ubuntu repos. this successfully introduced the bug on a productive machine where i have purposely *not* activated the kubuntu-PPA repositories.

[m.eik michalke (m.eik)]

seems to be fixed in 4.13.2-0ubuntu0.1~ubuntu14.04~ppa1 (you have to manually set the locale settings again after upgrading). this should *really* be backported! this bug should not have been shipped with regular packages in the first place.

[Orasis (orasisdimensional)]

it's been a while... and this is still not fixed. Or am I wrong ...

Kernel: Linux 3.13.0-32-generic (x86_64)
Compiled: #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014
Default C Compiler: GNU C Compiler version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
Distribution: Ubuntu 14.04.1 LTS
Qt: 4.8.6
KDE Development Platform: 4.13.2
kde4-config: 1.0

Again.
1) Americal English is the only prefered panguage in the list.
2) Country set to Greece.
3) Reboot.
4) type "locale" in terminal, you get this:

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_GR.UTF-8
LANGUAGE=en
LC_CTYPE="en_GR.UTF-8"
LC_NUMERIC=en_GR.UTF-8
LC_TIME=en_GR.UTF-8
LC_COLLATE="en_GR.UTF-8"
LC_MONETARY=en_GR.UTF-8
LC_MESSAGES="en_GR.UTF-8"
LC_PAPER=en_GR.UTF-8
LC_NAME=en_GR.UTF-8
LC_ADDRESS=en_GR.UTF-8
LC_TELEPHONE=en_GR.UTF-8
LC_MEASUREMENT=en_GR.UTF-8
LC_IDENTIFICATION=en_GR.UTF-8
LC_ALL=

Congrats.

[xxvirusxx (condor20-05)]

When try to change language in /home/.kde will be created a env folder wich have a file setlocale.env with incorect information about language.

Orasis

Do this:

sudo nano /home/your_username/.kde/env/setlocale.sh

Correct all from file the same
For example if you want el_GR setlocale.sh need to be this, and save it

export LANG=el_GR.UTF-8
export LANGUAGE=el_GR
export LC_NUMERIC=el_GR.UTF-8
export LC_TIME=el_GR.UTF-8
export LC_MONETARY=el_GR.UTF-8
export LC_PAPER=el_GR.UTF-8
export LC_IDENTIFICATION=el_GR.UTF-8
export LC_NAME=el_GR.UTF-8
export LC_ADDRESS=el_GR.UTF-8
export LC_TELEPHONE=el_GR.UTF-8
export LC_MEASUREMENT=el_GR.UTF-8

Then run in Terminal (Konsole)
sudo sh /home/your_username/.kde/env/setlocale.sh

Now if you type "locale" in Terminal will be no error

Also if you need to have all menu aplications translated you ned to do this

sudo nano /etc/default/locale

Paste and save

LANG="el_GR.UTF-8"
LC_NUMERIC="el_GR.UTF-8"
LC_TIME="el_GR.UTF-8"
LC_MONETARY="el_GR.UTF-8"
LC_PAPER="el_GR.UTF-8"
LC_NAME="el_GR.UTF-8"
LC_ADDRESS="el_GR.UTF-8"
LC_TELEPHONE="el_GR.UTF-8"
LC_MEASUREMENT="el_GR.UTF-8"
LC_IDENTIFICATION="el_GR.UTF-8"

Reboot your PC. After restart a popup notification will be displayed with this message Incomplete language .....press on it and install missing files.

That is

[xxvirusxx (condor20-05)]

I forgot

If you don`t have setlocale.sh you can run all commands in Terminal

export LANG=el_GR.UTF-8
export LANGUAGE=el_GR
export LC_NUMERIC=el_GR.UTF-8
export LC_TIME=el_GR.UTF-8
export LC_MONETARY=el_GR.UTF-8
export LC_PAPER=el_GR.UTF-8
export LC_IDENTIFICATION=el_GR.UTF-8
export LC_NAME=el_GR.UTF-8
export LC_ADDRESS=el_GR.UTF-8
export LC_TELEPHONE=el_GR.UTF-8
export LC_MEASUREMENT=el_GR.UTF-8

[Calabacin (raulgarciag)]

This bug is really annoying and still happens. I had to manually fix my new installation... After digging on the internet to find this bug report.

http://askubuntu.com/questions/501181/how-to-change-fix-systems-locale-when-you-setup-in-a-language-not-official-in-y/518149#518149

[David Fendrich (gurgeh)]

This just happened to me. It screws up all the programs, including Konsole, Emacs and Chrome, so I cannot type unicode characters in any of them. My /etc/default/locale is good, but the setlocale.sh (which it took a lot of bug hunting to track down) overrides my choices with a locale that does not exist and cannot be generated.

[dotancohen (dotancohen)]

To illustrate the severity of this bug, one cannot even use simple Perl one-liners:

<pre>
$ perl -pi -e 's/ \t/\t/g' foo.csv > bar.csv
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en:he:en",
        LC_ALL = "",
        LC_PAPER = "en_IL.UTF-8",
        LC_ADDRESS = "en_IL.UTF-8",
        LC_MONETARY = "en_IL.UTF-8",
        LC_NUMERIC = "en_IL.UTF-8",
        LC_TELEPHONE = "en_IL.UTF-8",
        LC_IDENTIFICATION = "en_IL.UTF-8",
        LC_MEASUREMENT = "en_IL.UTF-8",
        LC_TIME = "en_DK.utf8",
        LC_NAME = "en_IL.UTF-8",
        LANG = "en_IL.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

$ wc -l bar.csv
0 bar.csv
</pre>

Great, so where is en_IL.UTF-8 set? I have no idea:
<pre>
$ pwd
/home/dotancohen
$ grep -r en_IL *
$
</pre>

Now that I've found Calabacin's linked issue on AskUbuntu.com, I know that it is here, but as we've seen Grep cannot find it:
<pre>
$ cat ~/.kde/env/setlocale.sh
export LANG=en_IL.UTF-8
export LANGUAGE=en:he:en
export LC_NUMERIC=en_IL.UTF-8
export LC_TIME=en_IL.UTF-8
export LC_MONETARY=en_IL.UTF-8
export LC_PAPER=en_IL.UTF-8
export LC_IDENTIFICATION=en_IL.UTF-8
export LC_NAME=en_IL.UTF-8
export LC_ADDRESS=en_IL.UTF-8
export LC_TELEPHONE=en_IL.UTF-8
export LC_MEASUREMENT=en_IL.UTF-8
</pre>

Where did those definitions come from?

[dotancohen (dotancohen)]

Please excuse the use of '>' with Perl. That was stupid of me, but it does not change the fact of the matter that the locales are invalid!

[VladVons (vladvons)]

you can try to reinstall locales with apt-get install --reinstall locales
or read more here http://linux-ubuntu.info/en/how-to-change-the-default-locale/

[Pavel (pavel-vyazankin)]

Kubuntu 14
Can't workaround this TERRIBLE bug until added ~/.bashrc correct locale variables.

More than a year for a simple bug with locales... are you serious?!

[jpiesing (jon33040)]

Moving around between countries in Europe (UK <-> Belgium <-> France <-> Germany <-> Switzerland <-> Austria), I get all sorts of weird results for locales when I change the timezone from UK to anything else and back again.

[Achim Bohnet (allee)]

Fixed in 16.04 LTS (Xenial).

You can select the

region (with defines the default)

and if you don't like default settings, you can set individually:

Numbers
Time
Currency
Measurement units
Collation and Sorting

Which results in settings like:

(0)ach@allee:~$ cat .config/plasma-localerc
[Formats]
LANG=en_US.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_TIME=en_GB.UTF-8
useDetailed=true

[Translations]
LANGUAGE=en_US
(0)ach@allee:~$ cat .config/plasma-localerc
[Formats]
LANG=en_US.UTF-8

[Translations]
LANGUAGE=en_US
(0)ach@allee:~$ cat .config/plasma-localerc
[Formats]
LANG=en_US.UTF-8

[Translations]
LANGUAGE=en_US

[Bast1aan (bast1aan)]

Unfortunately, this bug occurred to me again in Kubuntu 18.04 / KDE Plasma 5.12.7 when setting language to English and region to Netherlands. Locale is then set to en_NL.UTF-8 which is invalid, causing rendering issues in konsole, screen, for example.

[Ioannis Iliadis - Ilousis (ioannis.ilousis)]

Also in Kubuntu 20.04 with KDE Plasma 5.18.5. Editing of /etc/default/locale, then restart, fixed issue.

[Lars Müller-Stumpf (auralucario)]

Apparently still not fixed, just happened to me with a fresh install of kubuntu 21.04. I live in germany and want my system language to be english.

Changing the language from American English to British English, manually adding "LC_ALL", "LC_CTYPE" and "LC_MESSAGE" to the /etc/default/locale file, running sudo update-locale and sudo locale-gen and then restarting the pc fixed the issue.

For me, this bug prevented Anki from launching (Error: "Anki needs an UTF-8 locale"). Pretty minor in comparison to what others are experiencing but still.

This bug is now more than 7 years old, could someone please at least assign this bug to a dev?

[Uqbar (uqbar)]

Nope, current policy is to wait until it either vanishes or makes no sense at all any more or simply expires.
I moved to a different distro some time ago just because of these annoyances.

[Erich Eickmeyer (eeickmeyer)]

Rather than bash Kubuntu/Ubuntu, let's do something constructive.

Has this been reported upstream to KDE (https://bugs.kde.org/)? If not, then that needs to be done. Until then, this bug is incomplete. Please report back with the upstream bug report linked.

[Gunnar Hjalmarsson (gunnarhj)]

To everyone affected by this bug: Please note that it's an upstream KDE bug. In other words it's not optimal to report it to a distro like Ubuntu/Kubuntu as in this bug; it's the upstream KDE maintainers you need to convince that the issue is worth prioritizing.

[Uqbar (uqbar)]

If you are certain it is an upstream bug, just report it upstream, whatever "upstream" means (KDE, libc, Debian...).

If you are not, please don't ask people to move a bug to the desk of other dev teams.

I have been using kubuntu, I have been experiencing this bug (7+ years ago), I said I was affected by it too.

I would say the Ubuntu team should try to reproduce and triage it. Or ignore it.

[Erich Eickmeyer (eeickmeyer)]

Uqbar,

Your tone is not welcome here. I'm a bug supervisor here, and have determined it's an upstream bug. It's not a matter of changing it "to the desk of other devs", but to make sure it's reported properly.

My logic here: there's no reason to believe this is an Ubuntu/Kubuntu-only bug since there are no modifications to the source code for this, meaning it's an upstream KDE bug. Contrary to your belief, the teams here don't do all of the development. Ubuntu is a "distribution" of software, not a "development" of software. So, please, report this upstream and report the bug number back here.

I can't reproduce because I don't know what I'm looking for. And even if I did, I wouldn't know how to fix it because I'm a packager, much like a majority of those who work on this distribution (and all volunteer, mind you, meaning NOT PAID).

[Lars Müller-Stumpf (auralucario)]

Hi Erich,
thanks for supervising the bug reporting here. I think everyone (except a few..) appreciate people like you who take the time out of their day to put effort towards maintain a project like this. :)

Regarding the bug: It has been outlined pretty clearly what needs to be done in order for this bug to appear. Install a fresh copy of (in this case) Kubuntu, and change the Region (under System Settings -> Regional Settings -> Formats -> Region) from English to something else, and your locale breaks immediately. In my case, the variables "LC_ALL", "LC_CTYPE" and "LC_MESSAGE" were unset in the /etc/default/locale file, resulting in a lot of program errors (Anki reported a broken UTF-8 and would crash before being able to start in my case).

I could report this bug upstream if you don't want to do that or if that's not your "job"/task, but I'm not sure how to do that. What would be the next upstream package to report to even?

[Erich Eickmeyer (eeickmeyer)]

My job is not to report every bug that lands here upstream, but to direct those reporting the bug where to properly report it.

The package in this case is kde-runtime and can be found at https://bugs.kde.org. However, I did notice that Herald Sitter (apachelogger), who *is* a KDE dev, marked this bug as "Won't Fix" initially, saying "Invalid country language combinations lead to invalid locales.". Therefore, this might get the same treatment upstream. If that's the case, then this bug will be marked accordingly, or perhaps even as "Opinion" since it leads to a broader discussion but wouldn't be considered a bug anymore.

In order to know that, though, the bug needs to be reported upstream at the link I posted in the previous paragraph and then the bug link needs to be posted here. At that point, Launchpad has a mechanism to automatically "watch" that bug report and update this one with the status of that one. I hope that makes sense.

Basically, it remains tracked here (therefore still our problem) but also gets the attention of the people who can triage and fix it.

[Uqbar (uqbar)]

I appreciate a lot the work done by the (K)Ubuntu team, this is why I was here to try to help.

I am a plain simple KUbuntu user, just like many others.
I use KUbuntu, not KDE alone nor Debian.
I encountered a bug and I tried to reproduce it in order to report it properly on (K)Ubuntu bug tracking. A report matching my situation was already there, so I joined the crowd.

I have no idea whether this is a bug coming from KUbuntu, KDE, Debian, GnuLibC or the kernel: I am not a dev at (K)Ubuntu nor a (re)packager, just a miserable simple user (MSU).

Someone else, the original triager, has more knowledge than I have (quite easy) and knows/understands/checks that this is a real bug that's not been introduced by (K)Ubuntu itself but by "someone else"(tm), aka an "upstream" package.

So the bug needs to be filed upstream, not here. Cool. As the best knowledge about the bug is in the original triager heads, he/she asks the MSU to file the bug upstream.
So the MSU goes upstream, registers a new user (he won't even likely need any more) and goes through the process of the bug filing. By starting with a fresh new installation.

This means that the subsequent bug triaging steps are in the MSU hands, which has much less knowledge than the original triager.

Long story shorter, it takes more time and resources by the MSU and by the upstream developer team to handle the bug, just to avoid the original triager a little bit more work: report the bug upstream with all the details she/he already has got.

Does this make any sense?
Does this make any sense after 7+ years?

I am not really sure.

[Lars Müller-Stumpf (auralucario)]

I just checked upstream and found that this bug already has been reported there some time ago, marked as "resolved donwstream": https://bugs.kde.org/show_bug.cgi?id=335301

Im confused. The bug still persists and there are a plethora of other linked bug reports branching off of that bug report i just linked, either on this or KDE's bug tracking site. What is the current state of this bug then? :D

[Erich Eickmeyer (eeickmeyer)]

Lars, thanks for investigating.

I'm pretty sure the "resolved downstream" status is referring to this bug being marked as "Won't Fix" by Herald above. The patching mentioned is no longer there, so it's definitely not a Kubuntu issue.

Based on that, and that this bug was initially filed against Kubuntu 14.04 (which used Plasma 4 and an *entirely different codebase*), I'm going to close this bug as "Won't Fix".

What we need here is an entirely new bug report. While this bug report may be related, it's not the same bug since it's no longer working with the same code. Please type "ubuntu-bug kde-runtime" in a terminal window and follow the instructions to file a new bug, then please file a new bug upstream at https://bugs.kde.org to alert the upstream as well.

Part of bug reporting is having the willingness to put in work to help report it to the right place(s) to help resolve the issue, so if you are not willing to do that, please do not report a new bug and please do not comment on this one.

[Lars Müller-Stumpf (auralucario)]

I just opened a new report as requested here: https://bugs.kde.org/show_bug.cgi?id=441468
I couldn't find a kde-runtime package, so I just reported it under kde.