GNOME Bugzilla – Bug 737216
Language displays as a dash
Last modified: 2021-06-09 16:28:27 UTC
With a fresh install of Fedora 21 Alpha Workstation, if I visit the region and language panel my language is displayed as English (United States), which is correct. The user accounts panel claims that my language is —. We should never display that. I guess if accountsservice doesn't have a language stored for a user, then we should display whatever is shown in the region and language panel, no? (P.S. This has been broken for a long time; it's nothing new.)
We can determine the language only for the one already logged in user if it isn't set in the accountsservice, but we can't determine the language for other accounts. Yes, we can fix it only for the one case, which is reported, but I think the language should be shown correctly for all the users. So the question is, who is responsible for setting the language into the accountsservice? The gnome-initial-setup should be shown after first login and the language should be set into the accountsservice. But it seems to be broken probably...
Created attachment 286963 [details] [review] user-accounts: show correct language if it isn't set Determine the language for the logged in user if it isn't set in the acountsservice.
Review of attachment 286963 [details] [review]: ::: panels/user-accounts/um-user-panel.c @@ +706,2 @@ lang = g_strdup (act_user_get_language (user)); + if ((!lang || !lang[0]) && act_user_get_uid (user) == getuid ()) { *lang == '\0' for the empty string.
(In reply to comment #1) > The gnome-initial-setup should be shown after first login and the language > should be set into the accountsservice. But it seems to be broken probably... It's indeed broken in Fedora 21 Alpha Workstation, but I don't think this ever worked since on my Fedora 20 machine my language is displayed as blank and I definitely went through gnome-initial-setup. (In reply to comment #1) > We can determine the language only for the one already logged in user if it > isn't set in the accountsservice, but we can't determine the language for other > accounts. I assumed that if the user's language is not set in accountsservice, then surely it is the "system language" and you can just read it from localed? Is this not the case?
Created attachment 286982 [details] [review] user-accounts: show correct language if it isn't set The condition statement is fixed.
(In reply to comment #4) > (In reply to comment #1) > > We can determine the language only for the one already logged in user if it > > isn't set in the accountsservice, but we can't determine the language for other > > accounts. > > I assumed that if the user's language is not set in accountsservice, then > surely it is the "system language" and you can just read it from localed? Is > this not the case? We can assume it, but there is another problem that we can't change it without authorization... and if we only show it, the system language could be changed before user's first login.
Review of attachment 286982 [details] [review]: Looks fine to me.
(In reply to comment #6) > We can assume it, but there is another problem that we can't change it without > authorization... Well of course not! I don't see why that's a problem, though? > and if we only show it, the system language could be changed > before user's first login. Then the user's language would be displayed as the new system language, right? I might be missing something, but I don't see how this is problematic at all. It certainly seems preferable to displaying the system language only for the currently logged-in user, which only fixes one case of the problem.
Comment on attachment 286982 [details] [review] user-accounts: show correct language if it isn't set commit 50bed210e54f06155a3eecb9ef6e4479ee1350b6 Thanks for the review!
Created attachment 287936 [details] [review] remove dead code This lines are dead code, because act_user_get_language() returns empty string if language isn't set. We don't want to fix the condition, because cc_common_language_get_current_language is wrong for other users.
Review of attachment 287936 [details] [review]: I hate all this papering over corner cases. Anyway, this will show the dash in this case which is fine with me
Comment on attachment 287936 [details] [review] remove dead code commit 37a54b69d669f688cc9f794fded68af948b3c171
Anything else to be done here?
Would be good to fix it also for "Other Accounts", but it would be fixed preferably in g-i-s (Bug 737249) and/or in accountsservice instead, because I think it isn't fully correct to show system language here if the language is unknown... However I'm letting this open to know about.
I think we should display the system language if nothing is configured in accountsservice.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.