Closed NightHammer1000 closed 10 months ago
Hey, are you talking about Steam games or about games that you installed manually on the desktop? Do you have some examples?
Patrician IV Is one of the Games not setting the Language correctly without the possibility to set locals.
What version of this game are you running? The one from Steam fails with Error in 'App::Initialize'
.
Edit: never mind, it worked on the third attempt
From the Steam UI it certainly does ignore the language setting, how are you launching it to make it work in German?
LC_ALL=de_DE.UTF-8 %command% does the trick for me. You need to delete the Wine Prefix tho, because once the config file is created there is no way to change it again without editing the Config File.
Another Example is a Non-Steam one. Bioshock Remastered from the Epic Store Launched through Heroic. This Game also requires that you pass LC_ALL=de_DE.UTF-8 to it.
I note that even on systems that have a glibc install supporting all locales, these title still require manual workarounds to enable specific languages.
In the case of Patrician IV setting the language from English to German downloads the German version of the game (>2GB) with all voices in German, but all messages on the screen, menus, etc, are still in English.
The language of the messages is defined in c:/users/steamuser/Application Data/Kalypso Media/Patrician 4/options.cfg
If you install the German version of the game and never run the English version before then everything works as expected.
The problem happens if you run the English version first and then switch to the German version. I would say that's a bug, and it can be worked around by removing (or editing) options.cfg
after switching versions.
None of this requires changes to the available glibc locales as far as I can tell.
Still. Is there an explicit Reason why all the Language files should be stripped? Why not give the users the Possibility to run the Desktop and Non-Steam Games in their own language? The fact that the Language Files are stripped out is something I don't get. Even the smallest Live-CD Distros like GParted and DamnSmallLinux are supplying those files.
Why not give the users the Possibility to run the Desktop and Non-Steam Games in their own language?
We believe this is possible already, and does not require the extra libc locale files. @bertogg has concluded that Pratician IV failing to switch to German is a game bug. Those typically need to be taken up with the game developer.
We aggressively reduce the size of the OS partition by removing locales, man pages, etc. This is done to leave as much space as possible for game content. We understand this is not ideal for a desktop use case.
Some of these decisions on what to include/exclude may change in the future, but in this particular case we do not see this being justified yet.
The Game was one example fixable with other means. Games like Bioshock Remasterd from the Epic Store through Herioc is one example that is not fixable otherwise.
But that issue goes even further than games. I know of at least 2 German Steam Deck users that sold their devices because Desktop Mode was unusable for them because their English is not good enough. Not every single person knows english. I do believe this is a Point you guys should really think about when selling Internationally. If you do not ship them, at least provide a Script that can pull those files from a Server.
I think there are two things here:
Whether having all locales generated is necessary to run a particular game in a particular language. That I would be interested to know in order to see what's actually happening under the hood and how we can solve it. In the Patrician IV case that doesn't seem to be the problem and in principle I would expect that you can change any game's language without having to change the locale.
Whether the OS should support running the desktop with any arbitrary locale and language. Here there are more considerations, one of them (not the only one) is that we would need all translation files for all packages, in my computer that's more than half a GB worth of files in the root filesystem.
a large portion of visual novels depend on japanese locale to be able to run. not having japanese locale in steamos is cutting out a large portion of an entire genre of game from running. these are non-steam games, but all the same it would be really great to be able to run them. please consider adding japanese locale for visual novel support.
there are a number of examples of people trying to attempt this and running into issues that require them to unlock steamos and hoping for the best.
https://old.reddit.com/r/SteamDeck/comments/u77i9m/steam_deck_japanese_visual_novels_how_change/ https://old.reddit.com/r/SteamDeck/comments/wc14gg/enable_japanese_locale_on_steam_deck/ https://old.reddit.com/r/SteamDeck/comments/v5jcbo/guide_to_changing_locale_settings_for_japanese/ https://old.reddit.com/r/SteamDeck/comments/v8375c/how_does_proton_handle_locale_emulation/
a guide on youtube someone made about unlocking the steam deck to be able to play vns on the steam deck: https://www.youtube.com/watch?v=KtiA6GaFIzM&t=3s
Non-steam game or not, running these in a sniper SLR would be the better way forward in order to avoid switching the root OS to read/write. We are working on improving locale support but that has a lot of ramifications, no ETA.
The Japanese locale can be enabled on the Deck without unlocking SteamOS. If the game's files only have ASCII characters: using HOST_LC_ALL=ja_JP.UTF-8 %command%
as launch options does the trick of setting Proton's codepage (the locale doesn't have to actually exist on the system in this case).
For games that both require the Japanese locale in Proton + have Japanese filenames: ja_JP.UTF-8 locale files can be created on a full Linux install then copied to the Deck's user directory + using a custom launch script to overwrite LOCPATH
after the Steam Runtime resets it.
(And for games that use non-English filenames but don't require changing Proton's locale: just LANG=en_US.utf8 %command%
is enough. utf8 instead of UTF-8. SteamOS bug? It also affects apps running in desktop mode.)
Non-root solution at https://gist.github.com/cfillion/4394c3b8cd051fb45721187053e92296.
I'm not from Valve and I don't decide what locales to support, I was just trying to understand the problem and give some technical context, but anyway:
I feel it is sickening that we even have to have this kind of conversation, just because some narrow minded English only speaking decision makers are a) either totally oblivious or ignorant [...] This is not true. And, you know it.
This is unnecessary.
Linux distros including SteamOS can be configured to a set of supported locales (see /etc/locale.gen and locale-gen). Hence, there is a mechanism to download or install only needed locales.
There are two things: compiling the locale definitions and actually having the translations installed. The translations are what takes most of the disk space and they come with each individual package. Also, note that the root filesystem is read-only.
We can argue all day here. The fact is that SteamOS currently Gatekeeps the Desktop Mode and certain Games to English Speakers only, only to save a few Megabytes really not worth saving if it means that half of the Device is not usable at all to non Native English speakers. Unnecessary in my eyes. I don't understand why this is a point of discussion at all. It should be a given to support all Translations if you sell worldwide. ESPECIALLY if all the Translations already exist.
I am currently thinking about forking HoloISO and modifying it from its hardware universal approach back to a Steam Deck-specific Image. Just to give the users the Option to something Valve is unwilling to give. Their Native Language and an open file system.
Like I said. I know a few people, mostly german, who were really excited about the prospect of a Portable PC with full Desktop access but canceled their order once they got to know that Desktop was English only.
Due to the changes to the kernel not being upstreamed, we currently have only two real options. SteamOS with very Lacking International functionality, and Windows, which Drivers lack important functionality like DXVA2 while also having massive Installing Problems. (Bluescreen with no Boot after APU Driver install)
Trying to run a different Distro on the Deck will give you a headache.
So, our best chance currently is to build the solution we want ourselves from the Image we already have. Because I don't see something changing here anytime soon, to be honest.
they have already acknowledged the problem and said they plan to address it. i don't know why you are acting like this is not the case. it will get done when it gets done. this is not the place to have a passive aggressive and disrespectful back and forth about it. it won't get it fixed any faster.
in the mean time, unlike any other console that is currently produced, you can unlock root and fix it yourself until it gets pushed out officially if it is a serious problem for you.
Steam Deck just launced in Asia and guess what? The desktop mode is STILL in English only. Also, it looks like some games (on Unity?) cannot display japanese language, for example RimWorld and Valheim, due to missing fonts I suppose. They both have "Verified" mark btw.
Seems like user Experience still isn't a huge priority
locale missing introduced a lot troubles for me and spends me almost a week to address them.
There is multiple solutions imo:
Another Example for Software that does not work in other Languages is the Emulator PPSSPP in Flatpak form because Flatpak does not download the Locals if it's not set. So, you are unable to set the Language of the Emulated PSP, and it always defaults to English in all Games you Launch with it.
Another Example for Software that does not work in other Languages is the Emulator PPSSPP in Flatpak form because Flatpak does not download the Locals if it's not set. So, you are unable to set the Language of the Emulated PSP, and it always defaults to English in all Games you Launch with it.
This can be workaround by:
flatpak config --set language "en;jp;fr" # change language code here, add --user if your flatpaked app is installed as user app
flatpak update # flatpak will download locales you set
Thanks. Man. Steam Deck outside the English Language really turns into a workaround machine.
flatpak config --set language "en;jp;fr" # change language code here, add --user if your flatpaked app is installed as user app flatpak update # flatpak will download locales you set
does this work even without steamos itself having japanese locale enabled?
does this work even without steamos itself having japanese locale enabled?
Locale files can be installed anywhere, they don't need to be system-wide.
just thought i might post this since it worked well for me, i just set up a debian distrobox and installed all of the locale/wine/lutris/whatever stuff in there and so far its been working perfectly for the couple of locale dependent games i've tried. from there you could probably find a way to add them as steam games if you got creative with it. it's nice because since it's all in a distrobox its all sequestered from the rest of my system, it didn't require that i unlock my os, and it should just persist as you would expect through updates.
flatpak config --set language "en;jp;fr" # change language code here, add --user if your flatpaked app is installed as user app flatpak update # flatpak will download locales you set
does this work even without steamos itself having japanese locale enabled?
yes, locale files for flatpak apps is managed by flatpak, so it's OS independent
Correction, the code for japanese is ja
, not jp
flatpak config --set language "en;ja;fr" # change language code here, add --user if your flatpaked app is installed as user app
flatpak update # flatpak will download locales you set
Please fix this, it's clear there's a necessity for this and that it isn't hars to fix it
FYI if the only thing that you want is the locale definitions you can add them yourself easily using an extension, something like this (on the Deck, as the normal non-root user):
Download glibc and and generate the locale definitions:
$ wget https://steamdeck-packages.steamos.cloud/archlinux-mirror/core-rel/os/x86_64/glibc-2.36-6-x86_64.pkg.tar.zst
$ mkdir locales
$ tar -C locales -xaf glibc-2.36-6-x86_64.pkg.tar.zst usr/share/i18n
$ mkdir -p locales/usr/lib/locale
$ for f in en_US gl_ES fr_FR ja_JP; do I18NPATH=locales/usr/share/i18n localedef --prefix locales -i $f -f UTF-8 $f.UTF-8; done
Configure the extension:
$ mkdir -p locales/usr/lib/extension-release.d/
$ echo ID=steamos > locales/usr/lib/extension-release.d/extension-release.locales
$ echo VERSION_ID=3.4.4 >> locales/usr/lib/extension-release.d/extension-release.locales
Create the extension (you can do this on your PC if you don't have mksquashfs on the Deck):
$ mksquashfs locales locales.raw
Install and enable the extension (do this on the Deck as root):
# mkdir /etc/extensions
# cp locales.raw /etc/extensions
# systemctl enable systemd-sysext
# systemctl start systemd-sysext
This should be more or less it. It should be safe but the usual disclaimers apply: this is unsupported, use with care, you're on your own, etc.
This is for the stable image, but it should work with any other, just make sure you download the same glibc package that you have on the Deck, and VERSION_ID
comes from the /etc/os-release
file.
For translation files you could use the same technique to create language packs. It's going to be more work but it can probably be automated more or less easily (a VM can help, see here for tips on how to create one). I haven't tried this at all, but it's probably just a matter of getting the relevant packages from the mirror (or reinstalling them if you're using a VM) and creating an extension with the translation files (at least /usr/share/locale
, maybe also /usr/share/help
and others?). You would need to re-create the language pack after every major OS upgrade, but you can share it with your friends.
Nice. Now the only thing that needs to be done is shipping these as a default and not forcing the user to fight around with such advanced stuff.
@bertogg can you elaborate a bit on what this does? What if i do a steamOS update? Then the version ID will change.
But whatever i does several scripts and things that complained about locale before work now.. thanks a lot.
I hope this will be embedded into release soon.
@bertogg can you elaborate a bit on what this does?
The missing locale definitions that produce the errors and warnings shown in this thread have to be compiled from the source files that describe those locales. However those files are not installed.
The steps that I listed download the original files from the repository and compile those definitions by hand. Note that the list of languages that I used (en_US gl_ES fr_FR ja_JP
) is just an example, maybe you want different ones.
After all files are ready you create a SquashFS image with an extension that, using the systemd-sysext
mechanism, makes those files appear as if they were part of the root filesystem, but without actually touching the root filesystem.
What if i do a steamOS update? Then the version ID will change.
If you update SteamOS and VERSION_ID
changes then the extension will simply be ignored and you need to create a new one. If the version of the glibc
package didn't change you can even reuse the same extension after updating the version ID:
$ unsquashfs -d locales locales.raw
$ nano locales/usr/lib/extension-release.d/extension-release.locales
$ mksquashfs locales locales-new.raw
If the glibc package changed it's better to create the extension again using the same steps.
But whatever i does several scripts and things that complained about locale before work now.. thanks a lot.
I'm happy that this was useful. If you could give a couple of examples of things that were totally broken because of the missing locales I would appreciate it. Thanks!
That's the first thing you see when opening Team Fortress 2 due to the locale files being broken and there's also no other language file on the system itself besides En US but broken and C. Also setting your keyboard language in desktop mode works by forcing it under devices > keyboard but it's still always qwerty English in gaming mode no matter what you set as device or virtual keyboard language in gaming mode. I just want to set everything to German and starting to use it properly.
Frankly we should have the ability to switch to whatever language we use, even en_UK would be nice.
That's the first thing you see when opening Team Fortress 2
I don't see anything like that when opening that game, what OS version are you using, and what changes did you make to the system?
That's the first thing you see when opening Team Fortress 2
I don't see anything like that when opening that game, what OS version are you using, and what changes did you make to the system?
I have this issue on two different versions 3.5 (Main) and the current version in the release channel. Did you by any chance did something to repair the locales or something like that?
Because the only language files on both Decks that I can test this on only have en_US and C as locales. The system is not rebuilding them by itself and there are some core components not even working to do so after you unlock the OS. You can find many more threads online about broken locales files so I'm definitely not alone with issue.
But I'm glad that you currently doe not have this issue.
Oh and I'm playing the German version of the game which tends to be why I get informed about missing locales files and this is probably true for any non English installation of this and other games.
I tried with the latest stable (20230313.1
) and main (20230327.1000
) images, it works fine in both of them, also when I set the game language to German.
I haven't repaired anything and I'm surprised that en_US.UTF-8
fails because precisely that one is installed in the system... so I'm genuinely interested to know why it fails for you. What do you see if you open a terminal and type locale
?
Please also include the output of locale -a
.
locale
(1)(deck@SteamDeck ~)$ locale
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
locale -a
(deck@SteamDeck ~)$ locale -a
C
C.UTF-8
en_US.utf8
POSIX
locale: Cannot set LC_ALL to default locale: No such file or directory
This is unexpected. Can you run strace -e file locale
?
Just retested to make sure that the issue still persists.
strace -e file locale
(deck@SteamDeck ~)$ strace -e file locale execve("/usr/bin/locale", ["locale"], 0x7fff04ab44f0 / 65 vars /) = 0 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=121875, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1953472, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3048928, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2998, ...}, AT_EMPTY_PATH) = 0 openat(AT_FDCWD, "/usr/lib/locale/de_DE.UTF-8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/de_DE.utf8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/de_DE/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/de.UTF-8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/de.utf8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/locale/de/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) locale: Cannot set LC_ALL to default locale: No such file or directory newfstatat(1, "", {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x1), ...}, AT_EMPTY_PATH) = 0 LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=de_DE.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= +++ exited with 0 +++
Ah sorry, I overlooked these earlier:
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
Yeah I can reproduce the problem now. If you go to the KDE Settings -> Regional Settings and change Numbers or something else there then the problem starts to appear.
Ah sorry, I overlooked these earlier:
LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8
Yeah I can reproduce the problem now. If you go to the KDE Settings -> Regional Settings and change Numbers or something else there then the problem starts to appear.
Yeah I tried to change the LANG to German so I could use it as a desktop replacement when I got my Deck some weeks ago due to not being able to use my main PC for the foreseeable future. But that sadly did not work at all so I opted to at least change what I can to German. And it's also really disappointing that changing the external keyboard layout in KDE does not change the external keyboard layout for gaming mode. And the virtual keyboards is already set to German.
Ok, so we have a clear way to reproduce this problem. Thanks for your help @Cederick
The short version is that touching the regional settings in desktop mode can mess up your locale setup due to the missing locale definitions. Gamescope mode should not be affected (by this at least).
Long version:
locale
, the error "Cannot set LC_ALL to default locale"
appears.This only happens if you run the game from desktop mode, Gamescope mode is not affected since it doesn't inherit the locale settings from Plasma.
I expect other programs to report similar errors because a simple setlocale(LC_ALL, "")
call fails. This means that the app's locale is not set to en_US.UTF-8 and remains set to C, so it can potentially have more consequences than an error message on the screen.
The workaround for desktop mode is to undo the locale changes, in the UI or by hand in ~/.config/plasma-localerc
(you can simply remove that file). Then restart the Plasma session.
One additional problem here is that if you made the root filesystem read-write before doing step 2 then /usr/lib/locale/locale-archive
will be lost and then you will really have a broken locale installation (you can fix it with a system update, or reinstalling glibc).
Replying to https://github.com/ValveSoftware/SteamOS/issues/794#issuecomment-1500866688
This screenshot was taken in game scope mode or non-desktop mode @bertogg.
Some Games Require that you pass LANG= %command%
or
LC_ALL= %command%
To launch the Game in the Correct Language. Some Games Default to English because thats the set System Language.
Doing this is not possible because the installed glibc was stripped of all its Language Files. Which is, in my opinion, a big no-go.
Attempting to enable a locale in /etc/locale.gen and running locale-gen results in:
This can only be fixed by reinstalling glibc via pacman.
The ability to set locales should be shipped in the stock Image. There is no reason why it shouldn't.