Translation IME on Linux Types Nothing? IBus/Fcitx Framework & Env Checks
Installed ≠ typing: pin framework and session env to desktop docs—no unverified commands.
When Translation IME installs on Linux but types nothing, confirm whether the session uses IBus or Fcitx/Fcitx5 and that the component is enabled in that framework, then match session-level IM environment variables to your desktop environment docs and re-login—do not paste unverified distro export one-liners. FAQ support lines are scope only; on macOS, check privacy permissions instead of reusing Linux framework steps.
1 Separate “installs but cannot type” from no-translation and FAQ blurbs
On Linux, three failures often collapse into “the IME is broken.”
Translation IME on Linux installs but typing fails: the package or component is on disk and may appear in lists, yet plain text fields show no candidates, no commit, or a dead keyboard after switching. Causes usually sit in whether IBus/Fcitx loaded, and whether the desktop session’s input-related environment matches.
Candidates work but never translate → not-translating guide. Candidates appear but language/direction is wrong → wrong-candidate-language pairing article. Only some shortcuts die → hotkey conflicts. Typing works but fans roar → high-CPU / prefetch. FAQ distro lines are scope summaries; detailed routing lives in the Linux FAQ ↔ framework guide article.
Thirty-second check: try a stock desktop text editor (not an IDE with its own input stack). Zero candidates → stay here. Candidates without translation → switch articles. Do not uninstall first.
2 Confirm the active framework: IBus, Fcitx, or Fcitx5
Two frameworks installed does not mean the current session uses the one you configured.
In system settings or the desktop’s Region & Language / Keyboard / Input Method pages, see whether IBus, Fcitx, or Fcitx5 is active. Trust your distro’s desktop docs for labels—do not force-match forum menu paths.
Open that framework’s config UI and check whether Translation IME is added and enabled. Missing from the list: return to the download page for Linux notes and source checks, then follow the on-site IBus/Fcitx guide’s “does the component appear” steps—do not invent apt package names.
Listed but still no keystroke response: the session often was not reloaded, or login is bound to another framework. Save work, log out and back in (or restart the IM daemon per desktop docs), then test a short phrase.
3 Environment variables and sessions: match docs, skip unverified commands
Wrong IM module variables look like “framework OK, every app silent.”
Linux input often depends on session-level variables (discussions commonly mention GTK/Qt IM modules and IM-daemon related vars). Which ones to set, and whether they belong in user config or the desktop session script, follows your desktop environment’s official docs—this site does not invent per-distro export lists.
Triage is comparison only: do the variable names your desktop docs require match the current session? Are you on Wayland while still carrying an X11-only legacy config? Fix the session per those docs; do not temporary-export inside every terminal window.
After session-level changes, re-login before acceptance. Typing works only in one terminal but not in GUI apps means variables entered the shell, not the desktop session—that is placement, not a corrupt IME package.
4 Wayland, X11, and app-only failures
Change the session protocol and yesterday’s config can fail quietly.
The same distro can log you into Wayland or X11. If typing fails in only one session type, check whether the framework supports that session and whether desktop docs split IM guidance by protocol—before reinstalling Translation IME again.
Browsers or Electron apps silent while the system text editor works: suspect the app’s own input/hotkey layer first, then global framework. Stolen shortcuts → hotkey article; global no candidates → keep digging env.
Tablet mode or an on-screen keyboard can reroute input. Disable the screen keyboard, retest with a hardware keyboard in a plain field, so you do not blame the framework for focus theft.
5 Contrast with macOS privacy: do not reuse the wrong platform fix
Both feel like “cannot type”; the checklists diverge.
macOS: Input Monitoring / Accessibility (and related privacy rows) off → input source selectable but keys unread—see the macOS privacy article.
Linux: there is no equivalent “Input Monitoring” narrative. The peer checks are which framework is running, whether the component is in its list, and whether session env matches desktop docs. Porting Mac privacy steps to Linux wastes time.
Dual-boot users mix them often: Input Monitoring fixed Mac yesterday; today on Linux they hunt “Accessibility” tutorials. Match the platform first.
6 Acceptance order: return to Download only after five checks
Reinstall will not fix “wrong framework on this session” or “vars only in the shell.”
Verify: (1) one active framework, running; (2) Translation IME listed and enabled; (3) session IM env matched to desktop docs, then re-login; (4) system text field shows stable candidates and commit; (5) retest office/browser. Fail (1)–(3) → this page and the IBus/Fcitx guide. Candidates without translation → not-working. Candidates with wrong language → wrong-candidate-language. Lag → high-cpu.
Still no candidates after five steps: confirm the Linux package and release notes on Download, and use the source-check guide—avoid stacking third-party “one-click fix” scripts.
Support scope and reading order: Linux FAQ routing; stepwise enablement: on-site Linux framework guide. This page owns “installs but cannot type” at the framework/env layer only.
Continue Checking
FAQ
The package is installed and Translation IME appears in settings, but Terminal and browsers type nothing. Why?
A successful install only means files are on disk. Linux still needs IBus or Fcitx (including Fcitx5) to load the component in the current desktop session. If the framework is not running, you have not re-logged into the session, or session IM environment variables disagree with the desktop, the menu “has” it while keystrokes produce no candidates. Confirm framework and session before chasing lexicons or translation output.
Should I paste a forum one-liner like export GTK_IM_MODULE=fcitx?
Do not follow blindly. Distros, GNOME/KDE, and Wayland vs X11 differ on IM module variables; an unverified export may affect only one terminal—or fight the desktop’s own config. Match the “input method / IM module” chapter in your desktop environment docs and the check order in the on-site Linux IBus/Fcitx guide. Package names and commands not listed on the release page are not recommendations from this site.
Is this the same class of failure as macOS Input Monitoring being off?
Same feeling—“installed but cannot type”—different root cause. On macOS, privacy toggles (Input Monitoring / Accessibility) are common. On Linux, the usual culprits are the input framework, session environment, or Wayland/X11 not attaching the component. Use the macOS privacy article on Mac; stay on this page and the framework guide on Linux—do not map “enable Accessibility” onto Linux.
FAQ says Ubuntu 20.04+. I installed within that range and still get no candidates. Out of support?
Not necessarily. FAQ summarizes support scope; it does not mean desktop integration is finished. Read the Linux FAQ routing article to pick the right guide, then use this page plus the IBus/Fcitx guide for framework and session checks. Inside the listed versions with no typing, prefer framework/environment over declaring “unsupported.”
After framework and session checks, grab the current Linux package from Download
If you are ready to install or update, return to the download page and verify the current public version, platform notes, and on-site release information.