DEV Community: Talha Ramzan

Supporting 5 Languages (Including 2 RTL Ones) Almost Broke My Layout System

Talha Ramzan — Thu, 13 Aug 2026 10:08:07 +0000

When I decided to support English, Spanish, Arabic, French, and Urdu on my tools site, I assumed the hard part would be translation. It wasn't. The hard part was that two of those five languages read right-to-left, and "just add dir="rtl"" turned out to be the beginning of the problem, not the end of it.

Here's what actually broke, and what fixed it.

The naive version (day 1)

<html dir={locale === 'ar' || locale === 'ur' ? 'rtl' : 'ltr'}>

This works for text direction. It does not work for anything else. The moment I flipped dir to rtl, every layout built with directional assumptions, icons pointing the wrong way, padding on the wrong side, flexbox items reversing in ways I didn't want, broke simultaneously.

Problem 1: "Left" and "right" in CSS don't mean what you think

Most CSS written without RTL in mind uses physical properties: padding-left, margin-right, text-align: left. These are directionally absolute, they don't care what dir the page is in. So a "back" arrow icon with margin-right: 8px (space before the label, in LTR) ends up with the gap on the wrong side once the page flips, because the icon's logical position reversed but the CSS didn't know to follow.

The fix is switching to logical properties, which are relative to text direction instead of physical screen position:

/* Before: physical, breaks under RTL */
.back-button {
  margin-right: 8px;
  padding-left: 12px;
}

/* After: logical, follows text direction automatically */
.back-button {
  margin-inline-end: 8px;
  padding-inline-start: 12px;
}

margin-inline-end means "the margin at the end of the reading direction", 8px on the right in LTR, 8px on the left in RTL, automatically. No conditional logic, no locale check in the component. The browser handles it based on dir.

Problem 2: Numbers and code snippets should not flip

This is the one that actually surprised me. RTL affects the reading direction of text, but numerals, currency values, and code blocks should stay LTR even inside an RTL page, nobody wants to read 123 as 321 or a JSON snippet mirrored.

<span dir="ltr" className="inline-block">
  {formattedPrice}
</span>

Wrapping numeric/code content in an explicit dir="ltr" override, even inside an RTL parent, keeps it readable. Miss this and a WAPDA bill calculator showing "Rs. 4,500" can visually reorder the digits depending on font and browser, which is a genuinely confusing bug to explain to someone reporting it.

Problem 3: Font rendering isn't uniform across scripts

Arabic and Urdu use different script systems (Urdu is written in a Nastaliq-influenced Arabic script, but the typographic conventions differ enough that a font tuned for Arabic can render Urdu text with incorrect letter joining). Using one font stack for both was a mistake I didn't catch until a native Urdu speaker pointed out that words looked "technically correct but wrong," which is a hard bug to self-diagnose if you don't read the script.

[lang="ar"] {
  font-family: 'Noto Naskh Arabic', sans-serif;
}

[lang="ur"] {
  font-family: 'Noto Nastaliq Urdu', sans-serif;
}

Scoping font-family by the actual lang attribute, not just a shared "RTL font" bucket, fixed rendering quality for both without either language compromising for the other.

Problem 4: hreflang tags are easy to add and easy to add wrong

Each tool page exists in 5 locale variants, and search engines need to know they're the same content in different languages, not 5 separate, duplicate pages. That's what hreflang is for:

const languages: Record<string, string> = {};
for (const loc of LOCALES) {
  languages[loc] = toolUrl(loc, slug);
}
languages['x-default'] = canonicalUrl;

Getting the mapping right matters more than it sounds like it should. Every locale variant needs to list every other locale variant as an alternate, including itself, a page that lists alternates for the other 4 languages but forgets to include a self-referencing hreflang tag is a common mistake that quietly confuses crawlers about which page is canonical.

The gotcha I hit: this metadata structure existed correctly from early on, but the actual visible title and description text didn't get translated, every locale was serving the same English title. Bing's crawler flagged this as "too many pages with identical titles," which is a fair complaint: the hreflang tags said "these are translations of each other," but the content proved otherwise for anyone actually reading the page.

Problem 5: Locale detection vs. locale preference are different problems

Auto-detecting a visitor's language from browser settings (navigator.language or the Accept-Language header) feels like the right default, but it fights with an explicit user choice. If someone's browser is set to Arabic but they click "English" in the site's language switcher, that choice needs to persist, otherwise every page navigation silently reverts them to the auto-detected language, which reads as broken rather than helpful.

function resolveLocale(request) {
  const explicit = getCookie('preferred-locale');
  if (explicit) return explicit;

  return detectFromAcceptLanguage(request.headers) ?? 'en';
}

Explicit preference always wins over detection. Detection is only a first-visit default, never an override.

What I'd tell someone adding RTL support for the first time

Logical CSS properties aren't optional once RTL is in scope. Physical left/right properties will break silently and inconsistently, not obviously.
Numerals and code need explicit direction overrides, even inside RTL content, this is the bug most likely to ship unnoticed because it looks fine to anyone not reading the specific numbers carefully.
Don't assume one font serves multiple scripts well, even ones that look superficially related. Get someone who actually reads the language to review rendering, because typographic correctness isn't something you can proofread visually if you don't read the script.
hreflang tags are a promise your actual content has to keep. Metadata saying "these pages are translations of each other" doesn't make it true, the visible title/description text has to actually be translated for the promise to hold up to a crawler or a user.

The tools are live in all 5 languages if you want to see the RTL layout in action: dukotools.com/ar or dukotools.com/ur.

Happy to go deeper on the logical-properties migration in the comments if anyone's dealing with a large existing LTR-only codebase and dreading the RTL retrofit.

What Nobody Tells You About Building "Simple" PDF Tools

Talha Ramzan — Sun, 02 Aug 2026 12:25:02 +0000

PDF merge, split, and compress sound like the most boring possible features to build. Take some files, do an operation, return a file. I believed that too, until real user files started hitting the backend and every one of these tools broke in a different, specific way.

Here's what actually went wrong, and what fixed it.

The PDF that wasn't actually a PDF

The first crash report was a "corrupted file" error on a PDF that opened fine in every desktop viewer. Turns out plenty of real-world PDFs are technically malformed, a missing xref table, a truncated stream, an object reference pointing at nothing but viewers like Chrome and Acrobat are extremely forgiving about it. Most Python PDF libraries are not.

try:
    reader = PdfReader(file_path, strict=False)
except PdfReadError:
    # strict=False alone doesn't save you from everything —
    # some files need the xref table rebuilt from scratch
    reader = PdfReader(file_path, strict=False)
    reader._override_encryption = True

strict=False fixed maybe 70% of the "corrupted" reports. The rest needed a repair pass first — scanning the raw byte stream for object markers and reconstructing a valid cross-reference table before the normal parser ever touches it. Painful to write, but it turned "please fix your PDF" into "it just works," which matters a lot when the whole pitch of the tool is "no signup, just upload and go."

Merging PDFs is not free, memory-wise

The naive merge implementation loads every input PDF fully into memory, concatenates pages, writes the output. Fine for two 200KB files. Not fine when someone merges fifteen scanned documents at 40MB each, because now you're holding the equivalent of 600MB of parsed PDF objects in memory at once on a backend container that doesn't have unlimited RAM.

The fix was switching to incremental writes process one input file at a time, write its pages to the output stream, then explicitly drop the reference before moving to the next file:

writer = PdfWriter()
for path in input_paths:
    reader = PdfReader(path, strict=False)
    for page in reader.pages:
        writer.add_page(page)
    del reader  # don't let the parsed object tree accumulate
    gc.collect()

The gc.collect() call looks paranoid, and normally I'd agree it's unnecessary, but with large parsed PDF object trees holding circular references (pages referencing parent objects referencing the page tree back), Python's reference counting alone doesn't reliably free them fast enough between iterations under real memory pressure.

Decompression bombs are a real concern for PDF compression

A PDF compression tool that accepts arbitrary uploads and re-encodes images inside them has to worry about the same class of attack as a zip bomb: a small, legitimately-sized PDF that contains an image with an absurd decompressed resolution. A 500KB PDF containing a "photo" that decompresses to 40,000 × 40,000 pixels will happily consume gigabytes of memory the moment you try to re-encode it.

MAX_PIXELS = 50_000_000  # ~50 megapixels, generous for real photos

if image.width * image.height > MAX_PIXELS:
    raise ValueError("Image dimensions exceed safe processing limit")

This check has to happen before decompression, based on header metadata alone, checking after you've already decoded the full image into memory defeats the entire point.

PDF-to-Word is where font and layout fidelity actually breaks

Converting a text-heavy PDF to editable Word is mostly solved. Converting a PDF with multi-column layouts, embedded custom fonts, and tables is a different problem entirely. The PDF format doesn't really have a concept of "this text belongs to this table cell" it just has text positioned at specific x/y coordinates on a page. Reconstructing table structure means inferring it from whether text blocks are roughly aligned in a grid, which is a heuristic, not a guarantee.

The honest fix here wasn't a clever algorithm — it was setting expectations correctly. Simple, single-column PDFs convert close to perfectly. Complex multi-column academic papers or financial statements with dense tables convert "usably editable, expect to fix formatting," and the tool now says exactly that instead of silently producing a mangled table and letting the user discover it themselves.

Cleanup matters more than it sounds like it should

Backend hosting on a platform like Railway means the filesystem is ephemeral, but "ephemeral" doesn't mean "instantly cleaned between requests" temp files from a crashed or abandoned conversion can sit around until the container itself restarts. Under real traffic, that adds up to disk pressure from files nobody's coming back for.

try:
    result = process_pdf(temp_input_path)
    return result
finally:
    if os.path.exists(temp_input_path):
        os.remove(temp_input_path)

The finally block matters more than it looks like it should an exception partway through processing shouldn't leave an orphaned file, and it's an easy thing to skip when you're focused on the happy path.

What I'd tell someone building similar tools

Real-world files are messier than test files. Malformed PDFs are common enough that a repair/recovery path isn't optional if you're accepting arbitrary uploads.
Any tool that decodes user-supplied compressed data needs a size check before decompression, not after the same principle as zip bombs applies directly to embedded images.
Memory accumulation across a loop is easy to miss when each individual file seems small it's the cumulative footprint across an entire batch operation that actually causes problems in production.
Being honest about fidelity limits (this converts cleanly, this one needs manual cleanup) builds more trust than silently producing a degraded result and letting the user find out.

The tools are live and free if you want to see them in action: PDF merger, splitter, and compressor are all part of DukoTools no signup required.

Happy to go deeper on any part of this in the comments, especially the PDF repair/recovery logic if anyone's dealt with similarly malformed real-world files.

Building a Video Downloader That Doesn't Break Every Time YouTube Sneezes

Talha Ramzan — Thu, 30 Jul 2026 11:21:07 +0000

A few weeks back I wrote about the lessons I learned building 120+ free tools solo. A few people asked which tool was the hardest to actually keep working hands down, it's the video downloader. Not because the initial version was hard to build. Because YouTube (and every other platform) actively fights you, and the "happy path" breaks constantly in production.

Here's what building and maintaining it actually looked like.

The naive version (day 1)

Like everyone, I started with yt-dlp. It's genuinely excellent handles 1000+ sites out of the box, actively maintained, and for the first few weeks it just worked.

python:
import yt_dlp

def get_video_info(url):
with yt_dlp.YoutubeDL({'quiet': True}) as ydl:
return ydl.extract_info(url, download=False)

Clean, simple, done. Or so I thought.

Problem 1: YouTube blocks you back

Within a couple weeks of real traffic, YouTube started throwing bot-detection errors intermittently not always, just often enough to be genuinely annoying to debug. Some requests worked fine, others got flagged. Classic cat-and-mouse: yt-dlp ships a fix, YouTube tweaks detection, repeat.

Two things helped:

PO tokens (proof-of-origin tokens) — a bypass mechanism yt-dlp added support for
Cookie injection — passing a logged-in session's cookies through YOUTUBE_COOKIES_TEXT/YOUTUBE_COOKIES_FILE env vars, in Netscape cookie format

But neither is bulletproof, and yt-dlp itself needs constant updates to keep pace. I ended up version-checking and self-updating yt-dlp on every cold start (pip install --upgrade git+...) rather than pinning a version, since a week-old release could already be obsolete against YouTube's latest detection.

Problem 2: When the primary engine fails, fail gracefully

Even with cookies and PO tokens, yt-dlp occasionally gets fully blocked for a stretch. Instead of just erroring out to the user, I added a fallback engine: pytubefix, specifically for YouTube.

The interesting part wasn't just "try A, then try B", it was building a proper circuit breaker:

python
class YouTubeCircuitBreaker:
def init(self):
self.consecutive_failures = 0
self.backoff_until = None
self.backoff_minutes = 1

def record_failure(self):
    self.consecutive_failures += 1
    if self.consecutive_failures >= 5:
        self.backoff_until = now() + timedelta(minutes=self.backoff_minutes)
        self.backoff_minutes = min(self.backoff_minutes * 2, 60)

def should_bypass_primary(self):
    return self.backoff_until and now() < self.backoff_until

After 5 consecutive yt-dlp failures on YouTube specifically, the circuit "trips" and routes straight to pytubefix for a backoff window — doubling up to a 60-minute ceiling. This meant users stopped seeing hard failures during YouTube's flakier periods, and yt-dlp got breathing room instead of hammering an API that was already rejecting it.

Problem 3: People will absolutely try to use this to hit internal infrastructure

Any tool that accepts a URL and fetches it server-side is a potential SSRF (Server-Side Request Forgery) vector. Someone will eventually try passing http://169.254.169.254/latest/meta-data/ (cloud metadata endpoints) or http://localhost:6379 (internal Redis) just to see what happens.

Before any URL reaches yt-dlp, it goes through a private-host check:

python
def _is_private_host(hostname):
ip = socket.gethostbyname(hostname)
ip_obj = ipaddress.ip_address(ip)
return (
ip_obj.is_private or
ip_obj.is_loopback or
ip_obj.is_link_local or
hostname.endswith(('.internal', '.local'))
)

Blocking private/loopback/link-local ranges and internal TLDs before the extractor ever sees the URL. Cheap to implement, and it closes off an entire class of abuse that's easy to forget about until someone finds it for you.

Problem 4: Format strings are basically user input into a shell-adjacent tool

yt-dlp's format selector syntax is powerful you can do things like bestvideo+bestaudio/best. But if you're building that string from user-supplied quality/format choices, you're one step away from format-selector injection. A whitelist regex on allowed format-selector patterns closed that gap before it became a real problem.

Problem 5: Rate limiting, because bandwidth isn't free

200MB max file size, 10 downloads per IP per hour, and a 5 minute in-memory cache (max 500 entries) for repeated metadata lookups mostly to avoid re-extracting info for the same viral video getting hit 40 times in an hour by different users.

What I'd tell someone building something similar

Don't trust the "it just works" phase. It works until the platform you depend on changes something, and it will.
A fallback engine is worth the complexity if your primary dependency has any adversarial relationship with the source (bot detection, rate limits, ToS enforcement).
Circuit breakers aren't just for microservices even a single external dependency benefits from "stop hammering this after N failures" logic.
Any tool that fetches user-supplied URLs server-side needs SSRF protection from day one, not as an afterthought after a security report.

The tool is live and free if you want to see it in action: dukotools.com/tools/video-downloader — supports YouTube, TikTok, Instagram, and 13 other platforms.

Happy to go deeper on any part of this in the comments especially curious if anyone's solved the yt-dlp bot-detection cat-and-mouse better than cookie injection + PO tokens.

I Built 120+ Free Online Tools. Here Are 10 Mistakes I'd Never Make Again.

Talha Ramzan — Tue, 28 Jul 2026 15:28:04 +0000

Four months ago I decided to build a simple utility website.

The original plan was maybe 15–20 tools.

Instead, I somehow ended up shipping 120+ tools covering PDFs, images, developers, students, finance, AI utilities, and a lot of niche calculators.

Looking back, I made almost every mistake a solo developer can make.

Hopefully this saves someone else a few months.

1. Stop waiting for the "perfect launch"

I spent four months building before showing the project to anyone.

Huge mistake.

Nobody cares how many features you have.

People care whether you solve their problem.

If I started again, I'd launch after 10–20 tools and let users decide what to build next.

2. Boring tools get used more than clever ones

I thought people would love the complicated AI tools.

Instead, the most used ones were things like:

Image Compressor
PDF Merger
JSON Formatter
QR Code Generator
Password Generator

Simple wins.

People search for solutions, not engineering.

3. Niche tools are an SEO superpower

Everyone builds a BMI calculator.

Almost nobody builds things like:

Pakistani Electricity Bill Calculator
Zakat Calculator
CNIC Validator
Cricket Run Rate Calculator
Construction Bid Comparison Tool The search volume is lower.

The competition is almost zero.

Those pages have become some of my favourites because they solve real problems.

4. Browser APIs are incredibly underrated

Many tools don't need a backend.

Compression.

Image editing.

QR generation.

JSON formatting.

Regex testing.

UUID generation.

Password generation.

CSV editing.

All of these can happen directly inside the browser.

That means:

Faster
More private
Cheaper to host
Works offline

5. Docker can save you from cold starts

One problem almost drove me insane.

My AI background remover worked perfectly locally.

Production?

Every first request timed out.

The reason:

The U2Net model (used by rembg) downloaded on first request.

Around 170 MB.

The fix?

Download the model during the Docker build instead.

One tiny change.

Massive improvement.

6. Users hate unnecessary accounts

I removed logins completely.

No email.

No registration.

No "Create an account to continue."

People just use the tool and leave.

That's exactly what most utility websites should encourage.

7. Performance matters more than animations

I spent hours making animations look perfect.

Users never mentioned them.

They did notice:

slow loading
laggy interactions
mobile issues

Speed is a feature.

8. Mobile users deserve first-class treatment

More than half the internet is mobile.

If your utility only works nicely on desktop...

You've already lost a huge percentage of users.

Every tool I build now starts with mobile in mind.

9. Build things you personally need

One of my favourite features is an Online Clipboard.

Open it on your desktop.

Scan a QR code.

Start typing on your phone.

The text appears instantly.

No login.

No app.

No emailing yourself.

It wasn't built because someone requested it.

It solved a problem I had every week.

Those are often the best products.

10. Marketing is part of building

Developers often think marketing starts after shipping.

It doesn't.

If nobody knows your project exists...

It doesn't matter how clean your architecture is.

Building is comfortable.

Marketing is uncomfortable.

Unfortunately, both are required.

Where the project is today

The project has grown into DukoTools, a collection of 120+ free online tools.

Everything is free.

No signup.

Many tools work entirely in the browser, and the site can even be installed as a Progressive Web App for offline use.

I'm now focusing on improving the existing tools based on real user feedback instead of endlessly adding new ones.

If you have a favourite online tool that doesn't exist or one that could be significantly better I'd genuinely love to hear about it.

Building is fun.

Building things people actually use is even better.

I built 120+ free online tools as a solo dev — here is what I actually learned

Talha Ramzan — Wed, 22 Jul 2026 13:02:47 +0000

I am going to be honest with you. This project started out of pure frustration.

Every time I needed to do something simple — compress an image, convert a PDF, format some JSON — I would land on a site that hit me with a cookie banner, then a popup asking me to sign up, then an ad covering half the tool, and then after all that the tool would not even work properly on my phone.

I got tired of it. So I built my own.

What I built
dukotools.com is a free utility website with 120+ tools. No ads right now. No signup ever. Works offline as a PWA. You can install it on your phone like an app and use most tools without internet.

It covers the usual stuff — PDF conversion, image compression, background removal, JSON formatting, regex testing, SQL formatting. But it also has tools I genuinely could not find anywhere else free:

A Zakat calculator for Muslim users that handles gold and silver Nisab thresholds. A Pakistani electricity bill calculator that uses the current NEPRA tariff slabs. A CNIC validator that detects province and gender from the ID number. A cricket run rate calculator that supports custom balls per over because street cricket in Pakistan does not always use 6-ball overs. A construction bid comparison tool for US contractors that scores bids on price, completeness, and qualifications.

Some of these are niche. But they solve real problems for real people and nothing good existed for them before.

The tech stack
Frontend is Next.js 14 App Router with TypeScript, Tailwind CSS, Zustand for global state, and next-intl for 5 language support covering English, Urdu, Arabic, Spanish, and French. Deployed on Vercel.

Backend is Python FastAPI with PyMuPDF for PDF processing, pdf2docx for Word conversion, rembg for AI background removal, yt-dlp for video downloading, pytesseract for OCR, and LibreOffice headless for converting Excel and PowerPoint files to PDF. Deployed on Render.

Realtime features use Supabase. The rest is just browser APIs.

The most interesting thing I built
The online clipboard tool.

The problem: you are on your phone and you need to get a chunk of text to your laptop without emailing yourself or using WhatsApp. Most solutions require an account or an app install.

My solution: open dukotools.com/tools/online-clipboard on both devices. A QR code generates instantly on the desktop pointing to a URL with a 6 character room code. Scan it on your phone. Both devices connect to the same Supabase Realtime WebSocket channel. Type on one device and the other updates in under a second. No account. No app. Session expires in 60 minutes and nothing is stored after that.

The interesting engineering parts were managing WebSocket reconnection with exponential backoff when the connection drops, handling the edge case where both devices type simultaneously without one overwriting the other, and generating the QR code entirely client side with zero server calls using qrcode.react so the feature works even if the backend is down.

It is a small feature but users genuinely love it. It solves a daily annoyance in a way that feels like magic the first time you use it.

What was harder than I expected
Getting the background remover to work reliably in production.

rembg is an incredible open source library that removes image backgrounds using a U2Net machine learning model. The problem is it downloads a 170MB model file on first run. On Railway and Render free tier the first request after a cold start would time out waiting for the model to download.

The fix was embarrassingly simple once I figured it out. I added a line to the Dockerfile that runs a dummy background removal operation during the Docker build phase. This forces the model to download and cache during build time rather than at runtime. First request now responds in under 3 seconds instead of timing out.

One line of Python in the Dockerfile saved me days of debugging.

What I would do differently
Start marketing on day one.

I built for four months before telling a single stranger about the site. Every tool I added in month three could have waited. The first 20 tools were more than enough to start collecting feedback and finding out what people actually wanted.

Building feels productive. It is comfortable, measurable, and completely in your control. Marketing feels uncertain and uncomfortable. So you keep building instead.

But 120 tools with zero users is worth less than 20 tools with 500 daily visitors. I know this now. I am telling you so you do not make the same mistake.

Where it stands today
The site is live at dukotools.com. It is completely free. I am only starting to do marketing now after 4 months of building in silence.

If you have 2 minutes I would genuinely appreciate you trying any tool and telling me what is broken, what feels slow, or what tool you use daily that I have not built yet. That feedback is more valuable to me right now than anything else.

And if you have ever built something and kept it hidden for too long , you are not alone. Ship earlier than you are comfortable with. Every time.

Thanks for reading. I am documenting this whole journey publicly if you want to follow along.