ValveSoftware
Problems with the Cyrillic alphabet.
Problem
In many games run through Proton, mostly developed on Unity, for some reason instead of Russian and other languages using Cyrillic characters are written question marks. It helps to specify in the startup parameters: HOST_LC_ALL=$(echo $LANG) %command%
System Information
- GPU: GTX 1660TI
- Kernel version: 6.14.6
- Proton version: Proton 10, 9 and more.
Possible solution
I think this should be solved so that you don't have to enter additional startup parameters. I'm not completely sure if it's a Proton problem, maybe it's a Steam Linux Runtime problem.
A few games in which this occurs are Lethal Company, Genshin Impact, REPO, Broken Arrow, Among US.
Please capture logs from one of the affected games on the affected system. If this can be reproduced with a free-to-play or demo game, that would be the ideal thing to test with - that will ensure that everyone investigating this definitely has access to the same game.
The most important thing is to capture logs without the workaround (in the broken state).
If you can, it would also be interesting to capture logs with the workaround, but please make it as obvious as possible what exact workaround was used, and which log is which!
To get a Steam Linux Runtime log, please set environment variable STEAM_LINUX_RUNTIME_LOG=1: see https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information. The log will appear in steamapps/common/SteamLinuxRuntime_sniper/var/slr-app*-*.log.
To get a Proton log, also set environment variable PROTON_LOG=1 and the log will appear in $HOME/steam-$APPID.log where $APPID is the numeric app ID, for example 945360 for Among Us.
It helps to specify in the startup parameters:
HOST_LC_ALL=$(echo $LANG) %command%
FYI, this can be simplified to: HOST_LC_ALL="$LANG" %command% (which is equivalent, except in strange corner-cases)
mostly developed on Unity
Unity seems to have trouble with falling back to fonts that are not at a hard-coded location: see also https://github.com/ValveSoftware/steam-runtime/issues/555 (which affected native Linux games, rather than Windows games via Proton).
For the test, I chose the game Lethal Company. I recorded logs with and without HOST_LC_ALL=$(echo $LANG). I signed the logs.
slr-app1966720-t20250516T133757.log slr-app1966720-t20250516T134052HOST_LC_ALL=$(echo $LANG).log steam-1966720.log steam-1966720 HOST_LC_ALL=$(echo $LANG).log
/home/volren/.local/share/Steam/compatibilitytools.d/proton-cachyos-10.0-20250515-slr-x86_64_v3/proton
This is not an official version of Proton. Valve's official, supported versions of Proton install into steamapps/common/Proton 10.0 (or similar) in your Steam library.
I know this problem persists the same way with Valve's version of Proton. And also with Proton-GE.
The difference in Proton behaviour is probably explained by
Language: LC_ALL None, LC_MESSAGES None, LC_CTYPE None
vs.
Language: LC_ALL ru_RU.UTF-8, LC_MESSAGES None, LC_CTYPE None
However, LC_ALL is a very big hammer: it overwrites all locale settings, which is often not a good idea. So this is probably a more intrusive workaround than would be ideal.
What are the values of your locale-related environment variables? The output of these commands would be useful information:
locale
echo "env LANG=${LANG-unset}"
echo "env LANGUAGE=${LANGUAGE-unset}"
echo "env LC_CTYPE=${LC_CTYPE-unset}"
echo "env LC_MESSAGES=${LC_MESSAGES-unset}"
echo "env LC_ALL=${LC_ALL-unset}"
(I infer from what you've already said that the answers probably include env LANG=ru_RU.UTF-8, env LC_MESSAGES=unset and env LC_CTYPE=unset, I can't tell beyond that.)
Alternatively, if you launch a game (without workarounds) adding STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 to the environment, it will record all environment variables in a new slr-app*-* log file. Unfortunately the default log file ("info" level logging) doesn't record this.
I do notice that the Steam Linux Runtime framework thinks your locales are set up in some reasonable way to be available via setlocale():
<6>13:40:53.542051: pv-adverb[194296]: I: No locales have been generated
<6>13:40:53.542140: pv-adverb[194296]: I: No locales were missing
LANG=ru_RU.UTF-8 LC_CTYPE="ru_RU.UTF-8" LC_NUMERIC=ru_RU.UTF-8 LC_TIME=ru_RU.UTF-8 LC_COLLATE="ru_RU.UTF-8" LC_MONETARY=ru_RU.UTF-8 LC_MESSAGES="ru_RU.UTF-8" LC_PAPER=ru_RU.UTF-8 LC_NAME=ru_RU.UTF-8 LC_ADDRESS=ru_RU.UTF-8 LC_TELEPHONE=ru_RU.UTF-8 LC_MEASUREMENT=ru_RU.UTF-8 LC_IDENTIFICATION=ru_RU.UTF-8 LC_ALL=
Yeah, I'm sorry. It's just that I use Fish and I spell it differently. I was looking for how it should be on Fish.
echo “env LANG=”(set -q LANG; and echo $LANG; or echo unset)
env LANG=ru_RU.UTF-8
echo "env LANGUAGE="(set -q LANGUAGE; and echo $LANGUAGE; or echo unset)
env LANGUAGE=
echo “env LC_CTYPE=”(set -q LC_CTYPE; and echo $LC_CTYPE; or echo unset)
env LC_CTYPE=unset
echo “env LC_MESSAGES=”(set -q LC_MESSAGES; and echo $LC_MESSAGES; or echo unset)
env LC_MESSAGES=unset
echo “env LC_ALL=”(set -q LC_ALL; and echo $LC_ALL; or echo unset)
env LC_ALL=unset
I hope I spelled it right.
If you try explicitly setting one of the LC_* environment variables to ru_RU.UTF-8, does that help? LC_CTYPE and LC_MESSAGES are probably the most likely to be significant.
Or, if you set LANGUAGE to some suitable value (note that its value is not intended to be the same as LANG or LC_ALL), does that help? Mine is set to LANGUAGE=en_GB:en on a system where LANG=en_GB.UTF-8, so the right value for you would probably be ru_RU:ru, or maybe something like ru_RU:ru:en.
It would also be interesting to know whether setting LC_CTYPE, LC_MESSAGES, HOST_LC_ALL and/or LANG to C.UTF-8 helps - that would clarify whether it's the Russian part or the UTF-8 part that is important.
My first guess would be that some component (but I don't know what component) is only looking at LC_ALL and maybe one of the more specific LC_* variables, but not falling back to LANG when it sees that those are unset.
The Steam Linux Runtime framework does look at LANG when necessary, so I think this would have to be a problem with Proton, some library, or the game.
I tried setting LC_ALL and running Steam through the console and that fixed the problem. It may be worth making Proton address LANG by default, since it is set in all systems. Maybe I'm being silly, but that's the way I see it.
It would also be interesting to know whether setting LC_CTYPE, LC_MESSAGES, HOST_LC_ALL and/or LANG to C.UTF-8 helps - that would clarify whether it's the Russian part or the UTF-8 part that is important.
I've tried all of the above, it doesn't solve the problem.
I tried setting LC_ALL
As I said, setting LC_ALL is a very big hammer which overwrites finer-grained settings, so it would be useful to know whether there is a less intrusive workaround available by setting one of the finer-grained variables like LC_CTYPE or LC_MESSAGES.
Having that information available would probably also help to direct a developer towards whatever component is not working as intended. We do not yet know what component that is, so clues are useful.
LC_MESSAGES=$(echo $LANG) %command% Helped to solve the problem. LC_CTYPE did not help.
OK, so some component (not clear which), presumably involved in font rendering, is looking at the sequence LC_ALL → LC_MESSAGES instead of the correct LC_ALL → LC_MESSAGES → LANG. Hopefully that gives a Proton developer a clue as to where to start looking.
Well, but it will solve the problem for those who have a Russian system. What about those who use the system in English but write in Russian or another language that uses Cyrillic?
If some component only works for the configured language, then there is probably no good solution, only bad and less-bad solutions (in which case we should choose the less-bad one). Obviously it would be better if everything supported every character set, but if it was that easy then presumably it would already have happened...
I've done what I can from the Steam Linux Runtime point of view, but I think someone who knows the details of Proton and font rendering better will have to take over from here.
Not sure if it's font rendering issue. Text can be pasted from clipboard and it renders just fine. Typing/encoding is a problem here.
I fix issue with adding this before launching the game in steam launch options HOST_LANG=ru_RU.UTF-8 HOST_LC_ALL=ru_RU.UTF-8
(Locale has to be already generated on linux system)
But it's more like a hack and it works only for locale that is specified. Hope this info helps
