Translating PDFs is easy. Keeping them readable is the hard part
Over the past year, I've been building a PDF translation tool and talking with users who regularly translate papers, manuals, and scanned documents.
One thing surprised me:
Translation quality was rarely the biggest complaint.
Most frustrations came after the translation was finished.
For example:
- Two-column academic papers often lose their reading order.
- Tables become misaligned or unreadable.
- Scanned PDFs need OCR before translation can even begin.
- Users still need to fix terminology, labels, numbers, or awkward paragraphs before the document is actually usable.
The more feedback I received, the more it felt like a document reconstruction problem rather than a translation problem.
That observation led me to build a PDF translator that focuses less on raw translation quality and more on making translated documents usable.
The main areas I've been working on are:
- Preserving layout as much as possible
- OCR for scanned PDFs
- Paragraph-level editing before export
The editing feature turned out to be much more important than I originally expected.
Many translation tools stop at "translation complete." In practice, people often want one more step: reviewing and correcting the translated content before generating the final document.
Right now, the product seems most useful for:
- Academic papers, especially two-column PDFs
- Scanned documents that cannot be copied as text
- Manuals and technical documents with structured layouts and tables
Some early signals so far:
- Core landing pages have started getting indexed by Google
- We're seeing users upload real papers and documents instead of test files
- Some users are paying to export the final translated PDFs
I'm still very much in the validation stage and trying to understand where the strongest demand exists.
I'd love to hear from people who regularly work with PDFs:
- What type of PDF tends to break most often after translation?
- Which matters most to you: layout preservation, terminology editing, OCR, speed, or pricing?
- If you only translate PDFs occasionally, would you prefer pay-per-download over a subscription?
If there's interest, I'm happy to share screenshots of:
- Two-column paper translation
- OCR results for scanned PDFs
- The paragraph editing workflow after translation
I like the way you framed this as a document usability problem, not just a translation problem.
We see a similar issue from the WordPress side. A PDF may already contain useful content, or even be OCR-processed, but if visitors cannot search and find that content on the website, it still feels hidden.
That’s one of the reasons we built Webequipe PDF Search for WordPress. The goal is not only to handle PDFs, but to make important document content easier to discover and actually use.
That's an interesting perspective.
We usually think of PDFs as a way to package and share information, but not as something people actively discover through search.
What's interesting is that our products start from the same foundation—extracting content from PDFs—but head in different directions afterward. Your goal is to make that content discoverable, while ours is to make it usable across languages without losing the document itself.
It's fascinating how the same underlying problem can lead to such different products.
I like the shift from thinking about this as a translation problem to a document usability problem.
That's a subtle but important difference. People rarely care that a PDF was translated—they care that it's immediately usable without spending another hour fixing what the translation broke.
Exactly — that's the shift that changed how I think about the product.
Early on I was optimizing for translation quality. But in user conversations, the pain almost always showed up after the translation finished: broken reading order in two-column papers, tables that no longer line up, labels and numbers that need manual fixes.
At that point people aren't asking "was this translated well?" — they're asking "can I actually use this document now?" With LLMs today, raw translation quality is often good enough; the bottleneck has moved downstream.
That's why I ended up focusing on layout preservation, OCR for scanned files, and a paragraph-level editing step before export. The editing part surprised me most — many users want to review and fix things before generating the final PDF, not just download a raw translation.
Interesting.
Reading your reply made me think less about translation quality and more about what changes once usability becomes the product's primary promise instead.
I don't think I can explain that line of reasoning properly in a thread without oversimplifying it.
If you're open to it, what's the best email to reach you on?
Sure, I'd be happy to chat more about it.
My email is zoe2727@gmail.com.
Looking forward to hearing your perspective.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.