[Fedora-i18n-bugs] [Bug 597305] New: need xinput conf file for XIM to enable X locale compose maps
bugzilla at redhat.com
bugzilla at redhat.com
Fri May 28 15:55:16 UTC 2010
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: need xinput conf file for XIM to enable X locale compose maps
https://bugzilla.redhat.com/show_bug.cgi?id=597305
Summary: need xinput conf file for XIM to enable X locale
compose maps
Product: Red Hat Enterprise Linux 6
Version: 6.0
Platform: All
OS/Version: Linux
Status: NEW
Keywords: Reopened
Severity: medium
Priority: high
Component: imsettings
AssignedTo: tagoh at redhat.com
ReportedBy: mchehab at redhat.com
QAContact: desktop-bugs at redhat.com
CC: jrb at redhat.com, tagoh at redhat.com, petersen at redhat.com,
eng-i18n-bugs at redhat.com, marcus at sbh.eng.br,
mclasen at redhat.com, kevin at tigcc.ticalc.org,
rodrigopadula at projetofedora.org,
rafael.espindola at gmail.com, vcrhonek at redhat.com,
allisson at gmail.com, ehabkost at redhat.com,
dchen at redhat.com, peter.hutterer at redhat.com,
brunojcm at gmail.com, i18n-bugs at lists.fedoraproject.org,
rosset.filipe at gmail.com, myllynen at redhat.com,
awilliam at redhat.com
Depends on: 505100
Blocks: 473302
Classification: Red Hat
Target Release: ---
Clone Of: 505100
+++ This bug was initially created as a clone of Bug #505100 +++
I'm noticing this bug after upgrading my desktop to RHEL6.
Description of problem:
We have a problem with the keyboard Us Internacional.
I'm using Fedora 11 in pt_BR
Looking the file /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz, I found this:
compose '\'' 'C' to 'Ç'
compose '\'' 'c' to 'ç'
This is correct, but, when I press ' + c or ' + C = ć or Ć.
In portuguese we don't have acent in the c, the correct is ç (C + cedilla)
Version-Release number of selected component (if applicable):
rpm -qf /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz
The package is kbd-1.15-7.fc11.i586
How reproducible:
Choose the pt_BR locale and the US ACENTOS(US International) keyboard layout
Actual results:
when I press ' + c or ' + C = ć or Ć.
Expected results:
ç (C + cedilla)
Additional info:
> Use [RAlt]+[,] and [c] to get ç.
>
> Kevin Kofler
>
It works, but we can't change the default way to use the us_acentos(US
International) keyboard.
Since Fedora 1 and in all others OS like windows and others distros when we
choose the pt_BR language and the US Internacional keyboard when we press C + '
we have = ç
--- Additional comment from kevin at tigcc.ticalc.org on 2009-06-10 20:08:53 EDT
---
As I wrote in my mail, this is a feature. The US International layout supports
many languages, including languages which do have a ć. The whole point is to be
INTERNATIONAL. Making the layout behave differently based on the system locale
makes no sense at all.
--- Additional comment from ehabkost at redhat.com on 2009-06-10 20:43:42 EDT ---
The point of localization is to make the system more accessible to people from
different countries. The way people type "ç" in Brazil is typing the ['] key
and then [c]. Asking the user to use a different method is like asking the user
to switch to a different keyboard layout. I would say that in practice, we use
a different keyboard layout, even if the labels on the physical keyboard look
the same.
I don't know how this can be implemented in the end (maybe it is already
implemented using some layout variation and I don't know it), but this is an
essential feature for making Fedora acessible for the brazilian audience. If
this is not considered a bug, then consider this a feature request, then.
--- Additional comment from kevin at tigcc.ticalc.org on 2009-06-10 20:59:36 EDT
---
There needs to be a us-brazil or something layout then. Redefining us-intl
based on locale is a bad idea.
--- Additional comment from vcrhonek at redhat.com on 2009-06-11 08:06:16 EDT ---
E. g. the letter 'č' is used in Czech Republic (and no other accent with 'c').
It's not possible to have everything included in one keymap.
There are four Brazilian keymaps in /lib/kbd/keymaps/i386/qwerty, please use
one of them.
--- Additional comment from kevin at tigcc.ticalc.org on 2009-06-11 14:49:56 EDT
---
>From http://en.wikipedia.org/wiki/Ć:
"It is the fifth letter of: Polish, Sorbian, Croatian, and Bosnian alphabets,
as well as the Latin forms of Serbian, and Macedonian (in some forms)[1]. It is
fourth in the Belarusian Łacinka alphabet."
--- Additional comment from rodrigopadula at projetofedora.org on 2009-06-11
15:57:41 EDT ---
The question is:
Since Fedora 1 to Fedora 9, when we press c + ' we had = ç
This is the default way in pt_BR locale with US International keyboard to do it
in Windows, Solaris, Mac/OS and all Linux distributions, including Fedora 1 to
9!
We are receiving a lot of claims in Brasil since Fedora 9 about this! We can't
force the users to change the default way to use the keyboard.
This is a big usability problem for Brazilians. Fedora is used by many
governments departments, companies and schools. We can't force this users to
change the way to write or to buy new keyboards.
--- Additional comment from ehabkost at redhat.com on 2009-06-15 10:42:10 EDT ---
(In reply to comment #4)
>
> There are four Brazilian keymaps in /lib/kbd/keymaps/i386/qwerty, please use
> one of them.
I didn't test it, but it looks like the br-latin1-us keymap is what I was
looking for (a US layout keymap with deadkeys for brazilian audience).
I don't know about the issues Rodrigo is seeing, however. Maybe there is a
problem somewhere else, or Rodrigo expects Anaconda to display those layouts as
options at install time. It isn't very clear to me what configuration options
he tried, and what exactly is not working for him.
--- Additional comment from vcrhonek at redhat.com on 2009-06-15 11:36:50 EDT ---
Rodrigo, do you talk about text console, right? Because kbd contains only text
console stuff, not stuff used with X server...
"loadkeys /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz" and typing "' + c"
produced "ç" for me in _text console_.
Typing the same with "USA International (with dead keys)" produced "ć" in
_gnome-terminal_.
System locale doesn't matter.
--- Additional comment from petersen at redhat.com on 2009-06-17 03:19:13 EDT ---
If this is a issue in gtk apps then I suggest trying to install the
gtk-immodules package, which includes the cedilla immodule - no longer
installed by default in F11 gtk2.
--- Additional comment from brunojcm at gmail.com on 2009-06-17 19:59:50 EDT ---
I'm using Fedora 11 and having the same problem with ç. I think it's not
correct to say that's not a bug, because people in Brazil always use ' + c to
put the ç.
It's true that running 'loadkeys
/lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz' or 'loadkeys
/lib/kbd/keymaps/i386/qwerty/br-latin1-us.map.gz' makes ' + c put a ç in _text
console_, as says Vitezlav, but ã is not working on these keymaps.
I think it's a really big mistake not installing gtk2-immodules by default,
because we can hold on without ç in text console, but in gnome it's infeasible.
I needed to install this package, edit /etc/X11/xinit/xinput.d/none.conf to use
the cedilla im and include "en" on the cedilla line of
/etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to get ç working properly on
gnome.
What package can I fill a bug against?
--- Additional comment from vcrhonek at redhat.com on 2009-06-18 02:20:41 EDT ---
(In reply to comment #10)
> I'm using Fedora 11 and having the same problem with ç. I think it's not
> correct to say that's not a bug, because people in Brazil always use ' + c to
> put the ç.
>
> It's true that running 'loadkeys
> /lib/kbd/keymaps/i386/qwerty/us-acentos.map.gz' or 'loadkeys
> /lib/kbd/keymaps/i386/qwerty/br-latin1-us.map.gz' makes ' + c put a ç in _text
> console_, as says Vitezlav, but ã is not working on these keymaps.
If 'ã' should work in Brazilian keymaps (i. e. not in us-acentos;)), please
fill a new bug and we should fix it with kbd upstream.
>
> I think it's a really big mistake not installing gtk2-immodules by default,
> because we can hold on without ç in text console, but in gnome it's infeasible.
> I needed to install this package, edit /etc/X11/xinit/xinput.d/none.conf to use
> the cedilla im and include "en" on the cedilla line of
> /etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to get ç working properly on
> gnome.
> What package can I fill a bug against?
I'll change component to xkeyboard-config - keymaps in X generally, that's
probably it. If not, feel free to reassign it accordingly.
--- Additional comment from petersen at redhat.com on 2009-06-18 19:50:20 EDT ---
Do you have a Brazilian or US keyboard?
If you login to your desktop after choosing one of the Brazilian keyboards
in the GDM keyboard menu, it does not work for you?
--- Additional comment from rodrigopadula at projetofedora.org on 2009-06-18
22:30:28 EDT ---
I'm using US keyboard + pt_br language in my system!
Since fedora 1 and in all OS with pt_BR support, when whe choose the pt_BR
language and US International Keyboard(US Acentos) when we press ' + c we have
= ç but it isn't happen using fedora 10 and 11.
The keyboard and language was defined during the Fedora 10 and 11 installations
and re-seted after the installation, the problem persist in text and GUI modes.
--- Additional comment from dchen at redhat.com on 2009-06-19 02:48:50 EDT ---
Rodrigo,
What you actually need is a Brazilian input method,
which, as Jens points out, in gtk2-immodules.
You may also need to install gtk2-immodules-xim, if there is no Qt equivalent.
Previous Fedora works because they install gtk2-immodules for you.
Keyboard guru Peter mentioned a simple rule:
If the character does not print on your keyboard, or not the place you want,
use an input method.
--- Additional comment from brunojcm at gmail.com on 2009-06-23 13:17:36 EDT ---
Can I report a bug against gtk2-immodules asking for installing it by default?
It is really surprising that the same method of putting ç, which works in all
other versions of fedora and other OS'es not working out of the box in Fedora
11. I think it's really inhibiting people to use Fedora 11 in Brazil.
--- Additional comment from rodrigopadula at projetofedora.org on 2009-07-05
22:42:26 EDT ---
So, we need to install gtk2-immodules and gtk2-immodules-xim by default.
We are receiving a lot of claims about this problem in the Brazilian lists and
Forum.
How we can add this packages by default as a dependency of a
keyboard/localization package ?
It's very important to be corrected ASAP.
--- Additional comment from petersen at redhat.com on 2009-07-08 00:58:52 EDT ---
(In reply to comment #16)
> So, we need to install gtk2-immodules and gtk2-immodules-xim by default.
gtk2-immodules-xim is not needed.
> We are receiving a lot of claims about this problem in the Brazilian lists and
> Forum.
But can't you see im-cedilla.so (from gtk2-immodules) is gtk specific so it
won't work consistently across the distro, eg in KDE, etc.
Sorry, it does not seem to be the Right solution I am afraid
but looks more like a hack.
You didn't answer the question about trying to use a Brazilian
layout instead of US International. Could you please try
that at least from gdm login and report your experience?
--- Additional comment from ehabkost at redhat.com on 2009-07-08 09:59:48 EDT ---
(In reply to comment #17)
>
> You didn't answer the question about trying to use a Brazilian
> layout instead of US International. Could you please try
> that at least from gdm login and report your experience?
I don't think there is a keyboard layout on the list that is equivalent to
us-international + cedilla (that is what brazilian user expect when they have a
US keyboard), but I still need to check the keyboard layout list, just in case.
On my Fedora 10 machine I configured KDE to use '-layout us -variant alt-intl',
and cedilla is working as expected. I don't know if there is an option for this
on Anaconda or GDM, though.
--- Additional comment from rodrigopadula at projetofedora.org on 2009-07-09
12:29:40 EDT ---
After the gtk2-immodules installation is necessary to change the file
/etc/X11/xinit/xinput.d/none.conf
Line: GTK_IM_MODULE=gtk-im-context-simple
To: GTK_IM_MODULE=gtk-im-cedilla
--- Additional comment from brunojcm at gmail.com on 2009-07-09 12:50:25 EDT ---
Here I'm using a US keyboard and need cedilla.
I tried all formats of "System > Preferences > Keyboard > Layout" without
success.
None of the "Brazil" variants matches the US international layout and if I
choose "United States" there is not a variant that gives me the cedilla
behaviour.
The only way I could make it work was selecting "United States", variant "USA
Alternative international (former us_intl)", and installing de gtk2-immodules
and editing /etc/gtk-2.0/x86_64-redhat-linux-gnu/gtk.immodules to put ":en" on
the end of cedilla line.
I agree with Eduardo, there is not a keyboard layout on the list that is
equivalent to "US International + cedilla".
I have a Windows VM on this Fedora and just select Language "Português
(Brazil)", layout "United States (International)" and everything is working
properly.
PS. I have another issue here: When I press " two times, i get ¨ instead of "".
When a press ' two times, i got a ´ instead of ''. It's not the desired
behaviour, but I'm not sure it's layout fault.
Thanks for all!
--- Additional comment from kevin at tigcc.ticalc.org on 2009-07-09 13:01:45 EDT
---
Re your PS, that's also a feature.
--- Additional comment from ehabkost at redhat.com on 2009-07-09 13:23:46 EDT ---
(In reply to comment #20)
>
> PS. I have another issue here: When I press " two times, i get ¨ instead of "".
> When a press ' two times, i got a ´ instead of ''. It's not the desired
> behaviour, but I'm not sure it's layout fault.
I think this is the expected behaviour.
Press ['] two times, to get: ´
Press ['] then spacebar, to get: '
Press ["] two times, to get: ¨
Press ["] then spacebar, to get: "
I think it always worked that way, didn't it?
--- Additional comment from brunojcm at gmail.com on 2009-07-09 14:44:53 EDT ---
(In reply to comment #22)
> I think this is the expected behaviour.
>
> Press ['] two times, to get: ´
> Press ['] then spacebar, to get: '
> Press ["] two times, to get: ¨
> Press ["] then spacebar, to get: "
>
> I think it always worked that way, didn't it?
I'm not sure about this because it's the first time I use Fedora with US
keyboard.. all my others boxes have a brazilian ABNT2 keyboard, with works very
well with the Brazilian layout.
It would be more useful if the behaviour was like I described above in a new
"Brazilian US International Keyboard" likely layout, because here in Brazil we
don't use [¨] and [´] frequently, and it would seems more with Windows
behaviour, users could feel less strange on migrations, etc.
But I think it's a little off-topic, the real problem in Brazil is actually the
cedilla, not it.
Thanks for all!
--- Additional comment from dchen at redhat.com on 2009-07-09 20:30:39 EDT ---
Rodrigo,
Modifying default behaviour of none.conf may upset other people that use it.
It looks like Vitezslav is going to help you by providing a Brazilian keyboard
layout/map
for kbd and X. How about, as he said, open another bug so he can work on that?
Alternatively, you can make an Brazilian input method for IBus. :-)
--- Additional comment from tagoh at redhat.com on 2009-07-09 21:01:30 EDT ---
Created an attachment (id=351200)
--> (https://bugzilla.redhat.com/attachment.cgi?id=351200)
im-cedilla.conf
Just a suggestion if using cedilla immodule in gtk+ is a solution:
How about put im-cedilla.so to the separate package like gtk-immodules-cedilla
with the attached imsettings configuration file? you could update comps to
require that package for Brazilian Portuguese Language Support then. although
you need to choose that with im-chooser manually and need a bit updates on
imsettings to support immodule only configuration.
As Ding suggested, supporting cedilla in IBus may be the right way to go. we
can enable IM for pt_BR and no need to do something with im-chooser basically
then.
Anyway, just for an idea.
--- Additional comment from petersen at redhat.com on 2009-07-09 21:02:30 EDT ---
This bug should be fixable at the xkb level IMHO without using immodule hacks.
Moving to xkeyboard-config based on comment 18.
(Please a separate bug for any quoting issues.)
--- Additional comment from petersen at redhat.com on 2009-07-09 21:04:15 EDT ---
(In reply to comment #25)
> How about put im-cedilla.so to the separate package like gtk-immodules-cedilla
> with the attached imsettings configuration file? you could update comps to
> require that package for Brazilian Portuguese Language Support then. although
> you need to choose that with im-chooser manually and need a bit updates on
> imsettings to support immodule only configuration.
Good point - we can certainly do that too - in fact doesn't require
subpackaging per se.
But I think the first attempt should be to fix this correctly with xkb support.
--- Additional comment from petersen at redhat.com on 2009-07-10 02:37:01 EDT ---
(In reply to comment #25)
> Created an attachment (id=351200)
--> (https://bugzilla.redhat.com/attachment.cgi?id=351200) [details]
> im-cedilla.conf
I opened bug 510666 to rfe adding xinput .conf to gtk2-immodules.
--- Additional comment from rafael.espindola at gmail.com on 2009-07-13 17:32:04
EDT ---
Just tried every combination of keyboards in
By language -> Portuguese
By country -> Brazil
By country -> United States
None has the desired effect of ' + c producing a ç.
No having such a layout (I don't care about the name) is a major usability
problem.
Also, the layout should work in any application, using a gtk specific fix is
not the way to go...
--- Additional comment from petersen at redhat.com on 2009-09-01 20:23:20 EDT ---
Hmm, what do other (commercial) OS's do for this?
--- Additional comment from ehabkost at redhat.com on 2009-09-02 10:45:52 EDT ---
On every pt_BR version of Windows I remember, the "US International" keyboard
layout was the US keyboard layout where '+c produced ç.
That's why the current behaviour is confusing for brazilian users coming from
Windows. It is confusing even for former Linux users because on older Linux
distributions, the US International keyboard layout on Xorg used to produce ç
instead of ć.
I have just checked this on a pt_BR Windows XP machine, and I get the expected
behaviour if I select: language=EN, layout="US international" on the
keyboard-layout applet.
I don't know what would be the best solution for this, however.
--- Additional comment from brunojcm at gmail.com on 2009-09-02 22:42:56 EDT ---
Rafael and Eduardo just confirmed what people said all the time along this
thread. All OS'es in all versions i know produced ç with ' + c until Fedora 11.
I don't know how people who uses the ć configured their keyboard up to now, but
they should have a way. Brazilian people with US keyboard layout don't have a
way anymore. Fedora 11 changes the default behaviour without provide an
alternative. As said Rafael, it's a major usability problem.
Even the workaround proposed by me on Comment #20 works anymore, problably
because some update I can't identify.
I just don't understand why this behaviour changed occurred.. but I hope it's
really necessary and the change worth enough.
If someone have another workaround, i would really appreciate to know.
Thanks
--- Additional comment from petersen at redhat.com on 2009-09-03 06:33:06 EDT ---
(In reply to comment #32)
> Rafael and Eduardo just confirmed what people said all the time along this
> thread. All OS'es in all versions i know produced ç with ' + c until Fedora 11.
So I think we need a xkb layout with dead_acute + c -> ç.
> I don't know how people who uses the ć configured their keyboard up to now, but
> they should have a way. Brazilian people with US keyboard layout don't have a
> way anymore. Fedora 11 changes the default behaviour without provide an
> alternative. As said Rafael, it's a major usability problem.
Dumb question probably: using the Brazil layout which has a Ç key
would not be good enough?
> I just don't understand why this behaviour changed occurred.. but I hope it's
> really necessary and the change worth enough.
Well it changed because we thought that the old gtk2 immodules
are mostly hacks and should not be installed by default in Fedora.
--- Additional comment from ehabkost at redhat.com on 2009-09-03 08:19:45 EDT ---
(In reply to comment #33)
>
> Dumb question probably: using the Brazil layout which has a Ç key
> would not be good enough?
Not if your machine's keyboard has US layout and doesn't have a ç key. :)
BR ABNT2 keyboards are also common in Brazil, but they have a completely
different physical key layout (among other differences, you have an actual ç
key on the keyboard). The problem here is for users who have US keyboards.
--- Additional comment from petersen at redhat.com on 2009-09-17 03:11:09 EDT ---
I see "us(intl)" has Alt_R + comma mapping to ccedilla.
Does that help at all?
What layout do people want to base on?
--- Additional comment from rafael.espindola at gmail.com on 2009-09-17 09:06:41
EDT ---
(In reply to comment #35)
> I see "us(intl)" has Alt_R + comma mapping to ccedilla.
> Does that help at all?
Helps, but having the same behavior as previous versions (and windows) is
better.
> What layout do people want to base on?
I think a us-intl with the '+c patched to produce ç would be perfect.
--- Additional comment from rodrigopadula at projetofedora.org on 2009-09-17
10:39:52 EDT ---
Problem fixed.
https://bugzilla.redhat.com/show_bug.cgi?id=510666
--- Additional comment from kevin at tigcc.ticalc.org on 2009-09-17 18:16:16 EDT
---
I think that's not a real fix, just a hack. It'll lead to GTK+ applications
doing something different than other apps (e.g. Qt apps).
--- Additional comment from petersen at redhat.com on 2009-09-17 20:38:22 EDT ---
(In reply to comment #36)
> I think a us-intl with the '+c patched to produce ç would be perfect.
I think the only way to do that is to have "'" mapped to
dead_cedilla which is not what you want I suppose.
Peter, any comment?
Seems to me that using dead_acute for this was a Bad Idea
and people should rather get used to Alt_R Comma.
How about Alt_R c -> ç that seems common?
--- Additional comment from rafael.espindola at gmail.com on 2009-09-17 21:32:04
EDT ---
I keep my opinion that fixing this is GTK is wrong. It has to work on Qt and on
plain X.
Alt_R c -> ç is a bit better (OS X is similar), but with windows being such a
big part of the market I think the best it to just follow windows and keep the
old behavior: ' + c -> ç.
--- Additional comment from petersen at redhat.com on 2009-09-17 21:58:42 EDT ---
Yes but how?
The only other idea I can offer is an m17n-contrib input-method:
Currently in fedora m17n-db-latin we have latn-post and latn-pre
which provide c, -> ç and ,c -> ç respectively (plus lots of
other accent bindings for qwerty), but it is trivial to make
map for 'c -> ç, etc.
--- Additional comment from rafael.espindola at gmail.com on 2009-09-17 22:09:39
EDT ---
There must be a way, that was the behavior in older versions of fedora :-)
Copying an old version of us-intl and renaming it to us-pt or us-pt_br should
work, no?
--- Additional comment from petersen at redhat.com on 2009-09-17 22:47:06 EDT ---
(In reply to comment #42)
> Copying an old version of us-intl and renaming it to us-pt or us-pt_br should
> work, no?
If you can attach it we can review. Which version of Fedora?
Was X using the kernel us-acentos map then?
As I see it the current choices are:
A) use dead_cedilla (only needed for ccedilla)
B) define ccedilla on a key (us(intl) provides it on Alt_R comma)
C) use an input method to implement it.
I think B or C are preferable.
--- Additional comment from rafael.espindola at gmail.com on 2009-09-17 23:17:21
EDT ---
comment #6 says Fedora 1 to 9.
C is not a fix IMHO
B using Alt_R + c is an improvement, but we would still have a regression
A I think this would fix the problem. In fact, I think that is how us-intl used
to work
I just moved and don't have a Fedora machine with me right now. Should be able
to test in one month.
--- Additional comment from rodrigopadula at projetofedora.org on 2009-09-18
00:17:16 EDT ---
In Kde and in text mode the ' + c = ç is working fine, without extra
configurations.
I had problems only using gnome/gtk.
--- Additional comment from kevin at tigcc.ticalc.org on 2009-09-18 02:49:11 EDT
---
"Solution" A would not really fix your problem, you could no longer enter
things like á, é, í, ó, ú (and ý if you need that one) nor the apostrophe
itself if ' was mapped to dead_cedilla.
If I set the layout to us_intl in KDE (F10, KDE 4.3.1, de_AT.UTF-8 locale), I
get ' + c = ć, not ç (and to be honest that's what I'd expect, especially from
an *international* layout: if dead_acute + c is ç, how are people who want to
type ć (needed at least for Polish and Croatian, and Serbian if written in
Latin letters) supposed to get it?).
But I think this may well be locale-dependant: the Compose tables are in
/usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps
dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer
uses the locale-specific table?
--- Additional comment from petersen at redhat.com on 2009-09-18 03:33:48 EDT ---
I dunno I just tried in rawhide kde and get ' + c = ć.
(In reply to comment #45)
> In Kde and in text mode the ' + c = ç is working fine, without extra
> configurations.
Console is using us-acentos presumably?
Please explain how to reproduce in KDE.
--- Additional comment from rafael.espindola at gmail.com on 2009-09-18 09:44:28
EDT ---
(In reply to comment #46)
> "Solution" A would not really fix your problem, you could no longer enter
> things like á, é, í, ó, ú (and ý if you need that one) nor the apostrophe
> itself if ' was mapped to dead_cedilla.
how about dead_acute + c = ç?
I remember that '+' used to be '
> If I set the layout to us_intl in KDE (F10, KDE 4.3.1, de_AT.UTF-8 locale), I
> get ' + c = ć, not ç (and to be honest that's what I'd expect, especially from
> an *international* layout: if dead_acute + c is ç, how are people who want to
> type ć (needed at least for Polish and Croatian, and Serbian if written in
> Latin letters) supposed to get it?).
Sure. Lets keep the us_intl what it is. It was enough pain to change it once.
Just add a us_pt or something.
> But I think this may well be locale-dependant: the Compose tables are in
> /usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps
> dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer
> uses the locale-specific table?
I think '+c was producing ć everywhere (xterm, mozilla, konsole, etc), but I
might be wrong. Can anyone with a current Federa install check that?
--- Additional comment from petersen at redhat.com on 2009-09-23 05:08:00 EDT ---
(I think with Compose (Multi_key) you could have
"Compose comma c" -> ç)
(In reply to comment #46)
> But I think this may well be locale-dependant: the Compose tables are in
> /usr/share/X11/locale/ and there's a special one for pt_BR.UTF-8 which maps
> dead_acute + c to ç (yuck!). So maybe what's going on is that GTK+ no longer
> uses the locale-specific table?
Oh yes - new to me...
> So maybe what's going on is that GTK+ no longer
> uses the locale-specific table?
You're right - the locale compose seems to work
for X11 and KDE apps.
So seems indeed GTK is inconsistent here.
--- Additional comment from petersen at redhat.com on 2009-09-23 05:17:45 EDT ---
An extra wrinkle is that IM (at least ibus) seems to break
the locale compose in KDE, but I assume you don't need
input methods for now.
--- Additional comment from mclasen at redhat.com on 2009-09-24 10:40:20 EDT ---
GTK itself has never used the X compose tables, we have our own builtin table.
And that table does in fact contain sequences for ç. E.g. try
Compose_key , c
Compose_key c ,
If you want to use the X compose tables in GTK+, you have to use xim.
--- Additional comment from ehabkost at redhat.com on 2009-09-24 11:51:21 EDT ---
(In reply to comment #51)
> GTK itself has never used the X compose tables, we have our own builtin table.
> And that table does in fact contain sequences for ç. E.g. try
> Compose_key , c
> Compose_key c ,
>
> If you want to use the X compose tables in GTK+, you have to use xim.
Sorry for the ignorance, but what does that mean for users that don't know what
Input Methods are, have a US keyboard, install Fedora in pt_BR, and expect
[']+[c] to produce [ç]?
--- Additional comment from petersen at redhat.com on 2009-09-28 04:23:01 EDT ---
I haven't succeeded yet in getting X compose working with im-xim.so
- so would appreciate receiving clues/steps to do that. :)
Is "GTK_IM_MODULE=xim" sufficient?
(In reply to comment #52)
> > If you want to use the X compose tables in GTK+, you have to use xim.
>
> Sorry for the ignorance, but what does that mean for users that don't know what
> Input Methods are, have a US keyboard, install Fedora in pt_BR, and expect
> [']+[c] to produce [ç]?
IIUC it means that if one enables XIM on the desktop then
your [']+[c] should work for pt_BR in gtk apps.
However as I say above I haven't succeeded yet with doing that.
--- Additional comment from petersen at redhat.com on 2009-09-28 05:15:14 EDT ---
Nm, Tagoh-san pointed me in the right direction.
- Need to make sure gtk2-immodule-xim is installed. ;)
- Login from gdm with lang=pt_BR.UTF-8 and kbd=us(intl).
- Run $ GTK_IM_MODULE=xim gedit.
- Enter [']+[c] to produce [ç].
- Game over. :)
But we need some imsettings to allow turning on
XIM in this case.
--- Additional comment from ehabkost at redhat.com on 2009-09-28 07:16:44 EDT ---
Once this is fixed, will it be enabled by default on pt_BR + US-intl-keyboard
installs?
--- Additional comment from mclasen at redhat.com on 2009-09-28 10:08:35 EDT ---
Jens, imsettings installs a file called /etc/X11/xinit/xinput.d/xim.conf. Is
that not enough to make xim available via imsettings ?
--- Additional comment from tagoh at redhat.com on 2009-09-28 21:46:32 EDT ---
(In reply to comment #56)
> Jens, imsettings installs a file called /etc/X11/xinit/xinput.d/xim.conf. Is
> that not enough to make xim available via imsettings ?
Since the most XIM servers requires the certain locale to work, it just
provides the proper XIM servers for current locale to the users if available.
xim.conf itself isn't useful if no xinput files are installed.
You may need something like /etc/X11/xinit/xinput.d/xcompose with:
XIM=none
XIM_PROGRAM=/bin/true
XIM_ARGS=
SHORT_DESC="X locale compose"
GTK_IM_MODULE=xim
QT_IM_MODULE=xim
and in %post
%{_sbindir}/update-alternatives --install
%{_sysconfdir}/X11/xinit/xinput.d/pt_BR xinput-pt_BR
%{_sysconfdir}/X11/xinit/xinput.d/xcompose 50
%postun
%{_sbindir}/update-alternatives --remove xinput-pt_BR
%{_sysconfdir}/X11/xinit/xinput.d/xcompose
I'm not sure if there are any requirements that people wants to use X compose
regardless of current locale anyway. if there are, it may be good to not depend
on xim.conf but put it as a standalone xinput file like scim and ibus does.
FWIW there are a bug in imsettings if the system locale is different to what
one gives to imsettings-* command and im-chooser say. so if you are going to
test it with LANG=pt_BR.UTF-8 im-chooser or so, you may see an error message
then. FYI
I'll file a bug for that.
--- Additional comment from petersen at redhat.com on 2009-09-28 23:22:54 EDT ---
(In reply to comment #57)
> and in %post
> %{_sbindir}/update-alternatives --install
> %{_sysconfdir}/X11/xinit/xinput.d/pt_BR xinput-pt_BR
> %{_sysconfdir}/X11/xinit/xinput.d/xcompose 50
>
> %postun
> %{_sbindir}/update-alternatives --remove xinput-pt_BR
> %{_sysconfdir}/X11/xinit/xinput.d/xcompose
>
> I'm not sure if there are any requirements that people wants to use X compose
> regardless of current locale anyway. if there are, it may be good to not depend
> on xim.conf but put it as a standalone xinput file like scim and ibus does.
I think we should support X compose for any locale in principle
so I suggest not to make it locale specific and call the xinput.d
file say "xcompose.conf". (Is the name "X compose" broad enough
to cover it?)
Also I am not sure it needs to set QT_IM_MODULE though it probably
doesn't hurt, or does Qt work because XIM is the default immodule
anyway?
--- Additional comment from tagoh at redhat.com on 2009-09-29 01:37:32 EDT ---
(In reply to comment #58)
> Also I am not sure it needs to set QT_IM_MODULE though it probably
> doesn't hurt, or does Qt work because XIM is the default immodule
> anyway?
That may depends on how people set up on qtconfig. so it would be better adding
that line too unless we don't mind either.
--- Additional comment from tagoh at redhat.com on 2009-10-01 09:00:38 EDT ---
(In reply to comment #58)
> I think we should support X compose for any locale in principle
> so I suggest not to make it locale specific and call the xinput.d
> file say "xcompose.conf". (Is the name "X compose" broad enough
> to cover it?)
Or we could update none.conf to use im-xim.so but with XMODIFIERS=@im=none
instead of gtk-im-context-simple. it doesn't requires the extra configurations.
and it will keeps consistency among all of applications on X.
--- Additional comment from petersen at redhat.com on 2009-10-01 23:27:10 EDT ---
Sounds good to me - good idea :)
--- Additional comment from tagoh at redhat.com on 2009-10-02 02:56:07 EDT ---
I was trying to remember why I didn't make such change before.
The impact on this change would be one has to restart their desktop after
turning off/on IM every time since we stop imsettings-applet running by default
and it depends on the change of XMODIFIERS anyway.
Another concern is, some applications might becomes unstable when switching IM
- one might freezes, one might crash etc - particularly when XMODIFIERS isn't
@im=none.
I've just brought up an idea. but not sure if it's really good.
--- Additional comment from rodrigopadula at projetofedora.org on 2009-10-28
15:08:17 EDT ---
I'm trying Fedora 12 Beta and the problem is the same with this new version.
When I choose Brazilian Portuguese and keyboard US International:
' + c = ć not ç
It's a BIG usability problem for Brazilians because great part of our laptops
are imported and the default keyboard is US International.
--- Additional comment from rosset.filipe at gmail.com on 2009-10-29 09:32:57 EDT
---
On Fedora 12 Beta ' + c = ç works with this steps...
yum install gtk2-immodules
System->Preferences->Input Methods-> Enable im-cedilla
Logoff
GDM Login
PT_BR
us_international (with dead keys)
Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0,
gnome-terminal 2.28.1
--- Additional comment from rodrigopadula at projetofedora.org on 2009-10-29
09:58:20 EDT ---
Yes, it works since fedora 11, but, the Ç on US International keyboards must
work automatically when I choose the BR Portuguese language + US International
Keyboard.
This is a big usability problem, mainly for new users.
--- Additional comment from rafael.espindola at gmail.com on 2009-10-29 11:12:46
EDT ---
(In reply to comment #64)
> On Fedora 12 Beta ' + c = ç works with this steps...
>
> yum install gtk2-immodules
> System->Preferences->Input Methods-> Enable im-cedilla
> Logoff
>
> GDM Login
> PT_BR
> us_international (with dead keys)
>
> Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0,
> gnome-terminal 2.28.1
This will not work on xterm or kterm or emacs, right?
--- Additional comment from rosset.filipe at gmail.com on 2009-10-29 11:21:51 EDT
---
(In reply to comment #66)
> (In reply to comment #64)
> > On Fedora 12 Beta ' + c = ç works with this steps...
> >
> > yum install gtk2-immodules
> > System->Preferences->Input Methods-> Enable im-cedilla
> > Logoff
> >
> > GDM Login
> > PT_BR
> > us_international (with dead keys)
> >
> > Tested on Firefox 3.5.4, Xchat 2.8.6, OpenOffice 3.3.1, Gedit 2.28.0,
> > gnome-terminal 2.28.1
>
> This will not work on xterm or kterm or emacs, right?
Im test now on:
xterm x86_64 248-2.fc12
rawhide 347 k
and works fine.
--- Additional comment from awilliam at redhat.com on 2009-10-29 13:36:41 EDT ---
Bruno Medeiros requested on fedora-test-list that this be nominated as an F12
Blocker, we will discuss at tomorrow's meeting, 15:00 UTC in #fedora-bugzappers
. Please come along to discuss this issue if you can.
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
--- Additional comment from petersen at redhat.com on 2009-10-30 05:13:02 EDT ---
> and works fine.
Because im-cedilla.conf configures XIM also,
so X compose takes care of the X apps.
But currently we can't see any easy way for imseetings
to make im-cedilla the default immodule for pt_BR.
--- Additional comment from tagoh at redhat.com on 2009-10-30 05:34:28 EDT ---
(In reply to comment #69)
> > and works fine.
>
> Because im-cedilla.conf configures XIM also,
> so X compose takes care of the X apps.
>
> But currently we can't see any easy way for imseetings
> to make im-cedilla the default immodule for pt_BR.
Even though it's XMODIFIERS=@im=none. in that sense, we could have the
condition state in none.conf as well to enable im-cedilla for pt_BR and
gtk-im-context-simple for others. what this way is better would be, it wouldn't
need extra work to make it default for pt_BR users. it should works even after
upgrading.
--- Additional comment from myllynen at redhat.com on 2009-10-30 09:03:22 EDT ---
I have read all the comments above and done quite some testing on Fedora 12
Beta. Below I summarize earlier findings, provide some additional information,
and present one possible solution. Please feel free to complement my remarks if
appropriate.
Dysfunctional ' + c for Brazilian Portuguese is just one symptom of a much
wider issue we have here. What is actually happening when a new user logs in is
that GTK's builtin compose rule table is used regardless of user's locale
settings. Apparently with earlier Fedora releases one's locale settings
(LC_CTYPE or LANG) caused X compose rules to be taken into use but currently
there seems to be no way to do that with GTK applications.
Problems arise especially when these GTK builtin rules conflict with
national/locale specific rules like in pt_BR or fi_FI. Using some character
specific trick like im-cedilla is really not a feasible solution to the issue
which literally covers thousands of compose rules.
With non-GTK applications like xterm one can easily see how locale settings
affect the compose rules in use:
# yum install xterm xorg-X11-fonts-misc
$ LC_CTYPE=en_US.UTF-8 xterm &
$ LC_CTYPE=fi_FI.UTF-8 xterm &
$ LC_CTYPE=pt_BR.UTF-8 xterm &
Simple test cases for these three example locales are:
dead_acute + c produces ć if using X's en_US.UTF-8/Compose (or GTK builtins)
dead_acute + c produces ç if using X's pt_BR.UTF-8/Compose
dead_acute + space produces ' if using en_US.UTF-8/Compose (or GTK builtins)
dead_acute + space produces ´ if using fi_FI.UTF-8/Compose
As mentioned several times in the earlier comments the default for Brazilian
Portuguese is not acceptable. Situation with Finnish is also very challenging
since there is an official national standard which defines both keyboard layout
and compose rules. As explained above now it seems impossible to comply with
this standard with Fedora 12 although X already implements everything what
would be needed (i.e., both keyboard layout and X compose rules).
One possible solution to solve all the issues discussed here could be:
1. Use any Input Method system like IBus or SCIM if configured by the user
2. If no Input Method system configured use X/locale settings (default)
3. If both previous methods fail or are unavailable use GTK builtin rules
This scheme would mean that en_US users would not notice any difference
compared to the current situation, users of locales like pt_BR and fi_FI would
notice their keyboards working by default, and others who need an advanced
input system (like ja_JP users) could enable it at will as always. It would
also provide a consistent user experience when switching between GTK
applications (e.g., gnome-terminal) and non-GTK applications (e.g., xterm).
Also, if an individual compose rule or keymapping is found to be problematic
within a locale, then it would be only a locale specific issue, no system level
changes would be needed at all. And should there be changes needed for an Input
Method system only those users who have enabled that particular Input Method
system would be affected.
I will take part of the IRC session later today where we can discuss this issue
in more detail.
Thanks.
--- Additional comment from petersen at redhat.com on 2009-10-30 10:01:24 EDT ---
Thank Marko for the good detailed summary and the Finnish perspective also.
(I am glad this also resurfaced in the i18n Test Day this week.)
(In reply to comment #71)
> Problems arise especially when these GTK builtin rules conflict with
> national/locale specific rules like in pt_BR or fi_FI. Using some character
> specific trick like im-cedilla is really not a feasible solution to the issue
> which literally covers thousands of compose rules.
Right - as also noted here earlier.
> 1. Use any Input Method system like IBus or SCIM if configured by the user
> 2. If no Input Method system configured use X/locale settings (default)
> 3. If both previous methods fail or are unavailable use GTK builtin rules
My suggests are:
1) avoid im-cedilla.so
2) install gtk2-immodules-xim by default
(or better move im-xim.so back into gtk2?)
3) try to make im-xim.so the default gtk immodule
(which corresponds to Marco's (2) instead of
gtk-im-context-simple, as Akira also suggested.
4) everyone (gtk, qt, X) happy
In fact I have pushed for this in the past (see bug 452938)
to bring parity with qt which has long defaulted to XIM
(probably because of its European heritage?:)
I think fedora-i18n can help to work on this in the coming days,
though it is getting rather late for f12-final...
It might be more realistic to target day-zero updates to
not risk destabilizing and further delaying the release
at this stage: I think that was our original intention.
--- Additional comment from awilliam at redhat.com on 2009-10-30 14:17:21 EDT ---
Discussed at the blocker bug meeting today. The thing that worries me is that
if we fix this as a 0-day update it won't be fixed during installation.
However, I've been told that the need to type a ç during installation is likely
to be quite small for most Brazilian users, so on that basis we agreed that
dropping it to F12Target and aiming to fix it with a 0-day update is OK.
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
--- Additional comment from mclasen at redhat.com on 2009-10-30 14:22:38 EDT ---
I don't want to bring xim back into the main gtk package. Imo, this is a step
back. We need to have a single input method framework that actually works for
everybody, not a patchwork where you have to pick whatever works best for your
language.
--- Additional comment from kevin at tigcc.ticalc.org on 2009-10-30 14:26:32 EDT
---
It's also not really true that Qt uses XIM by default. We don't even ship XIM
on the KDE spin. It might pick it up by default if you install it (and no other
input method package), but normally there's no XIM installed at all.
--- Additional comment from petersen at redhat.com on 2009-10-31 06:17:03 EDT ---
(In reply to comment #74)
> I don't want to bring xim back into the main gtk package.
> Imo, this is a step back.
What is the problem with replacing gtk-im-context-simple with
im-xim.so as the default IM context?
I see it as a step forward not a step back. :)
> We need to have a single input method framework that actually works for
> everybody, not a patchwork where you have to pick whatever works best for your
> language.
Well I would like that ibus can also handle X compose better:
hopefully for f13 but rather unlikely for f12 release...
we need a fix now this has been broken since f11. :-(
It is not a patchwork but consistent with qt's behaviour.
(In reply to comment #75)
> It's also not really true that Qt uses XIM by default.
Erm, we are talking about qt immodules here -
sorry for being unclear perhaps: try running
"QT_IM_MODULE= qtconfig-qt4" -> Interface
and looking at "Default Input Method".
Anyway Qt already works the discussion here is about
X and gtk apps.
--- Additional comment from petersen at redhat.com on 2009-10-31 07:29:05 EDT ---
Created an attachment (id=366913)
--> (https://bugzilla.redhat.com/attachment.cgi?id=366913)
imsettings-none.conf-xim.patch
My recommendation to fix this serious problem for International users:
Add to the comps-f12 input-methods group:
<packagereq type="conditional" requires="gtk2">gtk2-immodule-xim</packagereq>
and apply the above patch to imsettings none.conf to make
imsettings default GTK_IMMODULE to xim when available.
My main remaining concern though is multilib issues: eg when users
have gtk2.x86_64 and gtk2.i686 installed but only gtk2-immodule-xim
for one arch. For this reason I really wish Matthias will give
my idea to move im-xim.so back into the main gtk2 package
further consideration.
--- Additional comment from petersen at redhat.com on 2009-10-31 07:34:17 EDT ---
If people could test the above patch it would be appreciated
(be sure to turn-off IM in im-chooser to make sure you are
using none.conf, and restart your desktop session).
It seems to works well enough for me so far on i686 anyway.
--- Additional comment from mclasen at redhat.com on 2009-10-31 14:39:48 EDT ---
> Dysfunctional ' + c for Brazilian Portuguese is just one symptom of a much
> wider issue we have here. What is actually happening when a new user logs
> in is that GTK's builtin compose rule table is used regardless of user's locale
> settings. Apparently with earlier Fedora releases one's locale settings
> (LC_CTYPE or LANG) caused X compose rules to be taken into use but currently
> there seems to be no way to do that with GTK applications.
Depends on what you mean with 'locale settings' here.
If you don't use an input method framework like scim or ibus (or iiimf or xim
or whatever else is in vogue) you get whatever compose sequences that method
provides, which may depend on your locale or not.
If you don't use an input method framework, GTK+ uses its builtin simple input
method, which has a large, but fixed table of compose sequences.
This has always been the case. Nothing has changed in GTK+ here.
--- Additional comment from petersen at redhat.com on 2009-11-01 08:19:37 EST ---
(In reply to comment #79)
> This has always been the case. Nothing has changed in GTK+ here.
Right. What changed in F11 is we stopped installing
im-cedilla by default and hence this bug report.
(I was probably partly to blame for that decision:
not that it was wrong in itself, just that we didn't provide
a saner substitute, since I don't think we were aware then
of its wide use for pt_BR.)
It seems clear now that im-cedilla was merely a hack
to workaround the lack of X compose support in gtk-im-context-simple,
which is provided through im-xim.so. Using im-xim.so
should give us consistent keyboard input for all locales
across X, GTK, and Qt applications which is a big usability plus
for users dependent on X compose for writing their language.
--- Additional comment from mclasen at redhat.com on 2009-11-01 09:25:21 EST ---
> It seems clear now that im-cedilla was merely a hack
> to workaround the lack of X compose support in gtk-im-context-simple,
> which is provided through im-xim.so. Using im-xim.so
> should give us consistent keyboard input for all locales
> across X, GTK, and Qt applications which is a big usability plus
> for users dependent on X compose for writing their language.
I can only repeat my position on this:
We need a single input method framework and we need to tighly integrate it with
keyboard layout configuration and the rest of the desktop. Tagging input method
support onto desktops 'from the side' and trying to make it both
'desktop-neutral' and 'im-framework-neutral' is always going to provide an
insufficient user experience.
--- Additional comment from petersen at redhat.com on 2009-11-01 20:30:43 EST ---
I agree wholeheartedly - I see that as a long-term goal
for tight IM integration on the desktop. I feel
we are gradually moving in the right direction, and
I would like to collaborate on this.
--- Additional comment from petersen at redhat.com on 2009-11-02 04:59:00 EST ---
I built
http://koji.fedoraproject.org/koji/buildinfo?buildID=139343
to help with this issue: please test it with gtk2-immodule-xim
and report any problems or successes here.
--- Additional comment from myllynen at redhat.com on 2009-11-03 11:20:37 EST ---
Thanks Jens, I've now tested your new packages on two test systems and the
issue seems to be solved! I'll document some additional details below if
someone happens to struggle with this one in the future.
After installing gtk2-immodule-xim and disabling any Input Method (if in use)
one just needs to logout and login with an appropriate language and X compose
sequences should thenbe in use also in GTK applications. User experience
between GTK and non-GTK applications is now consistent.
In practice one can either choose an appropriate (native) language for the
whole session at GDM login prompt (like Brazilian Portuguese or Finnish) which
will set up LANG environment variable or adjust LC_CTYPE in a shell init script
allowing use of a language like US English for the session but still having
native compose sequences. The only limitation seems to be that one can't set
LC_CTYPE per window basis but needs it for the whole session but I don't think
that's a problem, really.
Should there be any issues still checking 'locale´ output might give some clues
as well as contents of ~/.dmrc.
--- Additional comment from updates at fedoraproject.org on 2009-11-07 23:54:18
EST ---
imsettings-0.107.4-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/imsettings-0.107.4-3.fc12
--- Additional comment from updates at fedoraproject.org on 2009-11-10 12:52:42
EST ---
imsettings-0.107.4-3.fc12 has been pushed to the Fedora 12 testing repository.
If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update imsettings'. You can provide
feedback for this update here:
http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11244
--- Additional comment from petersen at redhat.com on 2009-11-11 19:32:49 EST ---
Please test and feel free to bump karma in Bodhi to get this
pushed to F12 updates.
--- Additional comment from updates at fedoraproject.org on 2009-11-27 17:02:57
EST ---
imsettings-0.107.4-3.fc12 has been pushed to the Fedora 12 stable repository.
If problems still persist, please make note of it in this bug report.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the i18n-bugs
mailing list