GNOME Bugzilla – Bug 690750
doesn't change locale completely
Last modified: 2016-09-13 12:36:17 UTC
I'm using the Fedora 18 beta, just installed and completely updated. In System Settings I chose 'Region & Language' and changed the format to Dutch. I left the language at English. However, after rebooting it seems the locale didn't change completely: [alexander@linux ~]$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC=nl_NL.utf8 LC_TIME=nl_NL.utf8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=nl_NL.utf8 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=nl_NL.utf8 LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= For example, because LC_PAPER is still left untouched at en_US, GNOME Web still defaults to printing at US Letter paper size instead of A4.
After a lot of searching I finally figured out an easy way [1] to change the locale manually. This solution worked for me on Fedora 18. [1] http://forums.fedoraforum.org/showpost.php?p=1509795&postcount=13
Fixed in gnome-3-6 and master. I'm leaving this opened as we would need to show the selected paper size in the Region tab as well, and it's about to undergo some UI changes.
Bastien, I saw that you now let gnome-settings-daemon set also LC_PAPER. Maybe you should make the corresponding change in gnome-region-panel-system.c. But aren't a few locale categories still missing? In Ubuntu the regional formats selection results in these LC_* variables being set: LC_NUMERIC LC_TIME LC_MONETARY LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION As regards paper size, please note that many applications seem to not honor the LC_PAPER variable. Therefore, in Ubuntu we also set the PAPERSIZE variable to either "a4" or "letter" based on the dimensions in the LC_PAPER locale.
None of LC_NAME, LC_ADDRESS, LC_TELEPHONE, LC_IDENTIFICATION have any practical relevance. We set all the others. GTK+ uses LC_PAPER to find the default paper size for the print dialog. I don't think we want to start setting random other env vars for the same purpose. If applications don't respect LC_PAPER, they need to be fixed.
On 2013-03-17 19:16, Matthias Clasen wrote: > None of LC_NAME, LC_ADDRESS, LC_TELEPHONE, LC_IDENTIFICATION have any practical > relevance. We set all the others. Can't say I'm of another opinion; just compared with what we currently do in Ubuntu. No big deal. > GTK+ uses LC_PAPER to find the default paper size for the print dialog. I don't > think we want to start setting random other env vars for the same purpose. If > applications don't respect LC_PAPER, they need to be fixed. Well, such a statement does not make the users happier. And PAPERSIZE is not exactly a random variable: http://linux.die.net/man/5/papersize It would be an easy fix.
I noticed that on my Fedora installation, where the libpaper package is not present, setting LC_PAPER is sufficient for LibreOffice. It seems that it's libpaper and /etc/papersize (they are present in Debian/Ubuntu) that trigger a need to set the PAPERSIZE environment variable. Otherwise setting PAPERSIZE seems to be a no-op.
Reading that man page doesn't exactly make me more sympathetic to PAPERSIZE: /etc/papersize, PAPERSIZE env var, libpaper (!) - all just to support something that is already covered by LC_PAPER. Lets just stick with the standards here.
Yeah, I tend to agree now. Given that the libpaper package is included in Ubuntu, we need to play with PAPERSIZE to prevent buggy behaviour. But to be honest I don't know whether libpaper adds any advantages. It does serve applications directly with the paper size (e.g. "a4" or "letter"); the paperconf command gives you that. The question is whether there are any (significant) applications that query paperconf but lack the ability to query LC_PAPER for the dimensions and make conclusions from that.
I found libpaper in my fedora system too, but nothing depended on it... the gtk printing support has extensive papersize api too (which uses LC_PAPER for getting the default)
Created attachment 241471 [details] locale2papersize So libpaper may show up on Fedora too? ;-) One possibility may be to check for the existence of libpaper and set PAPERSIZE if it's there. It's easy to accomplish, btw. In Ubuntu we currently make use of the attached script.
Since this bug is still open, I think opening another one would be a duplicate. In fact this might be considered RFE. In fact locale settings is still missing to set LC_CTYPE. I've opened a bug report for fedora here: https://bugzilla.redhat.com/show_bug.cgi?id=1374888 Apart from Fedora specific issues, gnome-control-center should set LC_CTYPE too. As ibus handles the input method, it needs to know the input language, in my case, it is pt_BR . Adding LC_CTYPE=pt_BR.UTF-8 to /etc/locale.conf fixed my problems with C cedilla (ç). Default us input renders deadkey '+c as ć . So, my request is to make control center to set LC_CTYPE when Formats is different from Language. In my case, I use language as English(US) and Formats as Brazilian Portuguese.
Created attachment 335408 [details] cedilla-portuguese.sh @Mauricio: I noticed this comment at the fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1374888#c5 Hence I don't think it would be appropriate to consider LC_CTYPE be a formats related variable for all users. With that said, I'd like to mention that 'the ccedilla issue' has been addressed in Ubuntu (in a somewhat hackish manner). The attached file, located in /etc/profile.d, does set LC_CTYPE in accordance with your request, but only for Portuguese users.
Indeed a hackish but elegant manner. I just wonder what LC_CTYPE would interfere with if set to the selected "Formats". I've just tried the profile.d approach. It works fine except for gnome-terminal ( this might point to the fact that it might not work for other programs ). I stick to my original RFE, why setting CTYPE would be catastrophic?
On 2016-09-12 23:28, Mauricio Silveira wrote: > I just wonder what LC_CTYPE would interfere with if set to the > selected "Formats". I haven't research it thoroughly, but I fear that LC_CTYPE is queried quite often. One example is that it determines the default locale setting in LibreOffice, which affects the default spell checking language. > I've just tried the profile.d approach. It works fine except for > gnome-terminal Can't see an obvious reason why it wouldn't work for gnome-terminal. (It's effective for gnome-terminal on Ubuntu.)
(In reply to Bastien Nocera from comment #2) > Fixed in gnome-3-6 and master. I'm leaving this opened as we > would need to show the selected paper size in the Region tab as well, > and it's about to undergo some UI changes. This was implemented the day after my comment in: commit d3852fc8316d64204c1b94b5cb6a24c044ef2db1 Author: Matthias Clasen <mclasen@redhat.com> Date: Sun Jan 27 23:18:24 2013 -0500 Wip: new region panel Which does have the paper size. Marking as FIXED. (In reply to Gunnar Hjalmarsson from comment #12) > Created attachment 335408 [details] > cedilla-portuguese.sh > > @Mauricio: I noticed this comment at the fedora bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1374888#c5 > > Hence I don't think it would be appropriate to consider LC_CTYPE be a > formats related variable for all users. > > With that said, I'd like to mention that 'the ccedilla issue' has been > addressed in Ubuntu (in a somewhat hackish manner). The attached file, > located in /etc/profile.d, does set LC_CTYPE in accordance with your > request, but only for Portuguese users. How to enter the cedilla (fwiw, I use AltGr+, for that in the international English AltGr with dead keys layout, like so ç/Ç) is unrelated to LC_CTYPE. LC_CTYPE is practically obsolete in UTF-8, apart from the transliteration functions. I recommend that you adapt an existing keyboard layout to your tastes instead of trying to find unrelated work-arounds for this. Sorry, we're not going to add LC_CTYPE as a "format".
On 2016-09-13 01:52, Bastien Nocera wrote: > How to enter the cedilla (fwiw, I use AltGr+, for that in the > international English AltGr with dead keys layout, like so ç/Ç) is > unrelated to LC_CTYPE. Not quite. To clarify: The issue which Mauricio raised is not about not being able to type ccedilla; it's about a desire to type it in a way which especially Brazilian users are used to (due to other OSes). The Portuguese X11 compose files provide the feature, and setting LC_CTYPE is one way to enable it.
(In reply to Gunnar Hjalmarsson from comment #16) > On 2016-09-13 01:52, Bastien Nocera wrote: > > How to enter the cedilla (fwiw, I use AltGr+, for that in the > > international English AltGr with dead keys layout, like so ç/Ç) is > > unrelated to LC_CTYPE. > > Not quite. > > To clarify: The issue which Mauricio raised is not about not being able to > type ccedilla; it's about a desire to type it in a way which especially > Brazilian users are used to (due to other OSes). The Portuguese X11 compose > files provide the feature, and setting LC_CTYPE is one way to enable it. I don't see what would provide that, and how you'd get from LC_CTYPE to a compose file. There's probably a better way to fix this in any case. Please file a separate bug about this.
On 2016-09-13 11:28, Bastien Nocera wrote: > I don't see what would provide that, and how you'd get from LC_CTYPE > to a compose file. The related man page (man 5 compose) talks about "mapping the locale to a compose file", and LC_CTYPE is the locale category which is queried for the purpose. However, I played around on my Ubuntu GNOME installation, and found that a prerequisite for this to work under IBus is that the GTK_IM_MODULE variable is set (to "ibus"). While it is on Ubuntu (since we let im-config set the IM related variables), GNOME itself only sets QT_IM_MODULE and XMODIFIERS. > There's probably a better way to fix this in any case. There may well be. I just chimed in to show how we currently address it in Ubuntu. > Please file a separate bug about this. That ball is in Mauricio's court. :)
(In reply to Gunnar Hjalmarsson from comment #16) > On 2016-09-13 01:52, Bastien Nocera wrote: > > How to enter the cedilla (fwiw, I use AltGr+, for that in the > > international English AltGr with dead keys layout, like so ç/Ç) is > > unrelated to LC_CTYPE. > > Not quite. > > To clarify: The issue which Mauricio raised is not about not being able to > type ccedilla; it's about a desire to type it in a way which especially > Brazilian users are used to (due to other OSes). The Portuguese X11 compose > files provide the feature, and setting LC_CTYPE is one way to enable it. Not only in Brazil, but any Portuguese language country ( these countries sum up about 300 million people ), including portugal. Everyone here knows IBM/MS-DOS, OS/2 and Windows predates Linux, right? So, since the early ages of computers, when US layout was the standard, it's always been like this. And Linux too, it's always been as simple as setting up kbd layout as un_intl in X11/Xorg conf to get the right layout behavior, "Latim style". In console, it was as simple as running "loadkeys us-acentos". But at some point in time, someone or some group made a decision to turn us_intl into the Slavic default. Don't get me wrong, it makes sense since it's an acute + c , thus ć is logical. But in my POV, an us_slav variant would make more sense. Younger people tend to use Brazilian ABNT or ABNT2 keyboard layouts, simply because it started to become available and the OSes had the layout; and it has a key "ç", (In reply to Gunnar Hjalmarsson from comment #18) > On 2016-09-13 11:28, Bastien Nocera wrote: > > I don't see what would provide that, and how you'd get from LC_CTYPE > > to a compose file. > > The related man page (man 5 compose) talks about "mapping the locale to a > compose file", and LC_CTYPE is the locale category which is queried for the > purpose. > > However, I played around on my Ubuntu GNOME installation, and found that a > prerequisite for this to work under IBus is that the GTK_IM_MODULE variable > is set (to "ibus"). While it is on Ubuntu (since we let im-config set the IM > related variables), GNOME itself only sets QT_IM_MODULE and XMODIFIERS. This is not true. I think GTK defaults to gtk-im-context-simple, thus, it respects the LC_CTYPE somehow. > > There's probably a better way to fix this in any case. > > There may well be. I just chimed in to show how we currently address it in > Ubuntu. > > > Please file a separate bug about this. > > That ball is in Mauricio's court. :) I guess there might be indeed. After reading this: http://stackoverflow.com/questions/30479607/explain-the-effects-of-export-lang-lc-ctype-lc-all, I agree with Bastien not to set LC_CTYPE, as it would affect other behaviors. If ibus was the only im available it would be easy to ask the ibus developers to get this variable from some other file/setting from control-center... It is a complicated matter... Like stated in the link above, russian LC_CTYPE would make uppercase/lowercase conversion of english text follow the russian conversion rules.... But in Portuguese, the rules are the same as English... I'm just curious about what "evil" rules might exist in other languages about uppercase/lowercase conversion...
Mauricio, please file a separate bug about this. I really expect the compose set up to be tied to the *typing* setup, and not the default language or format. This will require untangling at various levels, so best to keep the bug separate.