Bug 847495

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.

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.

I mean showing us layout is not a bug.
m17n:ru:translit with Finnish would be another problem for now.
Transferring to ibus-m17n.

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

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.

(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.

(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.

(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.

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".

(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.

(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.

(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)

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

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).

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.