wrong locale set by kitty

[cvlmtg]

this happens on macOS Mojave with kitty 0.13.1

 ~ kitty --version
[347 13:06:22.614967] Failed to set locale with LANG: en_IT.UTF-8
kitty 0.13.1 created by Kovid Goyal

locale en_IT is wrong and it also it breaks nvim math functions, because e.g. str2float("3.3") returns "3.0"

[kovidgoyal]

the locale comes from your OS language settings. Change them and you will be fine.

[cvlmtg]

@kovidgoyal settings are fine. this is what happens in Terminal.app

 ~ locale
LANG="it_IT.UTF-8"
LC_COLLATE="it_IT.UTF-8"
LC_CTYPE="it_IT.UTF-8"
LC_MESSAGES="it_IT.UTF-8"
LC_MONETARY="it_IT.UTF-8"
LC_NUMERIC="it_IT.UTF-8"
LC_TIME="it_IT.UTF-8"
LC_ALL=

this is what happens in kitty

 ~ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

[kovidgoyal]

that just means terminal.app is using a different technique to deduce the locale, which happens to work on your system.

[kovidgoyal]

oh and the relevant function in kitty code is cocoa_get_lang() if you think there is a bug in that, feel free to submit a patch, I can see no bug.

[eelcocramer]

I also got this issue and fixed it by setting LANG to en_US in my shell configuration (config.fish, .bashrc, etc).

cocoa_get_lang() resolved en_NL.UTF-8 on my system. I also tried setting LANG to en_US.UTF-8 but I got the same results as mentioned in the initial issue.

[tallakt]

I'm having this as well. It's pretty annoying, if I'm not able to fix this, I'll have to find another terminal. I did not find a fix for this anywhere also, so perhaps some action should be taken on behaf of kitty devs? iTerm works out of the box, as does the built in terminal app

[wookayin]

As of 0.16.0, Kitty sets LC_CTYPE='UTF-8' which is wrong. (iTerm2, Terminal do not)

[kovidgoyal]

No, it doesn't. grep the codebase for LC_CTYPE

[KimonHoffmann]

I also experience the invalid setting of LANG (en_DE in my case) and LC_TYPE (UTF-8) with kitty v0.17.4 on macOS. It is worth mentioning that the latter appears to be an implicit consequence of the former and is probably not an error on its own.

Apparently for some applications NSLocale gives strange results and I have not yet been able to pinpoint how and why it happens. In a "Swift Playground" in Xcode I observed the same behavior, while I got the correct values from a minimal Objective-C or Swift CLI application.

I have now helped myself with a dirty workaround, by explicitly setting the locale I want via:

defaults write net.kovidgoyal.kitty OSLocale -string de_DE

After doing that (and restarting kitty) the LANG variable contains the correct information and the stray and ill formed LC_CTYPE variable is gone.

[KimonHoffmann]

Even though the linked comments refer to iOS instead of macOS, they might still point in the correct direction:

• https://stackoverflow.com/a/47678964
• https://stackoverflow.com/a/46206511

[kovidgoyal]

According to those posts currentLocale should return only a locale kitty is localized for. kitty is not localized for de_DE, so I dont see how the issue could be that.

[KimonHoffmann]

You are right: It shouldn't.

This matches the problem description for me and all of the posters above that it doesn't. It returns en_* (en_DE in my case), which is not a valid locale identifier.

It does only return the correct identifier, when forced to do so via the defaults setting described above.

[kovidgoyal]

Well if you have a suggestion that works better, I'm all ears, as I said before, the relevant function is cocoa_get_lang() which is just a wrapper around currentLocale(). A possible alternative is to use preferredLanguages() instead of currentLocale(). Or alternately to validate the locale returned by currentLocale() by using newlocale() to construct a locale based on it.