{"slug": "building-a-braille-translator-in-the-browser-when-unicode-bit-manipulation-meets", "title": "Building a Braille Translator in the Browser: When Unicode Bit Manipulation Meets AI Pair Programming", "summary": "A developer built a Braille translator that runs entirely in the browser, using Unicode bit manipulation to map characters to Braille cells. The tool handles the complexity of number signs and includes a visualization of dot patterns, with the developer noting that AI pair programming assisted in the process.", "body_md": "While working on a collection of browser-based utility tools, I stumbled upon an interesting challenge: building a Braille translator. Not because I have any personal connection to Braille — I'm just a developer who loves Unicode puzzles. But the problem turned out to be more fascinating than I expected, with a hidden layer of complexity that made me rethink how I approach character encoding.\n\nI was building a suite of small, focused web tools. You know the type — URL encoders, JSON formatters, maybe a base64 decoder. Useful, boring, done a thousand times. But Braille? That's different.\n\nHere's the thing: most \"Braille translators\" online are either:\n\nI wanted something that runs entirely in the browser, works offline, and doesn't send sensitive text to a server. Because apparently, I enjoy reinventing wheels.\n\nHere's what blew my mind: Braille isn't some mystical code. It's literally binary.\n\nA Braille cell has 6 dots, arranged in 2 columns and 3 rows. Each dot is either raised or flat. That's 2^6 = 64 possible combinations. And in Unicode, those 64 combinations map directly to code points U+2800 through U+283F.\n\nThe mapping is beautifully simple:\n\n``` js\n// Dot 1 is bit 0, dot 2 is bit 1, dot 3 is bit 2, etc.\nconst brailleCodePoint = 0x2800 + dotPatternNumber;\n```\n\nSo if you know the dot pattern for a letter, you just add the corresponding number to 0x2800. The letter 'a' is dot 1, so it's 0x2800 + 1 = 0x2801, which is ⠁. The letter 'b' is dots 1 and 2, so it's 0x2800 + 3 = 0x2803, which is ⠃.\n\nWait, did I just say \"the letter 'a' is dot 1\"? Because that's where the fun begins.\n\nHere's where my initial assumptions fell apart. I thought I'd just create a simple dictionary mapping letters to their Unicode Braille characters. Then I discovered the actual Braille alphabet pattern:\n\nThe first 10 letters (a-j) follow a pattern, then k-t add dot 3 to the first 10, and u-z follow another pattern. It's almost systematic, but not quite. There's a method to the madness, but you can't derive it from a simple formula — you need the actual mapping.\n\nI initially tried to write a clever algorithmic solution. That lasted about 15 minutes before I gave up and hardcoded the mapping. Sometimes the simple solution is the right one.\n\nJust when I thought I had it figured out, I hit the numbers issue.\n\nIn Braille, the letters a-j double as numbers 1-0. But you can't just type \"123\" and get Braille numbers — you need a special number sign (⠼) before them. So \"123\" becomes \"⠼⠁⠃⠉\", not just \"⠁⠃⠉\".\n\nThis creates an interesting ambiguity: if you see \"⠁⠃⠉\" without the number sign, is it \"abc\" or \"123\"? The answer is context-dependent, which makes bidirectional translation genuinely tricky.\n\nMy solution: when translating text to Braille, detect digits and prepend the number sign once for a run of consecutive digits. When translating Braille to text, if the number sign appears, treat the next characters as digits until you hit a space or non-letter character.\n\n``` js\nfunction textToBraille(text) {\n let result = '';\n let inNumber = false;\n\n for (const char of text.toLowerCase()) {\n if (char >= '0' && char <= '9') {\n if (!inNumber) {\n result += BRAILLE_NUMBER_SIGN;\n inNumber = true;\n }\n result += BRAILLE_MAP[char];\n } else {\n inNumber = false;\n result += BRAILLE_MAP[char] || char;\n }\n }\n return result;\n}\n```\n\nThis was one of those moments where I realized: \"I'm not just building a translator, I'm building a state machine.\"\n\nNow for the part that made this tool actually useful: showing the dot patterns. Because if you're learning Braille, just seeing \"⠓\" doesn't help — you need to know that's dots 1, 2, and 5.\n\nThe visualization is straightforward once you have the dot pattern number:\n\n``` js\nfunction getDots(codePoint) {\n const value = codePoint - 0x2800;\n const dots = [];\n for (let i = 1; i <= 6; i++) {\n if (value & (1 << (i - 1))) {\n dots.push(i);\n }\n }\n return dots;\n}\n```\n\nBit manipulation. Again. It's like binary is following me around.\n\nNow for the part I'm most honest about: I used AI to build much of this. And it was a mixed experience.\n\nThe first prompt I gave was something like: \"Create a Braille translator with text to Braille and Braille to text conversion, with a reference chart.\"\n\nThe AI nailed the basic structure in one shot. It created the HTML layout, the CSS styling, the i18n system — all the scaffolding. I was impressed.\n\nBut then came the bugs.\n\nThe AI initially made the translation case-sensitive. \"HELLO\" would produce different results than \"hello\". In Braille, there's no such thing as lowercase — it's all one case. The AI hadn't thought about normalizing input to lowercase before mapping.\n\nThe AI's first attempt at numbers was a disaster. It would put a number sign before every single digit, so \"123\" became \"⠼⠁⠼⠃⠼⠉\" instead of \"⠼⠁⠃⠉\". That's like writing \"one hundred twenty three\" as \"one-one-hundred-twenty-three\". Technically understandable, but completely wrong.\n\nThe biggest issue was reverse translation. The AI had a static map for text-to-Braille but didn't properly handle the reverse lookup. When I asked it to translate Braille back to text, it would get stuck on ambiguous characters. Is \"⠁\" an \"a\" or a \"1\"? Without context, you can't tell.\n\nThe AI's solution was to always treat it as a letter unless the number sign appeared. That's actually correct, but the AI couldn't articulate why it made that choice — it just happened to be right.\n\nThe AI was great at generating boilerplate and basic logic, but it kept making the same class of mistakes: not understanding the domain. It didn't know that Braille is case-insensitive, that numbers need special handling, or that the dot pattern visualization would be the most useful feature for learners.\n\nI had to:\n\nThe lesson? AI is great for generating code, but it's terrible at understanding domain-specific rules it wasn't explicitly trained on. Braille is a niche topic, and the AI's training data apparently had conflicting information about it.\n\nBuilding bilingual support (Chinese/English) added another layer of complexity. The tool needed to work for both Chinese and English speakers, which meant:\n\nThe i18n system itself was straightforward:\n\n``` js\nconst i18n = {\n zh: {\n title: '盲文翻译器',\n textInput: '文本输入',\n brailleOutput: '盲文输出',\n // ...\n },\n en: {\n title: 'Braille Translator',\n textInput: 'Text Input',\n brailleOutput: 'Braille Output',\n // ...\n }\n};\n```\n\nThe tricky part was making the AI understand that the default language should be Chinese, not English. It kept defaulting to English and I had to keep reminding it. Classic \"works on my machine\" situation.\n\nFor a tool like this, performance is almost a non-issue. The entire translation is O(n) — you're just iterating over characters and doing a lookup. Even a 10,000-character document would translate in milliseconds.\n\nBut there was one performance consideration: the reference chart. Rendering 26 letters + 10 digits + punctuation as individual DOM elements adds up. I used a simple CSS grid with `auto-fill`\n\ncolumns, which handles responsiveness gracefully without JavaScript. No virtual scrolling needed for 60 items, but it's worth thinking about if you ever scale this to include contractions (the full Braille system has hundreds of contractions).\n\nI chose vanilla JavaScript over React or Vue for a few reasons:\n\nThe trade-off? I had to write more boilerplate for things like state management and event handling. But for a tool this small, it's the right call. A React app with a build step would be overkill for what's essentially a `