翻译按钮应置于待译文本右上角，悬停显色；推荐调用 LibreTranslate 或 DeepL 免费 API，严格传 zh-CN/zh-TW 等完整语言码，仅替换 textContent 避免闪屏。

翻译按钮该放在哪里才不打断阅读流

用户真正需要的是“随时可译、译完即走”，不是多一个悬浮窗或侧边栏。把按钮塞进页头导航或文章末尾，都会强迫用户跳转视线——最不干扰的方案是紧贴待翻译文本的右上角，用小字号 + 半透明背景，鼠标悬停才显色。

实操建议：

• 用 position: absolute 定位，父容器需设 position: relative
• 避免用 fixed 或 sticky，否则滚动时按钮会遮挡其他内容
• 移动端要额外加 touch-action: manipulation，防止长按触发系统翻译菜单冲突

点击后调用哪个翻译 API 最省事

浏览器原生 translate() 不可靠（Chrome 已移除，Firefox 仅限部分页面），直接调用 google.translate.TranslateElement 又重且不可控。推荐用轻量级方案：先检测 navigator.language，再发请求到免费可用的 libretranslate 自建服务或 DeepL API 免费 tier（每天 50 万字符）。

关键点：

立即学习“前端免费学习笔记（深入）”；

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

• fetch 请求必须带 Accept-Language header，否则返回语言可能错乱
• 不要在按钮点击时重复初始化翻译实例，用单例缓存 translateService 实例
• 对中文内容，source: 'zh' 必须显式传，否则自动识别常误判为日文

切换语言时 DOM 怎么更新才不闪屏

整页 location.reload() 或替换 document.body.innerHTML 都会导致样式重绘闪动。正确做法是只替换文本节点，保留所有事件监听器和结构。

实操建议：

• 遍历所有含 data-i18n 属性的元素，用 textContent 替换，不用 innerHTML
• 遇到 <input placeholder> 或 <button></button> 这类属性文本，需单独处理 el.setAttribute('placeholder', ...)
• 若用了 CSS-in-JS（如 Emotion），确保翻译后调用 cache.resetCSS() 避免样式丢失

用户选了“简体中文”但页面显示繁体怎么办

这不是按钮逻辑问题，而是语言代码没对齐：zh-CN 和 zh-TW 是不同 locale，但很多翻译服务把二者都映射到 zh，导致返回结果随服务端配置浮动。

解决方式很具体：

• 前端发送请求时，target_lang 参数必须严格用 zh-CN / zh-TW，不能只写 zh
• 后端翻译服务（如 LibreTranslate）需确认是否启用 --frontend 模式，否则忽略子标签
• 本地 fallback 词典里，zh-CN 和 zh-TW 的键名必须分开维护，例如 submit_btn: { 'zh-CN': '提交', 'zh-TW': '送出' }

实际最难的不是按钮样式或 API 调用，而是语言代码在前后端、服务间、甚至 CDN 缓存层的传递一致性——漏掉一个 - 或大小写错误，用户就看到“你好”被翻成“こんにちは”。