How to Translate a Scientific PDF With Equations

If you need a paper in another language and it contains real mathematics, the rule is simple: the math must never reach the translator. Equations should be lifted out, carried through untouched, and put back exactly where they were. Everything else — the abstract, the prose, the captions, the table headers — gets translated around them.

Most tools do the opposite. They flatten the PDF to a text stream, hand the whole stream to a translation model, and hope. That is why the formulas are the first thing you notice is wrong.

Why equations break before a single word is translated

A PDF does not store an equation. It stores glyphs at coordinates.

When a typesetter renders a displayed formula, the output is a sequence of individually positioned characters drawn from math fonts, plus vector strokes for things like fraction bars and radical extensions. Sometimes the whole equation is an embedded image. In none of those cases is there a structure that says "this is an integral over t from zero to infinity". There is only ink in the right places.

So a text extractor has nothing good to do with it. It emits the glyphs in whatever order it finds them, drops the vector rules entirely, loses the vertical relationships that made a subscript a subscript, and produces a string that looks like a keyboard fell down the stairs.

This is not a theory. Here is the actual output of a standard text extractor (pypdf) run over page 1 of a real two-column USGS fact sheet:

S
ince the early 1990's, the
magnitude and location of an
Not long ago, the fi rst thing that most
people did after feeling an earthquake was to

Three separate failures in five lines. The dropcap S has been severed from ince. Two different columns have been interleaved mid-sentence. The fi ligature has been split into fi with a space in it.

That is ordinary body text — the easy case. If the reading order is already wrong here, whatever the extractor did to your Navier-Stokes equation two paragraphs down is worse. And note the timing: the text was already scrambled before translation started. The model then translates the scrambled version faithfully, which is the failure mode nobody catches, because the output reads fluently.

The worse failure: a model that rewrites your formula

Dropping an equation is bad. Rewriting it is much worse.

If you hand a large language model a line of mangled math and ask it to translate, it will often produce something. It may normalize a variable name, "fix" what looks like a typo, swap a Greek letter for the one it expected, drop a hat or a prime, or reorder terms into a more familiar-looking arrangement. The result is a formula that is plausible and wrong.

A missing equation is a hole you will notice on the first read. A silently edited equation is a landmine — it looks typeset, it looks confident, and it will survive right up until someone tries to reproduce your numbers.

This is the core reason a translation engine, however good, should never be shown a formula in the first place.

What a correct pipeline does instead

Layout-preserving translation treats a page as structure, not as a string. Concretely:

1. Parse the page into an intermediate representation that separates the visual layout (blocks, columns, figures, tables, reading order) from the text runs inside it.
2. Mask the math. Formulas, inline symbols, sub/superscripts and units are replaced with placeholders before anything is sent to a translator. The engine sees a sentence with a token in it, not the equation.
3. Translate only the prose, block by block, with reading order taken from the layout — not from the byte order of the content stream.
4. Re-anchor the translation onto the original layout, restore the masked math verbatim in its original position, and rescale each paragraph to fit its box, because the translated text is almost never the same length as the source.

The output is a PDF that mirrors the source page for page: same columns, same table cells, same figure placement, same equations — because the equations were never touched.

Translating a paper, step by step

PDFPal is built on that pipeline. The practical run-through:

1. Check that your PDF has a text layer. Open it and try to select a sentence with your cursor. If nothing highlights, it is a scan — see the section below before going further.
2. Upload the PDF. Up to 100 MB. Source language can be auto-detected; pick your target from 40+ languages.
3. Pick an engine for this document. Google is free, fast and deterministic — good for a first pass or for skimming a paper you are triaging. A free pooled Qwen model is also available. For a document you intend to actually rely on, premium LLM engines (OpenAI, Claude) are generally the better choice for technical register and long, clause-heavy sentences; they require a paid plan and cost 2 credits per page instead of 1.
4. Add a glossary if you have one. You can import a two-column CSV of source and target terms so your field's vocabulary stays consistent across the whole document instead of drifting between sections. This is available on every plan.
5. Translate, then open the side-by-side preview. Every job produces both a translated-only PDF and a bilingual side-by-side PDF — you do not have to choose up front.

Signing up gives you 20 free pages with no credit card, which is enough to run a full paper through and judge the output yourself. Free-plan output carries a small "Translated with PDFPal.ai" line; paid output has none. Details are on pricing, and there are before/after samples from six real public-domain documents at examples.

If a job fails, the credits are refunded automatically and you can retry — optionally on a different engine.

Verify it yourself. Every time.

Machine translation of a technical document is a draft, not a result. The bilingual side-by-side output exists precisely so this check takes minutes instead of an afternoon: original left, translation right, same page, same position. Walk down the page and compare.

The checklist:

• Every displayed equation. Compare glyph by glyph against the source page. Variables, operators, limits of integration, summation indices.
• Inline math and symbols in running prose. These are the ones that get absorbed into a sentence and quietly reworded.
• Sub- and superscripts. Confirm they are still raised and lowered correctly, not flattened onto the baseline.
• Units and numbers. Check that no decimal separator, exponent, or unit symbol changed.
• Figure and table captions, plus their numbering. Captions are prose and do get translated — the numbers in them must not move.
• Cross-references. "as shown in Equation 4" must still point at Equation 4.
• The reference list. Bibliography entries are titles and proper names. They should come through essentially untouched, not translated into your target language.

If something is off in one section, retrying on a different engine is often faster than fixing it by hand.

One honest limitation: there is no OCR

PDFPal has no text recognition. If your PDF is a scan — a photographed page, an old journal article, an image-only export — there is no text layer, so there is nothing to translate. The job will fail and refund your credits rather than produce nonsense.

The fix is to OCR it first with a dedicated tool, then upload the OCR'd PDF here. (The "scanned-PDF mode" toggle in the app only improves rendering on image-heavy pages — clean black text on white. It does not perform recognition.)

For everything else — arXiv preprints, standards documents, engineering reports, theses — the math comes through because it was never sent to a translator in the first place.