Home | News | Download | Packages | Forum | Wiki | Github

Installing Japanese Input Method


I installed ibus-anthy through xbps. However, there is no option for anthy when I try to add the input method. I figured that I may have not installed japanese fonts, but after I did still nothing shows up. Perhaps I need to change locales, but if so the several hours I spent looking into this issue did not say so. I would very much appreciate if someone who does have Japanese input on their void tell me what they did.

As a first time void user, I’m finding the utter lack of documentation on how to get foreign language input methods working very disenchanting. Perhaps I am too inexperienced to for this distribution.

[SOLVED] Setting up Chinese input?
[package request] fcitx-mozc

$ sudo xbps-install fcitx

Name Action Version New version Download size
gettext-libs install - 750KB
libfcitx install - 415KB
fcitx install - 6755KB

This installs a virtual keyboard in various languages. Only trouble is none of them work in the XFCE desktop, even the Latin one. fcitx did work in Debian 8 Gnome when I last used it a year ago. Having looked into this for a few minutes I can at least confirm there is some kind of problem. :slight_smile:

(Masato the Empty) #4

Odd coincidence. I just started playing with it the other day (I’ve never used an IME before).

I have some functionality, though it looks like using it in XFCE might be a bit tricky due to the use of both GTK2 and GTK3 applications (sounds like GTK stupidity in that both GTK2 and GTK3 would use the same environment variable)

At any rate, to get to this point, I didn’t have to do anything beyond “xbps-install ibus-anthy” which pulled in both ibus and the anthy ime. No other configuration was performed.

When I first went in to add an IME, I did have to hit the “more” button then I was able to find Japanese, and select the Anthy method from it.

Really not sure what you’re looking for in this respect. For this, and a lot of other software, Void doesn’t do anything special, so documentation provided by upstream projects should apply in most cases. Since Void doesn’t seem to have a complex framework specific to itself for the entire system (that I’ve noticed), it stands that there is less of a need to document things specifically to Void.

Not that such things would be unwelcome; far from it I think. But who is doing it?

But Void has a small core team and must rely on contributions from its community for this sort of thing. And so, documentation is sparse (what we do have, from what I’ve read as a native English speaker, is of decent enough quality as it’s pretty clear and understandable). I’ve seen it stated that good quality contributions to the wiki are always welcome.

Things don’t get better if people who see a need don’t do anything to help themselves and share with others. If you’re unable or simply unwilling to pitch in yourself where you see a need,and I don’t condemn either condition, then it’s nonetheless wholly unfair to complain that others aren’t either.


Perhaps some clues here?

$ fcitx-diagnose
# System Info:
1.  `uname -a`:

        Linux ok 4.9.7_1 #1 SMP PREEMPT Wed Feb 1 16:26:16 UTC 2017 i686 GNU/Linux

2.  `lsb_release -a`:

        LSB Version:	1.0
        Distributor ID:	VoidLinux
        Description:	Void Linux
        Release:	rolling
        Codename:	void

3.  `lsb_release -d`:

        Description:	Void Linux

4.  `/etc/lsb-release`:

    `/etc/lsb-release` not found.

5.  `/etc/os-release`:


6.  Desktop Environment:

    Desktop environment is `xfce`.

7.  Bash Version:


# Environment:


2.  Keyboard Layout:

    1.  `setxkbmap`:

            xkb_keymap {
            	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
            	xkb_types     { include "complete"	};
            	xkb_compat    { include "complete"	};
            	xkb_symbols   { include "pc+us+inet(evdev)"	};
            	xkb_geometry  { include "pc(pc105)"	};

    2.  `xprop`:

            _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""

3.  Locale:

    1.  All locale:


    2.  Current locale:


4.  Directories:

    1.  Home:


    2.  `${XDG_CONFIG_HOME}`:

        Environment variable `XDG_CONFIG_HOME` is not set.

        Current value of `XDG_CONFIG_HOME` is `~/.config` (`/home/hralgmir/.config`).

    3.  Fcitx Settings Directory:

        Current fcitx settings directory is `~/.config/fcitx` (`/home/steve/.config/fcitx`).

5.  Current user:

    The script is run as hralgmir (1000).

# Fcitx State:
1.  executable:

    Found fcitx at `/usr/bin/fcitx`.

2.  version:

    Fcitx version: ``

3.  process:

    Found 2 fcitx processes:

         1235 fcitx
         1294 fcitx-dbus-watc

4.  `fcitx-remote`:

    `fcitx-remote` works properly.

# Fcitx Configure UI:
1.  Config Tool Wrapper:

    Found fcitx-configtool at `/usr/bin/fcitx-configtool`.

2.  Config GUI for gtk2:

    **Config GUI for gtk2 not found.**

3.  Config GUI for gtk3:

    **Config GUI for gtk3 not found.**

4.  Config GUI for kde:

    **`kcmshell4` not found.**

    **Cannot find a GUI config tool, please install one of `kcm-fcitx`, `fcitx-config-gtk2`, or `fcitx-config-gtk3`.**

# Frontends setup:
## Xim:
1.  `${XMODIFIERS}`:

    **XMODIFIERS is not set**

    **Please set environment variable XMODIFIERS to "@im=fcitx" using the tool your distribution provides or add `export XMODIFIERS=@im=fcitx` to your `~/.xprofile`. See [Input Method Related Environment Variables: XMODIFIERS](http://fcitx-im.org/wiki/Input_method_related_environment_variables#XMODIFIERS).**
    Xim Server Name from Environment variable is fcitx.

2.  XIM_SERVERS on root window:

    Xim server name is the same with that set in the environment variable.

## Qt:
1.  qt4 - `${QT4_IM_MODULE}`:

    **Please set environment variable QT_IM_MODULE to "fcitx" using the tool your distribution provides or add `export QT_IM_MODULE=fcitx` to your `~/.xprofile`. See [Input Method Related Environment Variables: QT_IM_MODULE](http://fcitx-im.org/wiki/Input_method_related_environment_variables#QT_IM_MODULE).**

2.  qt5 - `${QT_IM_MODULE}`:

    **Please set environment variable QT_IM_MODULE to "fcitx" using the tool your distribution provides or add `export QT_IM_MODULE=fcitx` to your `~/.xprofile`. See [Input Method Related Environment Variables: QT_IM_MODULE](http://fcitx-im.org/wiki/Input_method_related_environment_variables#QT_IM_MODULE).**

3.  Qt IM module files:
    **Cannot find fcitx input method module for Qt4.**
    **Cannot find fcitx input method module for Qt5.**

## Gtk:
1.  gtk - `${GTK_IM_MODULE}`:

    **Please set environment variable GTK_IM_MODULE to "fcitx" using the tool your distribution provides or add `export GTK_IM_MODULE=fcitx` to your `~/.xprofile`. See [Input Method Related Environment Variables: GTK_IM_MODULE](http://fcitx-im.org/wiki/Input_method_related_environment_variables#GTK_IM_MODULE).**

2.  `gtk-query-immodules`:

    1.  gtk 2:

        Found `gtk-query-immodules` for gtk `2.24.31` at `/usr/bin/gtk-query-immodules-2.0`.
        Version Line:

            # Created by /usr/bin/gtk-query-immodules-2.0 from gtk+-2.24.31

        **Failed to find fcitx in the output of `/usr/bin/gtk-query-immodules-2.0`**

        **Cannot find fcitx im module for gtk 2.**

    2.  gtk 3:

        Found `gtk-query-immodules` for gtk `3.22.7` at `/usr/bin/gtk-query-immodules-3.0`.
        Version Line:

            # Created by /usr/bin/gtk-query-immodules-3.0 from gtk+-3.22.7

        **Failed to find fcitx in the output of `/usr/bin/gtk-query-immodules-3.0`**

        **Cannot find fcitx im module for gtk 3.**

3.  Gtk IM module cache:

    1.  gtk 2:

        Found immodules cache for gtk `2.24.31` at `/etc/gtk-2.0/gtk.immodules`.
        Version Line:

            # Created by usr/bin/gtk-query-immodules-2.0 from gtk+-2.24.31

        **Failed to find fcitx in immodule cache at `/etc/gtk-2.0/gtk.immodules`**

        **Cannot find fcitx im module for gtk 2 in cache.**

    2.  gtk 3:

        Found immodules cache for gtk `3.22.7` at `/etc/gtk-3.0/gtk.immodules`.
        Version Line:

            # Created by usr/bin/gtk-query-immodules-3.0 from gtk+-3.22.7

        **Failed to find fcitx in immodule cache at `/etc/gtk-3.0/gtk.immodules`**

        **Cannot find fcitx im module for gtk 3 in cache.**

4.  Gtk IM module files:

    1.  gtk 2:

        All found Gtk 2 immodule files exist.

    2.  gtk 3:

        All found Gtk 3 immodule files exist.

# Configuration:
## Fcitx Addons:
1.  Addon Config Dir:

    Found fcitx addon config directory: `/usr/share/fcitx/addon`.

2.  Addon List:

    1.  Found 25 enabled addons:


    2.  Found 1 disabled addons:


3.  Addon Libraries:

    All libraries for all addons are found.

4.  User Interface:

    Found 2 enabled user interface addons:


## Input Methods:
1.  Found 1 enabled input methods:


2.  Default input methods:

    You only have one keyboard input method enabled. You may want to add another input method to input other languages.

# Log:
1.  `date`:

        Mon  6 Feb 20:36:53 GMT 2017

2.  `~/.config/fcitx/log/`:

        total 0

3.  `~/.config/fcitx/log/crash.log`:

    `~/.config/fcitx/log/crash.log` not found.

(Masato the Empty) #6

I haven’t gotten as far as making it environment-wide, other than adding ibus-daemon to my xfce session autoruns, but you can play with it if you pass the GT_IM_MODULE_FILE variable to an individual application at runtime (you set it to /etc/gtk-3.0/gtk.immodules for gtk3, and /etc/gtk-2.0/gtk.immodules for gtk2). Note that having it set to gtk2 causes gtk3 programs (at least mousepad) to segfault. I don’t know if the same happens if you reverse it (gtk3 module set for gtk2 applications)

EDIT: I’m referring to ibus-anthy at this point

EDIT2: confirmed, gtk2 apps (abiword) will crash when you set the variable to the gtk3 module…

EDIT3: @hralgmir - looking at Arch docs, it seems you need to do the same thing with fcitx - gtk apps need immodules… provided by libfcitx-gtk and/or libfcitx-gtk3. wonder if they’ll have the same segfault issue.


Just thinking along the same lines…
$ xbps-query -Rs fcitx
[] fcitx- Flexible Context-aware Input Tool with eXtension
[-] fcitx-configtool-0.4.8_1 A GTK-based configuration tool for fcitx
[-] fcitx-devel- Flexible Context-aware Input Tool with eXtension - development files
] libfcitx- Flexible Context-aware Input Tool with eXtension - shared libraries
[-] libfcitx-gtk- Flexible Context-aware Input Tool with eXtension - GTK2 IM module
[-] libfcitx-gtk3- Flexible Context-aware Input Tool with eXtension - GTK3 IM module
[-] libfcitx-qt- Flexible Context-aware Input Tool with eXtension - Qt4 IM module
[-] libfcitx-qt-devel- Flexible Context-aware Input Tool with eXtension - Qt4 IM module development files
[-] libfcitx-qt5-1.0.5_1 Flexible Context-aware Input Tool with eXtension - Qt5 IM module
[-] libfcitx-qt5-devel-1.0.5_1 Flexible Context-aware Input Tool with eXtension - Qt5 IM module - development files
$ sudo xbps-install fcitx-configtool libfcitx-gtk3
But I still get some error messages from fcitx-diagnose, so I will reboot and try some more things it suggests later.


Hi, folks. Let me suggest two tips: I’ve found two pages of Void Linux’s users in Japan with instructions about how to configure it to Japanese locale! I suppose you’re able to read in Japanese, so there would be no much trouble to understand the instructions there! The first one: 日本語環境 - Void Linuxのメモ:
And the next one, specifically about uim Input Method framework :uim - Void Linuxのメモ:

I couldn’t yet read those sites and figure out how to do it (and I’m still a newbie in Linux…!)

To download and install ibus packages and/or other input Methods is easy… The tricky part (at least, for me…) is to configure locales files (which one?, where?, how?..)
If you guys get any success with this issue, please let me know! That is exactly the thing I miss with Void: a easy way to write in ‘multi-language’ configured within installing process, or through a ‘configuration central’, as in my current distro (Mageia 5, with KDE… but, with systemd… oh, boy!)

BTW, in Ubuntu 14.04 with Unity, multi-language input is quite easy to set-up, and its GUI works like in Windows! You can get at the same tool the option to change keyboard layout (for non-Latin languages like Russian and Greek, and/or even CTL languages, like Arabic, Hebraic…) and to call an IME (needed to write in Japanese, Chinese, Korean and some others). However, within Mageia /KDE , ibus isn’t so ‘integrated’ … If I want to write in Arabic (with phonetic layout, ‘Buckwalter’!), there’s no such option, and I have to call the other app, xkb, to change the keyboard layout properly… Not elegant!

Well, I hope to hear that you found how to set-up language input the way ‘We’ want!


This helped with some of the fcitx-diagnose errors:
Created this file: /etc/profile.d/fcitx.sh
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
Still not working yet.


I’m very happy to see so many replies to this topic. When I was trying to fix this problem, I searched the Void forum for keywords like Input Method, anthy, mozc, Japanese, etc, and I only found one other page relevant to my problem. In that page, there was only one post reply, and quite ironically the solution they gave assumed that I set anthy as my input method already, whereas my problem is that I can’t do so. I hope in the future people will find this thread when they are looking to get a Japanese IME on Void.

I’ve been looking at the arch documentation, and most of the Japanese IME packages listed in that documentation don’t have a void template (only ibux-anthy). I’ve also tried to compile ibus-anthy from source, but apparently the autogen can’t find void’s gettext package, so I can’t do that (idk if you can override this somehow, haven’t tried compiling enough to know how to do so).

About the gtk issues, I don’t think those are relevant to me as I run i3, so I don’t think I have any hard dependencies on gtk that are conflicting (although admittedly I have no idea how gtk compatibility works). Still great that you guys share for the people that do have that problem, though.

Also, I’m not fluent in Japanese, merely learning it, so I can’t fully understand pages linked by Andre_Luiz.

Anyway, thanks so much for the replies! I really wasn’t expecting this many.

(Masato the Empty) #11

your gtk apps still don’t know about it. But I found a missing piece that seems to do the trick for ibus (and you don’t have to set GTK_IM_MODULE_FILE, so there are no incompatibilities). It should do the same for fcitx. Of course, I haven’t tried fcitx yet, so I don’t know what other config is needed for that one.

run (sudo or root) gtk-query-immodules-2.0 --update-cache and gtk-query-immodules-3.0 --update-cache
These will write the /usr/lib/gtk-2.0/{version}/immodules.cache file (and same for the one in /usr/lib/gtk-3.0/{version}/ for the gtk3 one)

(Masato the Empty) #12

hehe, so you might get more from it than me. I don’t speak/read japanese, and at this time I’m very rusty on just the kana… My interest in an IME is just when I do find the need to type some kana/kanji, it’s always just a pain getting it done (having to go through google translate, which doesn’t help when you are trying to transliterate from romaji)

(Masato the Empty) #13

So yeah, things seem to work just fine using ibus/anthy.

@hralgmir - how you get the environment variables set depends on how you’re logging in. Since I use lightdm, I can’t put it in my kshrc or anything like that. So instead, I stuck it in ~/.pam_environment, which is shell-agnostic. (XMODIFIERS, GTK_IM_MODULE, QT_IM_MODULE) - the file just takes VARIABLE=value pairs (no globs/exports etc since it’s not a shell file. You might have to do other work for fcitx, but ibus/anthy seems to work out of the box, once you get your user environment right.

In this case, it’s simply that GTK applications will all look for relevant environment vars, as will QT progs. In reality, unless you’re strictly keeping to the brand of whatever DE you’re in (and it has its own version of everything you need), you’re quite possbly using a mixture of toolkits for various applications.


I found this last bit here:

This cleared up the last of the warnings, and fcitx works in mousepad, I had to close and reopen the XFCE terminal before it worked there too.
There is a package called im-config in Debian that deals with a lot of these installation details it seems.
Here is the procedure so far, I omitted installing 2 QT libs as they would have added a lot of deps as I have no QT apps on my OS at present, others may need that support.
3 backticks at the start and end of code make a code box in this forum incidentally.

$ sudo xbps-install fcitx fcitx-configtool libfcitx-gtk3 libfcitx-gtk
Created this file to export variables to set fcitx as IM: /etc/profile.d/fcitx.sh
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx

$ sudo gtk-query-immodules-2.0 --update-cache
$ sudo gtk-query-immodules-3.0 --update-cache
$ sudo su
# gtk-query-immodules-3.0 >/etc/gtk-3.0/gtk.immodules
# gtk-query-immodules-2.0 >/etc/gtk-2.0/gtk.immodules
# exit


(kny) #15


someone have some news about write japanese in void ?
Before installing void, I used to use ibus with anthy in a debian environment, and I remember how the installation was absolutely random.
It seems it is the same, but I still don’t know why.
I tried everything listed here and in the japanese google forum linked by @Andre_Luiz (it is absolutely the same :))
I can see the anthy input method (but the preferences are impossible to setup, the button is not active), and with the Shift+Space shortcut, I can switch between input, but… no difference, just my current French input entry…

It is really annoying, because as many of you I suppose, I really need to be able to write japanese without copying from dictionnaries or any other lame way…

I am using dwm as window manager. Maybe it is a problem ? But it finally working with Debian and the same configuration…

Does it work for someone ?

(Masato the Empty) #16

It didn’t take much modification to get it working on my own system.

  • Install ibus-anthy (which pulled in necessary deps).
  • run ibus-setup - I don’t know how important this particular step is; all the walkthroughs recommend it.
  • It advises you to set the following variables: (make sure they go into your environment; if you’re using a login manager to sign directly into X, rather than from a console login, then you should add them to ~/.pam_environment so they get set in your X logins)
  • GTK_IM_MODULE=ibus
  • XMODIFIERS=@im=ibus
  • QT_IM_MODULE=ibus
  • For GTK-based applications, there was one missing step that was needed to tie it all together:
    sudo gtk-query-immodules-2.0 --update-cache sudo gtk-query-immodules-2.0 --update-cache
  • This command puts the necessary cache file (immodules.cache) into /usr/lib/gtk-x.0/version/. It doesn’t help to have the ones in /etc

Regarding the last step - I would assume that QT applications would have worked before that last step, since that was GTK-specific. However, I did not test them first; nonetheless, they work now, and no other steps were needed related to QT, so it seems the most likely case.

EDIT: by the way, did you change the modifier keys? I don’t know if it varies between locales or layouts, but in my case (qwerty, en-us-utf8) it defaults to [super]+[space] for switching methods. When anthy is selected, you can toggle it with ctrl-j. 簡単。

(kny) #17

Hey, it is maybe because I log directly by X.
Do I need to put “export” before each line in the pam_environment, as I could do if I had to put them in my bashrc for example ? --EDIT-- no export :slight_smile:
(and by the way, why put them in this file, pam_environment, instead of the bashrc ?)

It seems it was the .pam_environement file I needed. It works finally, thank you so much @masato !
But my question about the Why about the pam_environment file is hold good :slight_smile:

(Masato the Empty) #18

bashrc is only sourced when running bash. When bash isn’t involved, neither is .bashrc or any other related files.

There are other places you could splice the environment variables into, and I suppose it depends on your DE; you have to put them somewhere that they will get sourced into your X session. But .pam_environment is there for all login environments on systems that use pam, so why not use it? The cases where you wouldn’t want to use it would be when you have variables that should only be set conditionally, since .pam_environment is not shell code; and if I read correctly, variables there always get set in all login sessions handled by pam.

(kny) #19

Thank you for all these explanations !


It’s beginning to get clear! :slight_smile: But I still have some doubts…

So, one must create (in case there isn’t yet) the file .pam_environment , right? However, which directory I may put it ?.. Whenever mentioned ~/ and I can’t figure out exactly where it is! (/etc/ , /usr/share/, etc). Or, does the location vary according to the chosen DE?.. :confused: In my case, I’m running LXQt by now, but I intend to try other DEs (KDE, which I’m already familiar… ; or LXDE ; or Lumina ; or Budgie… I don’t know!)

Thanks for sharing knowledge! :slight_smile: 知識を習いさせて有難うございます。

(Masato the Empty) #21

~ is always the user’s home directory in Unix shells. (/home/masato or /home/andre, etc)
Files there are be created by the user, either directly, or by running some program which touches them.