Series: Building PdfWord — a free, no-backend PDF tools site (Part 12)
I'm building in Pakistan. My users type business names in Urdu, price things in rupees, and read right-to-left half the day. So early on, I went down the localization rabbit hole — and the most valuable lesson wasn't what to build. It was what not to build.
Try it: PdfWord
What my users actually needed (it wasn't a translated UI)
I started by asking the wrong question: "how do I translate the interface?" The right question turned out to be: "what breaks for a Pakistani user that doesn't break for anyone else?" Three things:
- Currency. An invoice generator that only speaks USD is useless to a shop owner in Sargodha. Ours does PKR, USD, EUR and more, with configurable tax percentages — because "16% tax" is a sentence my users actually say.
- Unicode-safe inputs. Form fields are just HTML inputs, so the browser handles Urdu text natively. The lesson was on the output side (more below): never silently mangle someone's name.
- Trust signals in the right units. A shop owner seeing "Rs 8,020" instead of "$8,020" instantly knows the tool was made for them. Tiny detail, enormous trust.
The font wall
Here's where it gets technical. PDF generation with pdf-lib uses standard fonts (Helvetica and friends), which speak WinAnsi encoding — Latin only. I learned this the embarrassing way with the invoice generator: the pretty minus sign − (U+2212) isn't in WinAnsi and chokes the standard fonts, while the em-dash — (U+2014) is fine. If a single Unicode minus breaks things, imagine an entire Urdu sentence.
The proper fix — embedding a full Unicode font like Noto Nastaliq Urdu in every generated PDF — adds hundreds of KB per file plus subsetting complexity. The pragmatic call: keep generated PDFs Latin-safe, validate inputs honestly, and never silently corrupt a name into boxes or question marks. A tool that tells you "this character can't render" beats one that quietly destroys your data.
The Urdu toggle I built — and then removed
Yes, I built a full Urdu UI toggle. RTL layout, translated strings, the works. And then I removed it.
Why: every new feature meant double the strings and double the QA, forever — and the audience searching for and using PDF tools operates in English anyway. The site is English-only by deliberate design. The toggle was localization theater: it looked inclusive while the things users actually needed (PKR support, Unicode-safe inputs, honest font handling) were somewhere else entirely.
The lesson I keep coming back to: localize the workflow, not the chrome. Translating buttons is easy and mostly pointless. Making the tax math, the currency, and the text handling correct for your users' reality — that's localization that matters.
What I'd tell anyone localizing a tool
- Talk to five real users before translating a single string. Their actual pain is never where you expect.
- Currency and number formatting beat translated UI text, every time.
- If your output format (PDF, in my case) can't render a script, say so loudly — silent corruption is the unforgivable sin.
- It's okay to remove a feature. The toggle's deletion was one of my better product decisions.
Try it: PdfWord — generate an invoice in PKR and see what "made for here" feels like.
What's a localization feature you built that nobody used — and one tiny one your users loved? I have a feeling everyone's got a story like my Urdu toggle.
Top comments (0)