GNOME Bugzilla – Bug 671528
No Language Selection/Language List in GDM
Last modified: 2018-05-24 10:42:16 UTC
there is no Language Selection in GDM. Specially in Live ISO, it can be very helpful to allow language selection. Version-Release number of selected component (if applicable): gdm-3.2.1.1-15.fc17 gnome-shell-3.3.90-1.fc17 control-center-3.3.90-1.fc17 How reproducible: Everytime Steps to Reproduce: 1. run gdm from installed system or boot from Live ISO 2. 3. Actual results: No language selection in GDM. Non-English user need to Login first and then switch language if installation done in English. Expected results: there can be language selection from https://bugzilla.redhat.com/show_bug.cgi?id=681750#c24 "When non-english speaking users can be lucky enough and reach the Applications->system tools->system settings->Region and language"
Unstreamed the Fedora Bug: https://bugzilla.redhat.com/show_bug.cgi?id=681750
I have a non-English-speaking guest and wanted to let her use my Fedora 16 XFCE desktop. There's no way to set a user-specific language and I don't want to change the system default. GDM used to have a language selector on the login screen.
Dear GDM maintainers, it's been a while that the old gdm 2.x has been replaced by gdm 3.x. I understand that GNOME developers have removed the language selector in gdm as part of a new, more Apple-like or tablet-oriented design philosophy and expect users to set the language in GNOME control center. While this might work perfectly fine on MacOS X, it fails completely on classical Unix systems and Linux. The reason is simple, there is no default desktop like there is on MacOS X and thus no guarantee there is a control center available to set language. We're deploying Debian Linux at a physics department at a large university in Germany with around 150+ desktop machines and hundreds of users with different native languages and preferences for their desktops. We have users which don't speak German and we have some which don't speak English, we therefore cannot set a default language and hope for the users to find their way in the control center to set the language to their needs. Also, since many users actually don't use GNOME (and neither KDE nor XFCE), they don't have a control center to set their display language. Therefore, it is mandatory for the display manager to have a selector for *both* the default language and session *per* user. And, please store this information in the user's home directory (using .dmrc), the way AccountsService is doing it is a very very bad idea. Users always have to select their default session and language when they change their computer (something students do on a daily basis when using the computer pools), because AccountsService stores this information in /var/lib/AccountsService/users/$USER. Unless these things are fixed, gdm 3.x is unfortunately completely unusable for a corporate environment and most users will probably resort to lightdm. Cheers, Adrian
This makes it impossible to use GNOME's login for any kind of shared computers, e.g. workstations in schools or universities, with users that don't only speak this one dominant default language.
I've the very same problem as John Paul Adrian Glaubitz, also Physics department, but fewer users. This is great, we have to use GDM as the other display managers don't support GNOME's way of locking the screen (and I totally agree with GNOME here, that the login manager should be responsible), but on the other hand people are forced to edit their bashrc files to enable non-english languages. Please reimplement this feature.
language should be settable from control-center after the user logs in. there shouldn't be any need to edit .bashrc
(In reply to Ray Strode [halfline] from comment #6) > language should be settable from control-center after the user logs in. > there shouldn't be any need to edit .bashrc Assuming that everyone uses GNOME as their desktop environment, yes. But that does not reflect reality, unfortunately. We have several hundred users and while most users use MATE, many users prefer using KDE, XFCE, GNOME or even tiling window managers. Your scenario also assumes that everyone who logs into GNOME speaks English or the language of the host country (imagine a university with international guests) which often also isn't the case. I really don't think that moving the language settings out of GDM into GNOME was a smart move. It's very impractical and short-sighted. Adrian
(In reply to Ray Strode [halfline] from comment #6) > language should be settable from control-center after the user logs in. > there shouldn't be any need to edit .bashrc And even when they are using GNOME3, it doesn't work for us from the control centre as we have a read-only NFS4 rootfs (just tested it).
(In reply to Olaf Leidinger from comment #8) > And even when they are using GNOME3, it doesn't work for us from the control > centre as we have a read-only NFS4 rootfs (just tested it). What exactly do you mean with "it doesn't work"? The language and session selection for login is written to /var/lib/AccountsService and /var should also be mounted writable as many applications assume that. lightdm does allow selecting the session and language from the login screen (albeit the fact that storing and restoring that information is currently completely broken in lightdm which is why we resorted to kdm) but it also uses /var/lib/AccountsService as the venerable $(HOME)/.dmrc was abandoned with the argument that it requires the display manager to have read access to the user's home directory. Granted, they want to replace AccountsService with SSSD sometime in the future which would bring back the network transparency that the .dmrc file had due to the fact it was stored in the user's home directory. Adrian
Off-topic, but well: /var is on tmpfs, manages by tempfiles.d. Our machines are as stateless as possible (except selected files as fstab, xorg.conf, and selected directories from /var as the font cache and gdm stuff). So another directory needs to be dealt with - I forgot AccountsService.
*** Bug 768376 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdm/issues/94.