Forem: pBinder

I built a local-first Chrome extension for translating selected text and saving vocabulary

pBinder — Wed, 29 Apr 2026 14:09:21 +0000

I recently built Vocabinet, a Chrome extension for people who read foreign-language content online and want a faster way to translate words or phrases without leaving the page.

The idea came from a small frustration: when I’m reading an article, blog post, or documentation in another language, the lookup flow is usually too disruptive. I either open a new tab, paste text into a translator, or translate the page and lose the original reading context.

I wanted a lighter workflow:

highlight text on a webpage
translate the selected word or phrase
optionally save it to a vocabulary list
search saved vocabulary later
export the list as CSV

What it does

Vocabinet lets you translate selected text directly on the page using Chrome’s built-in Translator API.

The current workflow includes:

selected-text translation
keyboard shortcut support
optional double-click quick translate
local vocabulary saving
search and delete for saved items
CSV export
text-to-speech for source text

The core workflow does not require an account.

Why Chrome’s built-in Translator API?

I wanted the extension to be local-first where possible and avoid building the first version around a paid translation API.

Chrome’s built-in Translator API makes that possible, although it also comes with some constraints:

users need a supported desktop Chrome version
some language pairs depend on Chrome’s local support
a language pack may need to download on first use
it does not work on Chrome internal pages like chrome://

That tradeoff felt worthwhile for a tool focused on quick reading assistance and personal vocabulary capture.

Why include vocabulary saving?

Translation alone is useful, but it often becomes a dead end. You look up a word, understand the sentence, and then forget the word later.

So I added a simple local vocabulary list. When a translation is useful, you can save it and come back to it later. For now, export is CSV because it is simple and portable.

I’m considering whether direct Anki export should be added next.

A few things I learned while building it

Building a Chrome extension around selected text sounds simple, but there are a lot of small UX details:

selections disappear easily when users click elsewhere
double-click lookup can be helpful, but it can also become annoying if it appears too aggressively
translation errors need to be clear because language availability depends on the browser/device
keyboard shortcuts are faster for power users, but many users still expect a visible popup flow
permission scope matters a lot for user trust

The extension currently uses limited permissions and keeps the vocabulary list local.

What I’d like feedback on

I’m especially interested in feedback from people who read in other languages online:

Is selected-text translation the right workflow?
Would double-click lookup be useful or distracting?
Is CSV export enough, or would Anki export be expected?
Is local-only storage a benefit, or would sync matter more?
Are there any permission or onboarding concerns?

Chrome Web Store:
https://chromewebstore.google.com/detail/bmchpdngcmmalcpdlingddcmlfcddiia

Thanks for reading. I’d appreciate any feedback from language learners, Chrome extension builders, or anyone who has worked with browser-based translation tools.

One Screenshot Is Sometimes Better Than a Screen Recording

pBinder — Tue, 28 Apr 2026 14:33:34 +0000

I kept running into the same small workflow problem.

Whenever I needed to explain a browser process, report a UI bug, or document a quick internal step-by-step flow, the routine was usually the same: take a screenshot, open an image editor, draw arrows, add step numbers, export the image, and then send it.

None of that is especially difficult, but it adds friction when the goal is just to explain something quickly.

So I built a small Chrome extension called ClickTrek.

ClickTrek records the clicks you make on the current page after starting it, then turns them into a single annotated PNG with numbered markers and arrows.

The Problem I Wanted to Solve

There are already many good tools for documentation, screenshots, and screen recording. Loom, Scribe, Tango, Snagit, CleanShot, and similar tools are useful for full walkthroughs, polished docs, or more detailed editing.

But I wanted something narrower.

Sometimes a video or hosted walkthrough is more than I need. I just want one image that clearly shows:

Click here.
Then click here.
Then click here.

That specific use case is what ClickTrek is focused on.

How It Works

ClickTrek is designed for quick browser workflow documentation.

It currently handles:

recording clicks on the current page
adding numbered step markers
drawing arrows between steps
undoing accidental clicks
showing a preview before export
downloading the final result as a PNG

The output is a single image you can drop into a bug report, GitHub issue, Slack message, internal wiki, tutorial, or handoff note.

Why I Kept It Simple And Local

The first version is intentionally small. I wanted the flow to be easy to understand: open it, start recording, click through the workflow, preview, and export.

There is no account setup, no cloud upload, and no hosted workspace.

ClickTrek runs locally in the browser. It captures the visible page to generate the PNG, and the final export is saved through the browser download flow.

One important note: anything visible on the page can appear in the exported image, so the preview step matters. You should review the image before sharing it.

ClickTrek is not trying to replace full documentation platforms or screen recording tools. It is meant for the smaller moments where a quick annotated image is enough.

Current Limitations And What Might Come Next

The main limitation right now is that ClickTrek only supports single-page workflows.

If you navigate away to another page, the current capture ends. Since many real workflows span multiple pages, this is one of the biggest things I am thinking about for future versions.

Other features I am considering:

multi-page workflow capture
blur or redaction tools for sensitive data
PDF and Markdown export
copy-to-clipboard export
custom marker colors and styles

I am still figuring out which of these would add the most value without making the tool feel heavy.

Try It

ClickTrek is available on the Chrome Web Store:

Get ClickTrek on the Chrome Web Store

I would be interested to hear how people currently document quick browser workflows for bug reports, tutorials, internal docs, or handoff notes.

How to Convert Python Files to PDF or DOCX (Without Installing LaTeX)

pBinder — Mon, 09 Mar 2026 12:21:16 +0000

You have a .py file — or a handful of them — and you need a PDF or Word document. Maybe you're submitting coursework, sharing code with a non-developer, creating a printable archive, or reviewing an open-source repo offline.

There are several ways to do this, each with different trade-offs. Here's an honest breakdown.

Method 1: Pandoc (Free, Open Source)

Pandoc is a mature, widely-used document converter that handles .py to DOCX or PDF well.

pandoc my_script.py -o output.docx
pandoc my_script.py -o output.pdf

DOCX output works cleanly without extra dependencies — a solid choice if you're comfortable with the command line.

PDF output requires a separate PDF engine. By default Pandoc uses LaTeX — on Windows that means installing MiKTeX, on macOS it's MacTeX. Both are large installs (MiKTeX can reach several GB depending on packages). Pandoc also supports lighter alternatives like wkhtmltopdf or weasyprint via the --pdf-engine flag, but those also require separate installation. Once a PDF engine is set up, Pandoc is powerful and fully scriptable — you can batch-process entire directories and customise output with templates.

Best for: Developers comfortable with CLI who want a free, scriptable solution. DOCX output requires minimal setup; PDF requires choosing and installing a PDF engine first.

Method 2: Jupyter nbconvert (For Notebooks)

If you're working with .ipynb notebooks, nbconvert is the right tool. It handles cell outputs, inline plots, and markdown cells cleanly.

jupyter nbconvert --to html notebook.ipynb
jupyter nbconvert --to pdf notebook.ipynb

Native output formats include HTML, PDF, Markdown, and script. DOCX is not a native nbconvert format — converting to DOCX requires Pandoc and python-docx installed separately (available in JupyterLab via File → Export As → Word, if those dependencies are present). PDF output requires a LaTeX distribution.

Best for: Data scientists and notebook users who need HTML or PDF exports. Not applicable to plain .py files.

Method 3: Sphinx + LaTeX (Full Documentation Build)

Sphinx is the standard Python documentation tool. It generates a full docs site from your source code, and make latexpdf exports a PDF.

The setup is substantial — you need Sphinx configured, docstrings in the right format, and a LaTeX install — but the output quality is genuinely excellent: proper cross-references, module indexes, and a professional layout.

Best for: Open-source projects that need real, maintained documentation. Too much overhead for a quick export, but the right long-term investment for serious projects.

Method 4: VS Code Print Extension or Browser Print

Open a file in VS Code with a print extension, or open it on GitHub and use browser print-to-PDF. No installs, no command line, works immediately.

Output quality is limited — margins and page breaks aren't controlled, long lines can get cut off, and there's no table of contents. For a short script it's perfectly fine.

Best for: A quick rough printout of a single file when appearance doesn't matter much.

Method 5: pBinder (Windows, Free Trial Available)

pBinder is a portable Windows EXE built specifically for converting Python files and projects to DOCX and PDF. It requires no LaTeX, no Python environment, and no installation — download and run.

It works for a single file, a handful of files, or an entire project directory. It's also useful beyond your own code: clone a GitHub repo you're studying and convert it to a navigable document to read offline or annotate.

What sets it apart from the other methods is the output structure. Rather than a flat printout, it produces a document you can navigate:

Clickable table of contents with a project folder tree
Symbol directory — every locally defined class, function, and method listed with a hyperlink to the page it's defined on
Call-site cross-references — wherever a local function or class is called in the code, that call site links back to the exact page and line where it's defined. Similar to how you'd navigate in an IDE, but inside a DOCX or PDF

The main limitations: Windows only (Windows 10 64-bit), and PDF export requires Microsoft Word. DOCX works without Word.

Best for: Windows users who want navigable, structured output from a Python project without the LaTeX and CLI setup that Pandoc or Sphinx require. A 14-day free trial is available at pbinder.app.

Comparison

Method	DOCX	PDF	Multiple Files	TOC	LaTeX Required	Setup
Pandoc	✅	✅	Manual scripting	❌	PDF engine needed	CLI
nbconvert	❌	✅	❌	❌	For PDF	Jupyter env
Sphinx	❌	✅	✅	✅	✅	Heavy
VS Code / Browser	❌	✅	❌	❌	No	None
pBinder	✅	✅	✅	✅	No	None

Which Should You Use?

One file, no fuss → VS Code or browser print

Notebooks → nbconvert

Scripting and DOCX output → Pandoc (no LaTeX needed for DOCX)

Full project documentation long-term → Sphinx

Navigable DOCX or PDF, no setup, Windows → pBinder

Every tool here has a legitimate use case. The right choice depends on your OS, how much setup you're willing to do, and what you need the output to look like.

Have a method I missed? Drop it in the comments.