Engine name is "mozc-jp" though keyboard layout became not selectable in non Chrome OS about mozc HOT 4 CLOSED

Thanks for the report.
Hmm.. this looks like a code clean-up task rather than a bug since I don't 
think ibus engine ids are visible to users...

Can you let me know if there are any problems that are user-visible regarding 
the engine id.  I'd keep the code as it is for now if there aren't any, 

> though the keyboard layout other than Japanese can't be selected in this 
revision

It's not exactly true.  If the --enable_us_engine command line option is 
specified, an alternative engine for US keyboards, "Mozc (US keyboard layout)", 
should appear in the ibus-setup dialog.  And your patch seems not to work fine 
with the command line option since ibus-daemon is not able to handle two or 
more engines that have the same engine id (i.e. "mozc").  For example, if your 
patch is used with the option, Shift+2 generates ＠ (full-width at sign) 
character even with the "mozc-jp" engine.

Kana input mode in ibus-mozc also requires a dedicated engine id for each 
keyboard layout in order to select a correct ASCII-to-Kana mapping table:
http://code.google.com/p/mozc/source/browse/trunk/src/unix/ibus/mozc_engine.cc#4
28

> I don't think ibus engine ids are visible to users...

ibus.el, client for Emacs I wrote, shows engine name in the mode line as 
"IBus[mozc-
jp]". I think "mozc-jp" occupies unnecessarily large width.

> If the --enable_us_engine command line option is specified, an alternative 
engine 
for US keyboards, "Mozc (US keyboard layout)", should appear in the ibus-setup 
dialog.

Oops, sorry, I've not known it.

> And your patch seems not to work fine with the command line option since ibus-
daemon is not able to handle two or more engines that have the same engine id 
(i.e. 
"mozc").

I see. But currently the relations between engine names and longnames are 
inconsistent:

  mozc-jp => Mozc
  mozc    => Mozc (US keyboard layout)

I think engine names for JP and US keyboard should be changed to "mozc" and 
"mozc-
us", respectively:

  mozc    => Mozc
  mozc-us => Mozc (US keyboard layout)

I see your point, but I'm still wondering how severe the string width problem 
is, and also wondering why you don't take an approach which is compatible with 
ibus-setup and the language panel. They always use <longname> (and <language> 
for some places) rather than the <name>. Contrary to the implications of its 
name, 
longnames in major ibus engines are not that long :)

FWIW, in the meanwhile, it is a bit difficult to change the engine name in 
ibus-mozc for some reasons, especially on Chrome OS which has a "Sync user 
preferences with Cloud" feature.


> But currently the relations between engine names and longnames are 
inconsistent:

From the perspective of Chrome OS whose primary keyboard layout is US, I 
believe it's consistent.

  mozc    => Mozc (US keyboard layout)
  mozc-jp => Mozc (Japanese keyboard layout)

Closing this as WontFix for now. Thanks.

> ... why you don't take an approach which is compatible with ibus-setup and 
the 
language panel.

ibus.el needs to show users the unique names of engines because the function 
'ibus-
enable' requires the users give an unique name to specify which engine is 
activated 
(See http://d.hatena.ne.jp/iRiE/20100530/1275212234). The longname, however, is 
not 
unique. ibus-m17n uses the same longname for multiple languages.

> Contrary to the implications of its name, longnames in major ibus engines are 
not 
that long :)

Mozc engine's longname "Mozc (US keyboard layout)" is too long! Displaying this 
longname in mode line is really annoying... (See screenshot)

> ... especially on Chrome OS which has a "Sync user preferences with Cloud" 
feature.

I see, but I can't still understand why mozc provides two different engines for 
the 
same input method. I think keyboard layout should be selected in mozc 
properties 
tool.

Thanks.