Bug 847495 - For non-US keyboard layout Ibus-m17n adds English (US) to the list of input methods and other input methods use US layout
For non-US keyboard layout Ibus-m17n adds English (US) to the list of input m...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ibus-m17n (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Daiki Ueno
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-12 03:56 EDT by Daniil Ivanov
Modified: 2012-09-17 18:13 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-17 18:13:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniil Ivanov 2012-08-12 03:56:33 EDT
Version-Release number of selected component (if applicable):
ibus-1.4.99.20120712-1.fc17.x86_64

How reproducible:
I have non-US keyboard - Finish and I use Ibus with Russian m17-translit.
I had this setup in Fedora 16 and it was working perfectly fine. The problems started when I upgraded to Fedora 17.
Now Ibus has three input methods listed:
Finish - Finish
Russian - translit (m17n)
English - English (US)

If I remove English (US) from the list it re-appears on Ibus restart.
Another problem is using Russian translit, it uses US keyboard layout, instead of Finish.

Changing "Use system keyboard layout" option has no effect on the setup.
Comment 1 fujiwara 2012-08-13 22:32:36 EDT
Because m17n:ru:translit needs 'us' layout.
Currently if an input method engine specifies an XKB keymap, the keymap engine will be added in the ibus list automatically.
Probably this would be a limitation to use libxklavier.

% /usr/libexec/ibus-engine-m17n --xml | less
        <engine>
            <name>m17n:ru:translit</name>
            <longname>translit (m17n)</longname>
            <layout>us</layout>
        </engine>


Probably if you use Fedora 18 GNOME, the problem won't be happened because f18 GNOME will use XKB directly instead of libxklavier.
Comment 2 Daniil Ivanov 2012-08-14 01:52:14 EDT
How come it's not a bug? I use m17n:ru:translit with Finnish keyboard for years now and it's only in Fedora 17 it requires US. This is clearly a regression.
Comment 3 fujiwara 2012-08-14 01:54:57 EDT
I mean showing us layout is not a bug.
m17n:ru:translit with Finnish would be another problem for now.
Transferring to ibus-m17n.
Comment 4 Daiki Ueno 2012-08-14 02:33:40 EDT
I tend to merge this into bug 760108, though I'm not confident if these 2 bugs are same, as we didn't get enough feedback.

Reporter, could you check the comments at the bug and if appropriate please try the test RPM below?

http://koji.fedoraproject.org/koji/taskinfo?taskID=4387443
Comment 5 Daniil Ivanov 2012-08-14 02:37:42 EDT
I've checked /usr/share/ibus-m17n/setup/default.xml. It contains "us" layout for every single input method. This doesn't fit to non-US keyboards.
However, then I've changed layout to "fi" for "m17n:*" and "m17n:ru:kbd" and
/usr/libexec/ibus-engine-m17n --xml still shows "us" as a layout for m17n:ru:translit.
Comment 6 Daniil Ivanov 2012-08-14 02:50:55 EDT
(In reply to comment #4)
> I tend to merge this into bug 760108, though I'm not confident if these 2
> bugs are same, as we didn't get enough feedback.
> 
> Reporter, could you check the comments at the bug and if appropriate please
> try the test RPM below?

This bug was reported against Fedora 16 and says about impossibility to input certain symbols. I have a problem with Fedora 17 and am able to input any symbols, however I have to do it with US layout, while physically having Finnish/Swedish keyboard. I doubt they are related.
Comment 7 Daiki Ueno 2012-08-14 03:03:37 EDT
(In reply to comment #6)
> (In reply to comment #4)
> > I tend to merge this into bug 760108, though I'm not confident if these 2
> > bugs are same, as we didn't get enough feedback.
> > 
> > Reporter, could you check the comments at the bug and if appropriate please
> > try the test RPM below?
> 
> This bug was reported against Fedora 16 and says about impossibility to
> input certain symbols. I have a problem with Fedora 17 and am able to input
> any symbols, however I have to do it with US layout, while physically having
> Finnish/Swedish keyboard. I doubt they are related.

OK, I see.  But could you please try the RPM just in case?  It internally uses keycodes instead of symbols so it shouldn't depend on layout.  If it works ok, the fix would be easily upstreamable.

If it doesn't work, as you noticed above, you can tweak default.xml and add <layout>fi</layout> to m17n:* element.  Note that <virtual-keyboard>us</virtual-keyboard> is not related to keyboard layout, but a hint for external virtual keyboard software like eekboard or iok.
Comment 8 Daniil Ivanov 2012-08-14 03:24:49 EDT
(In reply to comment #7)
> OK, I see.  But could you please try the RPM just in case?  It internally
> uses keycodes instead of symbols so it shouldn't depend on layout.  If it
> works ok, the fix would be easily upstreamable.

This version of ibus-m17n made ibus defuct. I'm not able to switch input methods, and taskbar applet shows empty list of available methods. However, ibus-setup shows the same three input methods: Finnish, US and ru-translit.
Comment 9 Daniil Ivanov 2012-08-14 09:30:41 EDT
Adding <layuout>fi</layout> to "m17n:*" in /usr/share/ibus-m17n/setup/default.xml has workarounded the problem for me. Though, this is really wrong as my system keyboard layout is already "fi". Apparently, "us" is never correct unless user set's one of his layouts as "us".
Comment 10 Daiki Ueno 2012-08-14 21:04:20 EDT
(In reply to comment #9)
> Adding <layuout>fi</layout> to "m17n:*" in
> /usr/share/ibus-m17n/setup/default.xml has workarounded the problem for me.

I will certainly add a user option for that in setup UI.  Now thinking about the default value...

Probably I misunderstood the situation.  I thought that all the m17n maps are designed to run on us layout (as layout diagrams in ru-kbd.min or ko-han2.mim), but perhaps some of them are not, particularly "transliteration" maps.  Is that right?  If so, m17n:*:translit layout should not touch the layout?

(In reply to comment #8)

> This version of ibus-m17n made ibus defuct.

Sorry about that.  Maybe the patch was outdated.
Comment 11 Daniil Ivanov 2012-08-15 02:11:47 EDT
(In reply to comment #10)
> Probably I misunderstood the situation.  I thought that all the m17n maps
> are designed to run on us layout (as layout diagrams in ru-kbd.min or
> ko-han2.mim), but perhaps some of them are not, particularly
> "transliteration" maps.  Is that right?  If so, m17n:*:translit layout
> should not touch the layout?

I cannot say about kbd as they are supposed to resemble key positions in original layouts, but in my experience they work badly on non-US layouts. On the other hand, transliteration means typing Latin letters with keyboard one has. Difference between qwerty (US layout), azerty (used in France), qwertz (used in Germany and Switzerland) and, for example, Swe/Fin layout are just few symbols. It's very frustrating to have additional US keyboard, which does exactly the same as original layout, but doesn't match to writings on the buttons. Thus, forcing additonal US layout is a bug as it adds no value and makes switching more difficult.
Comment 12 Daiki Ueno 2012-08-15 04:45:24 EDT
(In reply to comment #11)

> I cannot say about kbd as they are supposed to resemble key positions in
> original layouts, but in my experience they work badly on non-US layouts. On
> the other hand, transliteration means typing Latin letters with keyboard one
> has.

OK, thanks for the confirmation.  I'll fix this by adding the following entry to default.xml.in.in:

	<!-- Don't touch the layout for transliteration maps. -->
	<engine>
	  	<name>m17n:*:translit</name>
		<layout>default</layout>
	</engine>

(I'll postpone adding an option to ibus-setup-m17n because of the implementation reason - it may cause race condition with ibus-dconf)
Comment 13 Fedora Update System 2012-08-15 05:40:51 EDT
ibus-m17n-1.3.4-4.fc18,eekboard-1.0.8-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/ibus-m17n-1.3.4-4.fc18,eekboard-1.0.8-1.fc18
Comment 14 Fedora Update System 2012-08-15 11:57:57 EDT
Package ibus-m17n-1.3.4-4.fc18, eekboard-1.0.8-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ibus-m17n-1.3.4-4.fc18 eekboard-1.0.8-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11896/ibus-m17n-1.3.4-4.fc18,eekboard-1.0.8-1.fc18
then log in and leave karma (feedback).
Comment 15 Fedora Update System 2012-09-17 18:13:23 EDT
ibus-m17n-1.3.4-4.fc18, eekboard-1.0.8-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.