Decide who will own the integration
BabelDOC targets developers who need scientific PDF translation and bilingual output inside another program. Its README describes parsing a PDF into an intermediate representation and rendering that structure into a new document. Preserving a paper's layout is the intended use, but our recorded run did not measure how faithfully it does so.
The support boundary matters before choosing an integration. The README calls the CLI a debugging interface and says end-user technical support is not provided for it. It also treats every BabelDOC API as internal and unsupported. For Python integration, it recommends calling high_level.do_translate_async_stream through pdf2zh-next rather than directly depending on BabelDOC APIs.
For self-deployment, the README points to PDFMathTranslate-next. That project describes itself as the official reference implementation for calling BabelDOC and provides an interactive interface, command line and Docker. Its own documentation declines usage assistance, so this recommendation should not be read as a promise of support.
What our recorded run establishes
Our stored run is dated 28 September 2026 at 02:51:46.640 UTC and identifies commit 38d3896dcde9b5a940c62cf5563cadea673a64d3. No new execution was performed for this review.
| Recorded step | Result | Limit |
|---|---|---|
| Install | Exit 0 in 34.686 seconds, rounded to 35 seconds; dependency summary of 106 packages and 744 MB | Does not establish a checked installed CLI or completed translation |
| Build | Exit 0 in 5.141 seconds, rounded to 5 seconds | Does not measure PDF output quality |
| Pytest | Exit 5 in 4.187 seconds, rounded to 4 seconds; parser summary of 0 passed, 0 failed and 0 total | No passing suite or failed assertion is established; exhaustive coverage was not verified |
| Pip-audit | Recorded advisory total of 0 | Coverage is unknown; this is not proof of dependency safety |
The retained install output identifies Python 3.12.12. The sandbox configuration records 3 CPUs, 8 GB of memory and image ghcr.io/astral-sh/uv:python3.12-bookworm. The repository summary records 410 files, approximately 77,258 lines of source, 19.9 MB and 7 CI workflow files. Detection found no Dockerfile, Compose file or tests directory; those detection results do not prove the repository contains no tests elsewhere.
Pytest warned that no files were found in testpaths and that it would search recursively. The retained record is a parser summary and output tail, without complete-log reconciliation. Treat it as an inconclusive test run. It does not show that BabelDOC is broken.
Translation needs a separate trial
The README documents an OpenAI-compatible endpoint, model name, API key and PDF paths. It recommends uv with Python 3.12 and supports local endpoints using the same API shape. Its --warmup option downloads and verifies required assets, while offline asset packaging covers document-processing models and fonts. Offline assets do not remove the need for a reachable translation endpoint.
English and Chinese are the default source and target languages. The README says the project mainly focuses on English-to-Chinese translation and that other scenarios have not been tested. This is the project's stated scope, not a language-quality result from our sandbox.
The documentation includes experimental table-text translation, formula-font controls and OCR workarounds. Those options are reasons to trial representative documents rather than assume that a successful build validates every PDF.
Separate document failures from model failures
Issue 613 reports ordinary New Computer Modern text fonts being classified as formulas, leaving body text unavailable to the translation model. The reporter checked v0.6.4 and the then-current main branch. An October 12, 2026 commenter reported improvement after narrowing the font patterns in a proposed fix. These are upstream reports, not our reproduction or proof that a fix reached a release.
Issue 609 initially reported untranslated content at the same full commit used in our sandbox. The reporter later said their model API sometimes returned Content of None and that adding exception handling and retries eliminated the incomplete translation. It should not be presented as an independently established extraction defect.
For an evaluation, choose PDFs with your actual fonts, scripts, equations and page structures. Check whether text reaches the model, whether the response is usable and whether the saved pages remain readable. Compare source and output pages, inspect retained source-language passages and verify navigation where your workflow requires it. These are recommended checks; we did not perform them in the recorded run.
Choose the application layer deliberately
PDFMathTranslate-next is the relevant self-deployment option when you want an interface around BabelDOC. Immersive Translate is relevant when the goal is bilingual reading through an extension rather than embedding a Python engine. Its primary repository states that the product is not open source and that the repository contains releases and feedback rather than its source code.
For a developer evaluation, pin the BabelDOC revision and model configuration, then translate representative documents before committing to the integration. Our install and build results support trying that next step; they do not establish production readiness.
How the scores work
These are editorial evidence ratings, not benchmark results. On this five-point rubric, 1 means the supplied evidence leaves major requirements unresolved; 2 means a documented route exists with substantial limits; 3 means a usable evaluation route is supported with important checks remaining; 4 means detailed evidence supports the category within its stated scope; and 5 requires broad verification beyond this record. Unknown adoption, compatibility and translation quality earn no extra credit. Community measures the documented contribution and feedback route, not popularity.