Japanese input in FreeBSD-10

I haven't seen anything about this save for similar comments about fcitx.

I've always been able to input Japanese in FreeBSD without too much work, following the steps on my own page, at http://www.srobb.net/jpninpt.html.

However, with FreeBSD-10, on a few machines, with a few different desktops, I'm having a notable lack of success. I've been using the japanese/ibus-mozc, but getting similar results if I use japanese/ibus-anthy.
Where I used to be able to change between Japanese and English with a key combination--I've always used ctl+shift--though the new default is super+space, one can change it to ctl+shift easily. (I also tried with super+space, keeping defaults, with the same result.)

Now, however, I find that the only way to shift is to repeatedly, in a GTK app, hit clt+space till I see an icon. I can then click that icon to choose input. This choice will then affect anything else capable of showing Japanese--that is, if I chose kana input in firefox and then open urxvt, the text in the terminal will be input in kana (Japanese phonetic characters.) To get back my English input in a new terminal, I have either kill the ibus-daemon or go back to a GTK app (I can't get this icon to appear in, say, a terminal), and choose direct input.

At this point, I'm just wondering if anyone who sees this has gotten Japanese input with japanese/ibus-mozc working to the point where they can change between Japanese and English input with the keyboard shortcuts they define in ibus-setup?

To answer what might be the standard questions, I've added the suggested variables from the package message to .bashrc, tried with a few different window managers with more or less the same results, and also set my LC_CTYPE to en_US.UTF-8, all with no success. So, I can get Japanese but switching between the two becomes more difficult than it has been for many years. (Or, I can always go to google translate, pick Japanese as my input language, and type my text that way, but that's even more roundabout than fiddling with mouse clicks on icons.)
 
Somewhere between the January 10.0-RELEASE and today, the latest/ branch of packages updated to a newer version of ibus that introduced that awful Super+Space selection window.

I recommend you unbind that shortcut in the preferences, and create this shell script (ibus-switch.sh) in /usr/local/bin with chmod +x instead:

Code:
#!/bin/sh
if [ `ibus engine` = 'anthy' ]; then
  ibus engine xkb:us::eng
else
  ibus engine anthy  #or whatever IME you prefer; change it above too.
fi

Or extend the script if you want 3+ languages to cycle through.

Now bind the script to Ctrl+Space via whatever desktop you use. For Xfce, it's under Settings->Keyboard->Application Shortcuts. That will get you back to being able to toggle between two languages instantly with no popup windows and from any application/input sink.

Alternatively, ibus also has the advanced tab setting to share the input method across all applications. You might wish to uncheck that? Or if you use anthy, its settings has a key binding tab with an on/off toggle of Ctrl+J by default. That'll let you stay in anthy but toggle between current input (hiragana/katakana) and latin. Downside to it is that it's not a standard key mapping. = becomes ^, etc. Haven't found a way to configure that. The key bindings to toggle between hiragana/katakana/latin directly seem to not work, though.
 
Thanks. I'm not sure when that change was made either, I think I first noticed it in one of the Ubuntus, and at the same time, a lot of folks on the Tokyo Linux list began complaining. I know on one of my preferred window managers, x11-wm/dwm, super+space is used (in my custom configuration) for something else.

I've been using mozc, so I'll try that script with the alternation and see if I have any luck.

It is a pity though, Japanese input for me was pretty trivial since FreeBSD 5, I think, and it's only with FreeBSD 10 that I've begun having issues.
 
Okay, I just tried this and it almost fixes things. I tried it with anthy, rather than mozc for starters. It worked just about perfectly in editors/libreoffice and www/firefox. With the x11/rxvt-unicode terminal it was a bit peculiar. If started with the standard keyboard shortcut I have in my x11-wm/openbox configuration, it wouldn't switch input. The same thing happened if I started it from x11/dmenu. However, if I opened it from a command -- that is, open one terminal then type urxvt into that terminal -- the resulting terminal would successfully switch back and forth.

I see what you mean about keyboard bindings. I was able to quick find how to be able to type =---it was one key over, the - key. However, couldn't find @.

Now, if in editors/libreoffice, I typed an @ or an = sign, they worked. I was also able to get it working by toggling ctl+space.

I then tried with mozc, modifying the script. However, with mozc, it seems to be the same problem as before, I can't switch back to Latin. Regardless, your script has been an enormous help, making it, if not quite trivial, at least usable.

Thank you again.
 
Tried out ibus-mozc for fun. Very nice. I especially love that it comes with an IME drawing pad for unknown kanji. Too bad it uses Qt. I like Qt, but I had zero Qt-depending apps otherwise. Well, at least it's not dependent on Mono like bless. I think I'll try switching from anthy.

I am not sure why it's not switching for you on a new urxvt terminal. I use Xfce4 and xfce4-terminal, and it switches okay there. I can also switch with Xfce4 and xterm.

As a note for everyone: xfce4-terminal (and gnome-terminal) use libvte to provide the GTK+ terminal widget. This library does something that causes /bin/sh to immediately exit (not crash, the spawned sh process returns 0 to libvte in < 1s) periodically on FreeBSD. So there's a ~1:20 chance of opening your terminal and having it close instantly. libvte catches sh closing and then sends a kill signal to your terminal emulator, which makes the whole thing close. I couldn't figure out why this was happening, because I wasn't about to debug a base system binary myself. Probably has to do with the Gnome devs not caring at all about the BSDs as per usual, and doing something that only works on Linux shells. I found that by setting my shell to bash, that the problem with libvte went away. Terminals like urxvt which don't use libvte are unaffected.

So, possible causes:
* urxvt is blocking Openbox from seeing ctrl+space (perhaps secure input mode? Or something to do with not being GTK+-based?)
* Openbox isn't hooking the keyboard the same way as Xfce4, so it is responsible for not invoking your hotkey to the shell script

My bet is on it being an Openbox key binding issue, given that Xfce4+xterm work okay for me. If you were willing, I'd recommend giving xfce4-terminal a try, since it's a pure GTK+ app, just to see if it works.

If you want to stick with Openbox+urxvt, my best advice would be to put a launcher icon on your dock/taskbar/whatever, so you have a button you can click to toggle inputs when the shortcut fails. Try testing non-IME shortcuts to urxvt and send bug reports to the appropriate teams to see if they can fix it for a future release.

がんばって!
 
I've now tried on two machines, and though I'm not getting completely consistent results, at least I'm getting something usable. One machine began working perfectly with urxvt. No changes that I am aware of. On the second machine, it's somewhat odd. I can input Japanese, but then, when I hit enter, it's blank. However, in Firefox and LibreOffice, it works without problem. Also, on this second machine, when I start urxvt from an existing terminal, Japanese does show up. It's one of those quirky things that I'm not going to spend too much time solving, since, with that workaround, I can get what I need.

I wasn't able to get mozc working though. I tried using your script, just subbing mozc for anthy, but it still wouldn't switch back.

However, I can now at least use Openbox, and urxvt, at least on one machine, with Japanese with almost as much ease as I can with Linux.
ありがとうございます。助けてくれました。(Although actually, I'm typing this on a Linux machine,)

For my fairly limited Japanese needs, your script with anthy will be fine. It's a bit late here, so I may try again with mozc tomorrow, but prior to your post, I couldn't get either one working.
 
I can input Japanese, but then, when I hit enter, it's blank.

Oh, that's a locale issue. It defaults to ANSI on FreeBSD.

Code:
echo export LC_ALL=en_US.UTF-8 >> ~/.bashrc
echo source ~/.bashrc > ~/.bash_profile

Now restart Xorg for it to take effect.

I tried using your script, just subbing mozc for anthy, but it still wouldn't switch back.

It's something different, like mozc-jp. If you set the engine on, put it in direct input mode, and type ibus engine on the terminal, it'll tell you the name.
 
Bah, I should have caught that about LC_CTYPE. (Or LC_ALL). I already had it on the machine that was working as desired, and didn't have it on the machine where the text wouldn't show in a terminal.

You are correct, it is mozc-jp for the engine name. However, I still didn't get it to work--whether it's an x11-wm/openbox issue or not, I don't know, but, though I prefer mozc to anthy, for the nonce, I'll just stick with what's working well for me.

Thanks again.
 
This is totally off the topic, but..??
I use English keyboard.
When I use the japanese/ibus-mozc on FreeBSD 10.0 on Xfce ,I change between Japanese and English input with F3.
I only change Keymap style in Japanese-Mozc.
日本語で何も困ってないよ。
 
Well, as the OP, I'm not going to say it's offtopic, because when the thread started, I was totally unable to switch input. Was F3 a custom shortcut, or possibly an Xfce thing?

At @byuu, after a restart, I _was_ able to use mozc with your script. I'm not sure why it didn't work the first time, I may have had to log out first.
 
Last edited by a moderator:
To add, for anyone who comes long to this thread:

After testing various combinations of various things, it seems that at least in x11-wm/openbox and x11-wm/dwm, the hotkeys that one chooses in ibus-setup don't work. However, if one uses the script that @byuu provided, either using anthy as shown or mozc-jp if using mozc, one can switch back and forth between Japanese and English. The hotkey combo can be anything you chose to make it in your window manager, e.g., in x11-wm/openbox, I set ctl+space to call the script in my $HOME/.config/openbox/rc.xml. In x11-wm/dwm I set it to mod4+y, in a custom config.h.

I also found that if japanese/ibus-mozc (or its anthy variant) is running, the default input is Japanese. However, as long as you have the script created, if you have some sort of keyboard shortcut to x11/dmenu you can open dmenu to call the script, and it will switch you back to English. So, for example, if you were using x11-wm/dwm, and manually start ibus with ibus-daemon --xim & you will have Japanese input. If x11/dmenu is installed, and you've used defaults, but have created the script, you can open dmenu with alt+p, the default--assuming you haven't used a custom config.h, and type whatever name you've given the script in there--assuming the script is in your $PATH, it will then switch back to English.

Once again, many thanks to byuu for that script. It basically replaces the hotkeys, at least in the two window managers that I usually use.
 
Last edited by a moderator:
In the interim, I've found that at least with FreeBSD-11, I can get this to work without byuu's script. I haven't yet tested with FreeBSD-10.x and probably won't until Sunday, but as this thread seems to be a common hit when googling FreeBSD and Japanese, figured I'd mention it.

So, regardless of window manager, it seems that if I open the tint2 bar, (which I don't use with my usual window manager, but it doesn't really matter), there will be an icon, either showing US or Japanese. With japanese/ibus-mozc it's an icon with a hiragana "a" (あ). Click on the icon till you get the option saying "Japanese - Mozc". When you get that, you'll get a menu giving an option of direct input or other things, including hiragana. Choose hiragana, and all works well in any app supporting Japanese, including x11/rxvt-unicode. You can close tint2 once you've made this selection, and, at least in my experience, after that, the ctl+space keyboard shortcut from the setup menu will work. Again, I've only done this in FreeBSD-11 so far, not sure how it will work in FreeBSD-10.

It's an annoying workaround (unless you use tint2 but it's working fairly well for me so far.

EDIT: Ok, just tested on FreeBSD-10.1 and it works there too. I needed a reboot to get it working with urxvt but everything else worked fine. So, I am not sure what tint2 does, but it gets things working.
 
Somewhat offtopic on my part but I am no longer responding to an ancient thread.

Domo arigato gozaimastita

どうもありがとうございました

Thank you very much, this has actually helped me and my gf (in the same order, no disrespect) and I applaud you for taking the effort to share the whole thing with us.
 
I also discovered this morning that this doesn't work as well with multiple monitors. The tint2 method with dwm doesn't have an icon to work with textproc/ibus. Openbox does. With fluxbox it shows on its taskbar, but one has to manually, that is, with the mouse, choose direct input and hiragana. With spectrwm shows the icon with tint2, but you have to use the mouse to choose. So, if you must use it with multiple monitors, at this point, I'd say openbox is your best bet, but you need byuu's script to use it without the mouse.

HOWEVER. I can use this method, combined with byuu's script,with dwm and the taskbar trayer. Start ibus-daemon, start trayer I get the icon.

I'll have to play with it a bit more, and then I'll put the information up on my page about Japanese input.
 
Last edited by a moderator:
After more investigation, I've found that it's actually much quicker and easier to do this with the japanese/fcitx-mozc port. I've updated my page (linked in an earlier post). If curious, look at the FreeBSD section and go down till you get to the part for FreeBSD-10. (Or search for FreeBSD-10 on the page, and when you get there, search for fcitx. One of these days I will make a TOC for it, but not today)
 
Back
Top