Zed seems to hardcode `LC_ALL` to `en_US.UTF-8`

[Liamolucko]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

Even though my system locale is set to en_AU.UTF-8, Zed seems to be hardcoding LC_ALL to en_US.UTF-8. LC_CTYPE is also set to en_US.UTF-8, but I'm not entirely sure whether that's Zed's fault or not (more on that later). I wouldn't normally care about this since the locales aren't that different anyway, but I frequently ssh into a server that doesn't support en_US.UTF-8 and gives these warnings every time I ssh into it from within Zed's terminal:

-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
manpath: can't set the locale; make sure $LC_* and $LANG are correct

I was able to work around it by telling ssh not to forward LC_*, but this is still an issue nonetheless.

I've tried this in VSCode for comparison. When terminal.integrated.detectLocale is "on", it behaves the same way as Zed. When it's "off", LC_ALL is left blank, but LC_CTYPE is still set to en_US.UTF-8. So I'm not sure whether LC_CTYPE is being explicitly set by Zed/VSCode or by some underlying system thing - that would explain why disabling terminal.integrated.detectLocale doesn't affect it.

On the other hand, if I use Terminal.app or Alacritty, LC_ALL and LC_CTYPE are both blank and LANG is set to en_AU.UTF-8 (it's blank in Zed/VSCode).

Environment

Zed: v0.111.6 (stable) OS: macOS 14.0.0 Memory: 16 GiB Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue.

If you only need the most recent lines, you can run the zed: open log command palette action to see the last 1000.

No response

[Liamolucko]

Ok, I can confirm that LC_CTYPE isn't Zed's fault - it's also set when running scripts in Shortcuts, which definitely isn't hardcoding it:

Edit: I figured out that it's being set by Fish.

[mikayla-maki]

I'm pretty sure we are hard coding it, I've been meaning to fix it for a while! Once we're done this rewrite, I'll be overhauling the terminal and will fix this :)

[Liamolucko]

I've started looking into this. It is indeed hardcoded: https://github.com/zed-industries/zed/blob/8c3ae8b26411559adbe98229ea228cea86466284/crates/terminal/src/terminal.rs#L342-L343

Zed already has a dependency sys-locale for querying the current locale that could be used, but it returns it in a different format (BCP 47 / RFC 5646) than LC_ALL uses. So it'd have to be parsed somehow; would it be preferable to hand-roll it or add a dependency like oxilangtag?

I might also be overthinking this, since language tags seem to usually just look like en-AU - the same as LC_ALL but using - instead of _ and without the .UTF-8. So just replacing - with _ might work fine. The reason to use a dependency would be to handle more complex language tags like zh-cmn-Hans-CN (from oxilangtag's examples), and taking the bits we want to produce zh_CN.UTF-8 in that case, but I have no idea if they can actually show up as a system's locale.

Also, I think it'd make more sense to set LANG rather than LC_ALL, since LC_ALL overrides the rest of the LC_* variables which it doesn't particularly seem like Zed should be doing.

[mikayla-maki]

I think for something that uses standards, it'd be better to add a crate in general. That said, alacritty uses libc and objc, which the terminal and GPUI already pull in, so a solution like theirs would probably be good.

[Kassiee]

has there not been a fix for this yet? I'm still getting the same warning, although on linux

[zerodegress]

same issue, hope fix soon

[Xefreh]

for anyone having this issue you can add what locale you use in your zed settings

"terminal": {
    "env": {
      "LANG": "fr_FR.UTF-8",
      "LC_ALL": "fr_FR.UTF-8"
    }
  }