Sounds like the system you're SSH'ing into is fucked. It probably doesn't have your locale generated.

@chrisduerr Does this mean I should set the LANG environment variable manually?

I can set envs section in cofiguration file to fix this, howerver iTerm2 and kitty automaticlly handled LANG env.

@chrisduerr Does this mean I should set the LANG environment variable manually?

Is your remote server takes the locale of you host upon connecting? That would be strange to be honest, usually your remote server should have its locale set, like configured in /etc/locale.conf, etc.

It seems that at least iterm is setting LANG based on the macOS system preference lang variable, which is a bit weird, but isn't that complicated from what I can see

https://github.com/gnachman/iTerm2/blob/master/sources/PTYSession.m#L2524

This is all weird, but whatever... As a workaround you could set LANG in env section of alacritty.

@chrisduerr Does this mean I should set the LANG environment variable manually?

Is your remote server takes the locale of you host upon connecting? That would be strange to be honest, usually your remote server should have its locale set, like configured in /etc/locale.conf, etc.

I think the problem lies in LC_CTYPE env being set to UTF-8, which is obviously an invalid value. The correct value should be something like 'C.UTF-8' or 'en_US.UTF-8'. Not sure if this is related to alacritty.

alacritty -vv prints:
[0.002248002s] [DEBUG] [alacritty] Using environment locale: C/UTF-8/C/C/C/C

It seems that at least iterm is setting LANG based on the macOS system preference lang variable, which is a bit weird, but isn't that complicated from what I can see

So does Alacritty. Why did you reopen this issue?

[0.002248002s] [DEBUG] [alacritty] Using environment locale: C/UTF-8/C/C/C/C

That means you have your locale set manually, which Alacritty will not override.

So does Alacritty. Why did you reopen this issue?

We don't set LANG if you look into our macOS code, that's why I've reopened it. At least I don't see that we really set it to anything.

I think the problem lies in LC_CTYPE env being set to UTF-8, which is obviously an invalid value. The correct value should be something like 'C.UTF-8' or 'en_US.UTF-8'. Not sure if this is related to alacritty.

Locale on macOS is weird, they use plain UTF-8 thing and it's common.

We don't set LANG if you look into our macOS code, that's why I've reopened it. At least I don't see that we really set it to anything.

We don't need to set LANG, we set LC_ALL after which setting LANG is pointless.

You can try the following patch, that might fix things:

diff --git a/alacritty/src/macos/locale.rs b/alacritty/src/macos/locale.rs
index 2a47ace8..6750e56d 100644
--- a/alacritty/src/macos/locale.rs
+++ b/alacritty/src/macos/locale.rs
@@ -18,7 +18,7 @@ pub fn set_locale_environment() {
         let env_locale = unsafe { CStr::from_ptr(env_locale_ptr).to_string_lossy() };
 
         // Assume `C` locale means unchanged, since it is the default anyways.
-        if env_locale != "C" {
+        if !env_locale.is_empty() && env_locale != "C" {
             debug!("Using environment locale: {}", env_locale);
             return;
         }

But this very much looks like you messed with your locale in your env and your system is broken because of it.

To make it work, I will simply set the LANG environment in the configuration file.

Building from source is too difficult for me since I am not familiar with Rust.