Switching from russian to chinese does not work

Status changed to 'Confirmed' because the bug affects multiple users.

same problem when switching from Russian to Japanese(ibus-anthy) as well as Chinese(ibus-libpinyin).
And Korean(ibus-hangul) works fine. So I inserted Korean to work around between Russian and Chinese

Thanks for your report.

Is this still an issue in Ubuntu 17.10 or Ubuntu bionic (coming 18.04)?

Well, actually I did switch to arch linux, not an ubuntu user anymore. However I suppose it is still issue because of upstream ibus-libpinyin package. Likely I would to post a bug report there but right now I am simply fixing it for my self using simple patch like this:

```
diff -Naur src.org/ibus-libpinyin-1.9.0/src/libpinyin.xml.in.in src/ibus-libpinyin-1.9.0/src/libpinyin.xml.in.in
--- src.org/ibus-libpinyin-1.9.0/src/libpinyin.xml.in.in 2017-04-20 17:52:53.000000000 +1000
+++ src/ibus-libpinyin-1.9.0/src/libpinyin.xml.in.in 2017-06-14 13:34:13.966666659 +1000
@@ -21,7 +21,7 @@
                         BYVoid &lt;<email address hidden>&gt;
                         </author>
                        <icon>${pkgdatadir}/icons/ibus-pinyin.svg</icon>
- <layout>default</layout>
+ <layout>us</layout>
                        <longname>Intelligent Pinyin</longname>
                        <description>Intelligent Pinyin input method</description>
                        <rank>99</rank>
```
After that all starts working just fine.

see source here https://github.com/libpinyin/ibus-libpinyin/blob/master/src/libpinyin.xml.in.in#L24

switching to chinese from russian uses default layout, as described in that xml, which is RU. because of that switching does not work. Forcing the layout to be US resolves the issue.

Hope the information will be useful to somebody

Thanks for your input; much appreciated!

Sounds as something worth looking into.

I have gained some more insight on this topic lately.

There is no "right" or "wrong" layout value in IBus plugins like these packages. We have reasons to assume that "default" is a deliberate decision after a trade-off between different goals. A hard coded layout would prevent issues like the one reported in this bug report, but it would make it harder for users who prefer some other underlying layout when using respective input method. It seems that they preferred the flexibilty which "default" offers.

It's worth noting that the ibus-anthy setup GUI allows the user to specify the layout (the Typing Method tab). To me that appears to be the optimal solution, and it's probably a good idea to encourage the upstream developers of other input methods to do the same.

But such a change won't happen in Ubuntu only. Please submit upstream issues if you want it to be considered by the upstream developers.

Still keeping this bug report open for now, since this discussion may be of some interest.

@gunnarhj
you are right, this is upstream issue.

And you are wrong about "right" and "wrong" layouts for this input method. Pinyin implies latin letters input only. So, for example, neither of languages of ex-USSR is suited for pinyin. Maybe some/many others as well. When we switching to pinyin we expect just to start typing and get hanzi, not anything else. En us is common input method, any keyboard has it, so it seems reasonable to the method to have it as standard (right) input method.

Just IMHO ))

Just to clarify: When saying that there is no "right" or "wrong" I meant the configuration of respective input method, i.e. "default" vs. some specific layout. We are of course agreed on the fact that e.g. a Russian layout is not compatible with an input method, which - as you say - expects latin letters.

just note the default alphabet for pinyin is latin, not anything else. We want it just work right out of the box, correct? Well, in 99.9% of usecases. So user (any user, nub, advanced, etc) installs it and uses it. With currently used 'default' approach, switching to the method does not yields right layout. How many languages are there? How many of them use pure latin alphabet (and thus compatible 'default' layout)? diving latter by former you will get the percentage when it works (I suppose it will be something around 50%. an exact figure can be taken by reviewing all the languages with their respective layouts in conjunction with available input methods. Hard to do, no doubt).

Using 'en' layout resolves the issue, by forcing an environment to switch to this layout, and anyone can type hanzi seamless. Thus we have uniformity. If you want to reuse dvorak layout (just for example), then you have a choice to fix it by supplying an exact layout using either available means (e.g. ibus-anthy, and such). It is for advanced users.

"but it would make it harder for users who prefer some other underlying layout when using respective input method. It seems that they preferred the flexibilty which "default" offers."

Could you estimate how many there is such an users? I think just a units of percents, and it seems they are a kind of 'advanced' users, who is able to make fine tuning of their software on their own.

Usually (99.9%?) latin alphabet is engraved on keyboards using plain QWERTY, right? It is why "en-us", for example, is right candidate to the 'right' input method for pinyin.

just IMHO))

I understand completely what you write now, and won't argue with you. After all I don't speak any language which requires an input method, so my view wouldn't be worth much anyway.

As we already agreed on, it's the upstream maintainers you need to convince. And to make it more complicated, it's not obvious that the Chinese maintainers have the same view on this topic as the Japanese and Korean ones.

Chinese is the simple case, I think. There would the "us" layout be natural in most cases.

Not that easy with Japanese and Korean. Those languages have special "jp" respective "kr" XKB layouts, which are close to "us", but not quite. Instead they are designed to be used together with some input method.

To get an idea of the complexity of this topic you may want to check out the discussion at this issue:

https://gitlab.gnome.org/GNOME/gnome-control-center/issues/196