让 100 篇 PDF 排队自动翻译用 PDFMathTranslate 搭一个批量翻译 API 的实战笔记【免费下载链接】PDFMathTranslate[EMNLP 2025 Demo] PDF scientific paper translation with preserved formats - 基于 AI 完整保留排版的 PDF 文档全文双语翻译支持 Google/DeepL/Ollama/OpenAI 等服务提供 CLI/GUI/MCP/Docker/Zotero项目地址: https://gitcode.com/GitHub_Trending/pd/PDFMathTranslate做文献综述、翻译技术文档时最消耗人的往往不是翻译本身而是重复劳动打开一个文件、点一下翻译、等进度条、保存、再打开下一个。文件一多几十上百个纯手工操作就熬不住了。PDFMathTranslate 的价值正在于此——它把保留排版地翻译 PDF做成了一个可被程序调用的模块你可以在自己的脚本里循环调用它也可以把它包装成一个 HTTP 翻译 API让任何语言、任何客户端批量提交任务。这篇文章就带你从零到一把这条批量翻译链路跑通。先看清楚它在做什么PDFMathTranslate 是一个基于 AI 的 PDF 全文翻译工具EMNLP 2025 Demo核心能力是边翻译边重建排版正文段落被翻译成目标语言后放回原页面的原始位置公式、图表、表格基本不被破坏。翻译引擎可切换为 Google、DeepL、Ollama、OpenAI 等输出有单语版纯译文和双语版上下对照两份 PDF。下面这张图是它处理一份论文后的效果注意公式和版面结构都被保留了对开发者来说关键事实是它既可以import进你的 Python 进程用也可以起一个独立服务通过网络调用两条路都只依赖同一个底层翻译内核pdf2zh/high_level.py。环境准备最短可跑通步骤整个安装可以压缩成三步目标是先能跑再谈扩展确认 Python 版本。项目要求3.11 版本 3.13先检查python3 --version。拿到代码并安装。git clone https://gitcode.com/GitHub_Trending/pd/PDFMathTranslate cd PDFMathTranslate pip install .如果要用 HTTP 服务加装后端依赖并准备 Redis。Flask Celery 服务以 Redis 作为消息队列和结果存储默认连redis://127.0.0.1:6379/0见 pdf2zh/backend.py所以 Redis 不是可选项pip install pdf2zh[backend] # 用你的发行版包管理器装好 redis-server 并启动它 # 或者临时用 Docker 跑一个docker run -d -p 6379:6379 redis:7装完可以用一条命令验证 CLI 可用pdf2zh --help。两条接入路径怎么选进程内调用 vs 网络服务拿到模块后真正要做的第一个决策是在哪个层面接入它两条路径对比如下维度路径 APython 进程内调用路径 BHTTP 服务接入方式from pdf2zh import translatecurl/ 任意 HTTP 客户端适用场景你自己写的 Python 脚本、批处理作业、定时任务多语言客户端、Web 应用、团队共享一个翻译后端部署成本零额外进程需常驻 Redis Flask Celery worker任务管理自己写循环天然带任务 ID、进度查询、中途取消隔离性翻译和宿主机程序共享进程资源翻译在 worker 里跑宿主机只传 JSON一句话决策调用方是 Python 且就这一台机器 → 选 A调用方不止一个、或者不想把翻译引擎焊死在业务进程里 → 选 B。B 的代价是多出 Redis 这一套依赖换来的是跨语言、可取消、可查进度的标准任务模型。两条路径的详细契约见 接口文档。端到端跑通一条命令提交三步拿到结果下面选路径 B 走一条完整链路Flask 默认监听 11008 端口。先起两个进程pdf2zh --flask # 起 HTTP 服务监听 11008 pdf2zh --celery worker # 起异步任务执行器第一步提交任务。文件走 multipart翻译参数走data字段JSON 字符串curl http://localhost:11008/v1/translate \ -F filepaper.pdf \ -F data{\lang_in\:\en\,\lang_out\:\zh\,\service\:\google\,\thread\:4}响应只有一样东西——任务 ID拿到它后续全靠它{id:d9894125-2f4e-45ea-9d93-1a9068d2045a}第二步轮询进度。对同一个 ID 发 GET未完成时会带n/total页数进度curl http://localhost:11008/v1/translate/d9894125-2f4e-45ea-9d93-1a9068d2045a # 进行中: {state:PROGRESS,info:{n:13,total:506}} # 完成后: {state:SUCCESS}第三步取结果。mono取纯译文dual取双语对照都是直接回 PDF 二进制curl http://localhost:11008/v1/translate/d9894125-2f4e-45ea-9d93-1a9068d2045a/mono -o out-mono.pdf curl http://localhost:11008/v1/translate/d9894125-2f4e-45ea-9d93-1a9068d2045a/dual -o out-dual.pdf批量场景下你的批量 API本质上就是循环发 N 个第一步 → 并发轮询各自的 ID → 状态变SUCCESS后拉文件。如果某个任务跑歪了用 DELETE 终止并清理curl -X DELETE http://localhost:11008/v1/translate/id而如果你走路径 A同样的参数在进程内两行就能表达from pdf2zh import translate params dict(lang_inen, lang_outzh, servicegoogle, thread4) mono, dual translate(files[paper.pdf], **params)[0] # 返回两个输出文件路径translate_stream(streambytes, **params)则接收内存中的 PDF 字节流返回译好的单语/双语两份内容——HTTP 服务端内部其实就是调它pdf2zh/backend.py 里的translate_task。避坑与调优几个会卡住你的点两条路径都强依赖 Redis。官方接口文档明确写着All methods need the Redis。很多人只装了 Flask 依赖却没起 Redisworker 一提交任务就报错先确认redis-cli ping有回音。结果没好就下载会拿到 400。任务状态不是SUCCESS时请求/mono、/dual会返回{error: task not finished}轮询逻辑里必须把状态判断放在下载之前。thread是并行度旋钮不是越大越好。它控制内部并发请求翻译服务的线程数调太高容易触发服务商限流表现为重试变多、速度不升反降4 是个稳的起点遇到限流往下调。service决定成本与质量。Google、DeepL、OpenAI、Ollama本地模型各有取舍参数里只传名称密钥走环境变量配置不要在data字段里明文拼密钥。重复翻译会被缓存。相同片段的译文有缓存机制pdf2zh/cache.py批量重跑同一批文件时耗时会明显缩短反过来排查结果没更新时也先想到它。批量吞吐瓶颈在 worker 数量。单 worker 同一时刻只跑一个任务想提高批量吞吐就横向起多个pdf2zh --celery worker进程它们共享同一个 Redis 队列。谁适合用谁该绕道适合科研文献批量转译、技术文档多语言分发、教材/论文双语对照整理——凡是文件多、要求版面别散架的场景都契合尤其是英文论文转中文这类主力用途。不适合扫描件为主无文本层的 PDF它靠解析文本流工作效果远不如原生 PDF对版面有像素级还原要求的商业级排版输出以及只翻译其中一段的需求——它的工作单位是整份文档虽然可以按页选择。收尾把批量翻译做成 API核心动作其实就三个选对接入路径进程内 or HTTP、把提交—轮询—下载这条状态链路写进代码、然后围绕线程数与 worker 数做调优。项目细节与接口契约以官方文档为准APIS.md、ADVANCED.md。跑通第一篇之后剩下的就是把for循环写满一百个文件而已。【免费下载链接】PDFMathTranslate[EMNLP 2025 Demo] PDF scientific paper translation with preserved formats - 基于 AI 完整保留排版的 PDF 文档全文双语翻译支持 Google/DeepL/Ollama/OpenAI 等服务提供 CLI/GUI/MCP/Docker/Zotero项目地址: https://gitcode.com/GitHub_Trending/pd/PDFMathTranslate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考