Marcus Wren

I built this tool because most free braille translators online treat English to braille conversion as a simple character swap, and it isn’t one. Contraction rules in Grade 2 depend on position, word boundaries, and context that a naive letter-for-letter substitution gets wrong constantly. Getting that right meant working through the actual UEB rulebook directly, not approximating it from secondhand summaries.

How this tool actually got built

Before writing a line of the contraction engine, I spent time understanding what people actually need from a braille translator: transcribers who need exact output for legal or technical text, parents and teachers introducing spelling instruction, fluent readers who want fast Grade 2 output for personal notes, and people exporting files for physical embossers and note-takers. Those different needs shaped which features shipped, not the other way around.

The Perkins-style keypad exists because dot-by-dot composition is genuinely useful for learning cell structure, not because it looked good on a feature list. The forced Grade 1 fallback inside emails and URLs exists because I traced through what actually breaks when contraction rules apply somewhere they shouldn’t, an email address with an accidental contraction stops being a valid email address. The reverse decode engine’s handling of genuinely ambiguous cells, like the one that means both a comma and the “ea” groupsign depending on position, came from working through what a trained transcriber does by hand and encoding that same positional logic into the decoder.

What I claim, and what I don’t

I’m not a certified UEB transcriber, and I don’t present myself as one.

What I can stand behind is the engineering: every contraction rule in this tool is checked against BANA’s published UEB rulebook, and the translation engine runs against a regression suite built specifically to catch the cases that break simpler translators, morpheme boundary exceptions like “rawhide” not contracting despite containing “wh”, digit and letter disambiguation, email and URL handling, and ambiguous reverse-decode cells. That test suite is what keeps changes to the engine from silently breaking output that used to be correct.

I’ve also written up the mechanics behind these decisions in more depth, including a walkthrough of the tool itself, on YouTube, and shorter breakdowns of individual features on X and Medium, if you want to see the reasoning behind a specific decision rather than just the end result.

Corrections and updates

If you find an output that looks wrong, I want to know. Contact details are on the contact page, and confirmed issues get fixed and added to the regression suite so the same mistake can’t reappear silently in a future update.