Firefox 社群討論區

I've followed all of Firefox's suggestions for translating web pages without success. (I have the latest version of Firefox.) No translation panel automatically opens when I visit a page in French. I have no translation icon in the tool bar to click, and "translate page" doesn't appear in any Firefox drop-down menus. No translation options appear when I right click on the web page. Any suggestions?

My browser constantly tries to guess the language of web pages and offers me translations. These functions get in my way, I don't need them. How to switch off any translations (and translation offers) forever for all sites?

Hello!

I'm a Japanese user who recently started using Firefox, and I have a question.

I've noticed that Firefox's built-in translation feature is somewhat less convenient than those of Edge and Chrome, especially when I want to translate pages into my native language (Japanese) regardless of the language Firefox detects.

For some reason, when Firefox identifies a page as Japanese, it doesn't offer the one-click translation option, even if the page contains a lot of English text.

To work around this, I have to click the ≡ menu on each page, change the source language from Japanese to English, and then change the target language from Japanese to English.

Does anyone have any ideas for making this translation process smoother?

Any suggestions would be greatly appreciated.

Thank you!

Environment: - Firefox 157.0.1 (64-bit) - Windows 11 (build 26100) - IME: Microsoft Pinyin (TSF)

Steps to reproduce: 1. Open any page with a text input (e.g. chat.deepseek.com). 2. Type quickly in Chinese Pinyin, e.g. "zuihou". 3. At some point during composition, the current composition ("zu") is committed as raw pinyin (with the apostrophe separator preserved), and the next key ("i") starts a new composition.

Expected behavior: - The composition should continue normally, and all keys should be consumed by the IME. - No raw pinyin string should ever be committed.

Actual behavior: - Firefox delivers the key event to the web page with keyCode 73 ("i") instead of keyCode 229 (Process), so the IME never receives it. - The IME's internal composition state stays at "zu" while the browser display has already moved on. - When the next key arrives, the IME commits the stale "zu" as raw pinyin and starts a new composition. - This results in the composition being split into two parts, with the first part committed as raw pinyin containing the "'" separator.

Additional context: - The problem occurs only in Firefox. In Edge (Chromium) on the same machine, typing the same sequence for several minutes never reproduces it. - It does not occur with every key; only certain keystrokes are affected, and it seems to require fast typing. - The issue is not caused by keyboard hardware, third-party software (AutoHotkey, yasb, PixPin, Intel drivers, MuMu), or key injection. A low-level keyboard hook log shows no injected events (inj=0 for all 204 keystrokes).

Log excerpt (from a JS composition probe injected into the page): [ime] 04:20:54.740 keydown key=Process isComposing=false keyCode=229 repeat=false [ime] 04:20:54.740 COMPOSITIONSTART data="" [ime] 04:20:54.741 compositionupdate data="z" [ime] 04:20:54.831 keydown key=Process isComposing=true keyCode=229 repeat=false [ime] 04:20:54.833 compositionupdate data="zu" [ime] 04:20:54.928 keydown key=i isComposing=true keyCode=73 repeat=false <-- key 73, not 229 [ime] 04:20:55.324 keydown key=Process isComposing=true keyCode=229 repeat=false [ime] 04:20:55.326 COMPOSITIONEND data="zu" <-- stale composition committed [ime] 04:20:55.327 COMPOSITIONSTART data="" [ime] 04:20:55.327 compositionupdate data="h"