Cannot parse locale on macOS

[ancwrd1]

Observed on macOS Catalina and Big Sur, when the LC_CTYPE envrionment variable is set to UTF-8 (seems like a default for macOS, at least in the terminal application).
The DesktopRequester fails with InvalidLanguage error.

[kellpossible]

thanks for the issue report, I'll look into it soon

[kellpossible]

@ancwrd1 Sounds like it could be an issue with our upstream dependency https://github.com/rust-locale/locale_config/ I don't have a Mac to test this properly, would you be happy to try that library with your environment variable and see if it is broken there too?

[kellpossible]

Considering that dependency looks close to abandoned I'd consider forking it or bringing it into this project, or finding some alternative.

[ancwrd1]

would you be happy to try that library with your environment variable and see if it is broken there too?

Tried the example from locale_config with the same issue.

Generally it depends on the setting of the terminal application, Set locale environment on startup.
By default this option is turned on.
When it is turned on the LC_CTYPE env variable is set to UTF-8 and obtaining a locale fails.
When it is turned off there is no LC_CTYPE variable set and locale_config detects the locale as en-NL (language set to English, region set to Netherlands).

So to my understanding the fix would be to ignore the LC_CTYPE method if it doesn't contain a proper language-region prefix. Or perhaps don't use it at all on macOS.

[kellpossible]

@ancwrd1 Would it be possible for you to show the output of your LC_CTYPE variable?

[ancwrd1]

Yes, here it is:

I tried it on recent macOS versions 10.15 and 11.0.

Depends on this option in the terminal application settings. It is turned on by default.

If this option is turned off the LC_CTYPE is not set. I think local_config uses macOS API to get the locale in this case.

[kellpossible]

@ancwrd1 Thanks! Iteresting ohhh it's literally UTF-8 😆 for some reason I assumed that it was some UTF-8 string that wasn't able to be parsed by the locale_config library. Makes sense though I guess, the variable represents the encoding type?

[ancwrd1]

Makes sense though I guess, the variable represents the encoding type?

Most likely, yes. So shouldn't be used on mac I guess.

[kellpossible]

locale_config appears to be fairly abandoned, if someone knows of a good alternative I'm definitely open to replacing it

[lara-rium]

could we have a tempfix for this, basically having the crate overwrite the env var (in the context of the command only ofc, we wouldnt wanna mess with user settings)?

[kellpossible]

Looks like we could perhaps integrate https://crates.io/crates/sys-locale which seems better maintained?

[ancwrd1]

Unfortunately sys-locale has the same issue: 1Password/sys-locale#32
However, I believe it's fixed at least partially.

[complexspaces]

Hi there, sys-locale maintainer here 👋. UTF-8 alone isn't a valid BCP 47 language tag, language, or modifier, its just a codeset.

As of the latest release of sys-locale, the crate no longer looks at LC_CTYPE at all so it wouldn't run into the problem presented in this issue.

With that said, on macOS sys-locale has never used the LC_ variables and instead reads your user's System Preferences with CoreFoundation APIs because that's the correct behavior on Apple platforms. It therefore wouldn't be affected by this report in any version.