DrRacket uses `LC_CTYPE` to set UI language

[eigengrau]

I’ve noticed that DrRacket presents me with German translations even though I have LANG=en_US.utf8 set. The issue seems to be that DrRacket is using the value of LC_CTYPE to determine the interface language.

This is reproducible using the following locale settings (NB this is locale(1) output, so quotation indicates inherited defaults):

LANG=en_US.utf8
LC_CTYPE=de_DE.utf8
LC_NUMERIC=de_DE.utf8
LC_TIME=de_DE.utf8
LC_COLLATE=de_DE.utf8
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER=de_DE.utf8
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT=de_DE.utf8
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

When unsetting LC_CTYPE or setting it to en_US.utf8, DrRacket starts up in English.

To determine interface language, (after checking LC_ALL) LC_MESSAGES should be looked up in the environment instead of LC_CTYPE, falling back to LANG when unset.

[rfindler]

Thank you for this. Do you have a place where the intended uses of these environment variables is documented?

[eigengrau]

Locale handling is described by POSIX resp. SUS, cf. here. Alternatively, check out man 7 locale.

[spdegabrielle]

@eigengrau is this resolved?

[spdegabrielle]

is this still an issue? Please consider adding the label good first issue so it is findable:

Issues labeled good first issue in in Racket GitHub repositories

[ghost]

I spent some time digging into this issue, and it seems surprisingly complicated. From what I understand, Dr. Racket's GUI figures out what strings to display via the string-constants package, and that code figures out your language by calling system-language+country from the core Racket language. That function appears to be implemented in C; moreover, its behavior seems to have been documented and stable for over a decade at this point.

Patching the C function seems like the most straightforward approach, but doing so would break backward compatibility. Implementing some kind of shim higher up in the stack might work, but I can imagine being very surprised that Dr. Racket and Racket disagree about what language I speak. I'm not sure what the right approach is, here.

[rfindler]

It seems like system-language+country should be following the algorithm described by @eigengrau, instead of what it is currently doing.

I'm unsure of the ramifications of this change, however, and whether it is better to change system-language+country or it is better to have a different function (or a new argument that causes system-language+country to use LC_MESSAGES).

Also looks there is a docs bug; they say that it is looking at LC_TYPE but it seems to be looking at LC_CTYPE.

[rfindler]

I think it makes sense to just stop using LC_CTYPE and start using LC_MESSAGES.

[mflatt]

That makes sense to me, too.