不推荐在生产环境用 Google Translate API 做批量新闻翻译，尤其用于双语对齐语料：它打乱段落结构、吞HTML标签、术语和长句翻译不稳定，易触发429/403错误；官方库失效，替代方案需付费或复现TK算法；翻译结果含冗余符号、丢失格式、专有名词错乱，且违反服务条款禁止构建平行语料库。
直接上结论：不推荐在生产环境用 Google Translate API 做批量新闻翻译，尤其当目标是双语对齐语料时。它会打乱原文段落结构、吞掉 HTML 标签、对专业术语和长句翻译不稳定，且容易触发 429 Too Many Requests 或 403 Forbidden 错误。
requests + BeautifulSoup 抓取双语页面时，别硬拆再翻译
很多双语新闻站（比如 news.iyuba.com、bbc.com/zhongwen）本身已提供中英对照结构，HTML 里常有明确区分，例如：
<div class="article-en">... 和 <code><div class="article-zh">... <li>同一 <code><p></p>下用<span lang="en"></span>/<span lang="zh"></span>包裹- 英文标题在
<h1></h1>，中文标题在相邻<h2></h2>或<div data-lang="zh"> <p>此时应优先用 <code>BeautifulSoup.find_all()按属性或 class 精准提取两组文本，再 zip 对齐。强行统一抓英文页 → 调 Google API → 存中文，反而丢失原始排版逻辑和上下文一致性。真要用 Google Translate API，必须绕过默认 client 的坑
官方
googletrans==4.0.0rc1库已失效，返回空结果或AttributeError: 'NoneType' object has no attribute 'group'。可行方案只有两种：
Work Productivity Gog Google Workflow Helper下载帮助用户满足已验证的需求：代理用户在Clawhub上对Gog式工作流有强烈需求，需要实际帮助修复bug、强化设置等。
- 改用
google-cloud-translate（需配GOOGLE_APPLICATION_CREDENTIALS环境变量和付费账号），调translate_text()方法，支持批量、指定模型（nmt或base） - 退而求其次，用 requests 手动发 POST 到
https://translate.googleapis.com/translate_a/single，但必须构造正确sl（源语言）、tl（目标语言）、q（文本）、tk（动态 token）。这个tk是 JS 生成的，Python 里得复现算法，稍有改动就失效
注意：
q单次最大长度约 5000 字符，超长需切分；中英互译建议显式设sl=zh/tl=en，否则自动检测在短句上极不可靠。翻译后清洗比爬取更耗神
即使翻译成功，输出也常含冗余符号和错位换行：
- Google 返回的 JSON 里，
[["Hello","你好"], ["world","世界"]]这种二维数组，要 flatten 成单层字符串就得小心处理嵌套 - 原文带
<strong>China</strong>，API 返回纯文本 "China"，格式信息彻底丢失 - 数字、专有名词（如 "DeepSeek"、"天舟九号"）可能被意译或音译错乱，需后置白名单替换规则
- 中→英常把“新华社”译成 "Xinhua News Agency"，但英→中却返成 "新华通讯社"，而非更常见的“新华社”——这对语料对齐是硬伤
真正省事的做法是：只对无法获取双语源的单语页做翻译，并且把翻译结果和原文哈希值一起存库，后续人工抽检+关键词过滤，而不是当成可信数据直接喂模型。
最容易被忽略的一点：Google Translate API 的服务条款明确禁止用于构建平行语料库。哪怕技术上跑通了，法律风险也在那儿摆着。
- 改用
