PDF translator bot: automating a 100-page research bottleneck

While working as a research analyst at GreyB, I kept running into the same problem: potentially relevant patents were sometimes published only in a foreign language, with no usable translated family publication available.

A researcher could find the right document, but understanding it could mean manually translating dozens, sometimes hundreds, of pages. For a short document that was inconvenient. For a 100-page patent it was a workflow problem: the team was spending time on repetitive mechanical work.

Nobody asked me to build a translation tool. I started by watching how the team already worked. Once I mapped the process, it was clear most of it was repetitive and predictable, which meant it could be broken into smaller steps and automated.

The goal wasn't to replace the researcher. It was to remove the mechanical work so they could spend more time on the part that actually needs judgment: analysis.

I designed it as a pipeline rather than one large script. The input is a foreign-language patent PDF; the output is an editable translated document plus a translated-page PDF, with no one repeating the same operation page after page.

A 100-page PDF isn't a convenient unit for automation, so I used Python-based PDF processing to convert the document into individual page images. That gave the automation a predictable unit of work, one page per processing cycle, and made the rest of the workflow much easier to control.

The next challenge was interacting with the translation interface over and over. I used Playwright to automate the browser, so instead of someone doing each page by hand a hundred times, the browser handled the repetitive interaction.

This was the point where the project stopped being a utility script and became a workflow.

I deliberately didn't treat the result as just plain text. Each page produced two useful outputs, so the final package kept both readability and visual context.

An automation isn't finished when the script finishes; the output still has to be useful. So I added automatic document compilation: translated text from each page is assembled into one structured document, and the translated page images are compiled into a separate PDF.

The researcher gets a complete output package instead of hundreds of disconnected files.

Building the first version exposed more problems, and that's where the interesting engineering started.

I added automated workspace management so every run starts clean and temporary processing data is removed afterwards, which made repeated runs much easier to manage.

Later iterations focused on making the generated document easier to review and share, rather than simply dumping translated text into a file.

The interesting part wasn't the translation itself. It was recognising that the real bottleneck was human time spent on repetitive steps, and turning that workflow into a pipeline.

The tool was well received by the research team and became part of GreyB's internal workflow. Colleagues used it for real research work, and it was documented internally as an example of solving a repetitive research problem through automation. It later kept evolving toward more polished, client-shareable output.

The strongest signal wasn't that the script worked once. It was that it was useful enough to become part of the organisation's process.

I identified the bottleneck during my day-to-day research work, then designed and built the automation around it.

This project changed how I approach software. I stopped thinking only "what can I build?" and started asking "what repetitive problem is wasting someone's time, and how can I turn that process into a system?" That mindset has stayed with me ever since.