Translation IME Candidate Window Covers Text or Drifts? Position Fixes

A visible candidate list in the wrong place is a position issue; an absent list is not.

When a Translation IME candidate window covers text, blocks the input field, or appears far from the caret, investigate app zoom, system display scaling, multi-monitor coordinates, and input focus. Do not begin with hotkeys: if the key action produces candidates but the window lands incorrectly, another app has not stolen the shortcut.

Type the same short phrase in the system plain-text editor and watch whether the window follows the insertion caret. If it works there but drifts in a browser or chat app, the scope is that app or web input. A similar offset everywhere points instead to display scaling or monitor layout.

Visible candidates in the wrong language belong to language-pair troubleshooting. No candidates anywhere belong to the missing-candidate guide. Separating “visible but misplaced” from “not generated” avoids unnecessary reinstall attempts.

If plain text works, isolate the app before changing global IME settings.

Restore page zoom or interface scaling to its default, then close and reopen the affected tab, document, or chat window. In a browser, compare a normal single-line field with the failing editor. A working address bar and broken web editor points toward the page component or page zoom.

Full-screen views, split panes, collapsed sidebars, and floating editors can alter the reported input rectangle. Leave full screen, move the app to the center of the display, restore a normal window size, and test in a fresh text area.

If the installed version visibly offers candidate appearance, horizontal or vertical layout, font size, or follow-caret controls, change one control at a time and retest. Labels depend on the current build; do not invent or follow an old screenshot for a “reset candidate window” menu that is not present.

An offset that changes with scaling is stronger evidence than a reinstall result.

Record the display resolution and system scale, then temporarily choose a neighboring recommended level. Fully quit and reopen the target app; sign out and back in if needed so both the IME and app reread the display metrics. Changing page zoom without restarting can leave stale coordinates.

On Windows, check whether the affected app has a separate compatibility DPI behavior. On macOS, verify whether the app is running in a low-resolution mode. Change only controls you can see and preserve the previous value; one failing app is not a reason to force every monitor to the same scale.

If one scale level is stable, use the readable stable setting and record the combination of system scale, app zoom, and versions. Stop after position is restored. If every level shows the same offset, continue to monitor layout and focus checks.

A window on another display or screen edge often follows a recent layout change.

After disconnecting a secondary monitor, dock, or remote session, move the app to the center of the primary display, fully close it and the visible IME interface, then reopen it. If one display works, reconnect the monitor and make the OS layout match its physical left, right, above, or below position.

With mixed scaling, move the entire app onto the target display before opening a new input window; do not leave it spanning two screens. If drift happens only after sleep or a cross-screen move, close that window and reopen it on the destination display.

Remote desktop, virtual machines, and screen sharing add another coordinate mapping layer. Test the local app before the remote session. If only remote input drifts, record client scaling, session resolution, and full-screen state for environment-specific troubleshooting.

The coordinates may be valid for an input control that still owns focus.

Click a blank area, explicitly click back into the intended field, press Escape to end an unfinished composition, and type a new short phrase. Close unused dialogs and overlays when the page contains several editors or search boxes, because a hidden input can retain focus.

If candidates remain beside the previous line, message, or window, type one character in another app and return. A plain-text editor that accepts new focus while the target app does not points to the app input area, not a hotkey conflict.

When the app visibly lags and the candidate window catches up with the caret late, position may be a symptom of performance delay. Use the high-CPU and lag article to inspect background processes and candidate prefetch; changing scale and process settings together destroys the useful comparison.

Change one variable, test the same phrase, and stop when the normal workflow passes.

Verify in this order: plain-text editor, normal window in the original app, original input field, then secondary-display or full-screen use. At each step, enter the same phrase and note overlap, distance from the caret, and behavior after moving the window.

A pass means candidates no longer cover the active text and continue to follow the caret, app window, and destination display. If only one website or remote session fails, save the OS, app and IME versions, scaling values, screen layout, and screenshot.

Once candidates generate in a stable position, leave hotkeys, language pairs, and dictionaries alone. Route silent shortcuts to hotkey conflicts, wrong candidate language to pairing, a missing list to missing-candidate troubleshooting, and emoji or special characters that will not insert or render as boxes to the emoji/symbol article.