What I Learned Building an AI Video Clipper for Hinglish Creators

Baljeet Singh — Mon, 26 Oct 2026 16:42:50 +0000

Most AI clipping tools I tried were clearly built for English first. They did fine on a US podcast, but when I fed them a typical Indian creator video, where someone says "Yeh setup bahut simple hai, bas ek good mic le lo", the captions fell apart. That gap is why I started building Printivelle, an AI tool that turns long videos into Shorts and Reels with Hindi, Hinglish or English captions.

This post isn't a launch announcement. It's the set of problems I didn't expect, and what I'd tell another developer building anything around Indian-language audio or a single-page app that needs to rank on Google.

1. Hinglish is not one language, and it isn't one script either

The first surprise was that "Hindi captions" means at least three different things to creators:

Devanagari Hindi: "यह गलती मत करना"
Hinglish in Roman script: "Yeh galti mat karna"
Code-mixed speech: a sentence that switches between Hindi and English mid-way, often several times

A speech-to-text model will usually pick one script per segment. So the same speaker can come out as Devanagari in one line and Roman letters in the next, and English words sometimes get transliterated into Devanagari ("सेटअप") when the creator wanted them left as "setup".

What I learned:

Don't try to be clever about the "right" script. The audience decides. News, devotional and educational creators often want Devanagari. Lifestyle and tech creators often want Roman Hinglish. I generate in the spoken language and make every line editable, and the transcript tool can convert Hindi to Hinglish.
Spelling consistency matters more than spelling correctness. In Roman Hinglish there's no standard for "hai" vs "h" or "nahi" vs "nahin". Viewers stumble when it changes between lines, not when it differs from a dictionary.
Names and brand words will be wrong. Channel names, slang and product names are where the model fails most. A fast editing UI does more for caption quality than any prompt trick.

2. Fonts are a real bug source with Indic scripts

Devanagari has matras and conjuncts that break in fonts that don't fully support the script. On a phone screen, a broken conjunct looks like a typo, and creators blame your tool.

Two rules I ended up following:

Ship proper fonts per script. I added Devanagari, Punjabi, Bengali, Tamil, Telugu, Gujarati, Kannada and Malayalam fonts instead of relying on system fallbacks.
The preview must use the same fonts, line breaks and timing as the final render. If the browser preview wraps a line differently from the rendered MP4, users lose trust fast. "What you see is what you get" turned out to be a feature in itself.

3. Caption timing and SRT: the boring part that takes the longest

Generating text is the easy bit. Getting it to appear at the right moment is harder.

A few things I learned about timing:

Short lines read better on mobile. Two to five words per line works for vertical video. Long subtitle-style lines that are fine on a laptop are unreadable in a Reel.
Word-level effects need trustworthy word timestamps. I have a karaoke style where each word lights up as it's spoken. If the word timings for a video don't pass sanity checks, I switch karaoke off and fall back to line-by-line styles. A highlight that runs half a second ahead of the speech looks worse than no highlight.
Validate every timestamp against the real media duration. AI output can drift or invent times past the end of the file. Clamping and checking against the actual video length saved me from a whole class of render errors.
SRT is still the format people need. Burned-in captions are right for Reels and Shorts, but long YouTube uploads want a separate SRT file. SRT is simple (index, HH:MM:SS,mmm --> HH:MM:SS,mmm, text, blank line), but watch the comma before the milliseconds and keep UTF-8 output so Devanagari survives the trip into YouTube Studio.

4. Picking clips and reframing to vertical

The clipping logic looks for self-contained moments of roughly 15 to 60 seconds: a hook, a tip, something funny or emotional. The biggest quality gain came from one rule: start and end on full sentences. A clip that starts mid-word feels broken no matter how good the moment is.

I also stopped forcing a fixed number of clips per video. Some videos have three good moments, some have fifteen. Padding the list with weak clips only makes users trust the good ones less.

For formats, I support 9:16, 1:1 and the original aspect ratio, with reposition and zoom per clip. With two people in a podcast frame, no automatic crop is right every time, so letting the user nudge the frame is worth more than chasing a perfect auto-crop. Re-editing and re-rendering don't use any of the user's minutes, so people actually take the time to fix things.

5. My Vite SPA was invisible to search, until I prerendered it

This one is for web devs. Printivelle's frontend is a Vite single-page app served by Caddy on a VPS. It worked great for users, but every route shipped the same near-empty HTML shell with one generic title. Social previews were identical for every page, and I had no confidence about what search engines were indexing.

The fix was prerendering. Each public route now ships as real HTML with its own:

<title> and meta description
canonical URL
Open Graph tags (with og:locale set to en_IN or hi_IN)
JSON-LD structured data where it fits (software and pricing info plus an FAQ on the homepage, BlogPosting on articles, FAQs on tool pages)

The app still behaves like an SPA once it loads, so nothing changed for users.

Lessons from that migration:

Bilingual routes need clear canonicals. I have English pages, a Hindi homepage, and ?lang=hi variants. The ?lang=hi copies point their canonical to the English URL and are noindex. Running an SEO crawler on my own site later found one route where I'd forgotten the noindex. Audit your own site, it's humbling.
The H1 matters as much as the title. I had keyword-first titles but slogan H1s like "Long video. Short clips. Ready to share." That's nice copy, but it gives search engines no signal. The slogan belongs in the sub-line.
Old routes need redirects, not empty shells. An old URL kept serving the bare SPA shell instead of real content. A proper 301 and a real 404 for unknown paths cleaned that up.
Blog as Markdown files. Posts are plain Markdown with front matter (title, date, description, tags), rendered to HTML with BlogPosting schema, and the sitemap updates on its own. No CMS, and writing a post is just adding a file.

If you run a Vite or React SPA and wonder why Google shows the wrong title or no description, check what your server actually returns with curl before you blame anything else.

What I'd tell myself at the start

Build for the messy real input (code-mixed speech, bad mics, fast talkers), not the clean demo.
Make editing fast and free. AI output is a first draft.
Be honest about limits in the UI. Turning off a feature that would look wrong is better than shipping it broken.
Treat SEO as part of the architecture on day one, not a fix after launch.

If you're building for Indian-language audio, or you've fought with SPA SEO yourself, I'd love to hear what worked for you in the comments.

You can try what I built at printivelle.com. There are 20 free minutes, no card needed, and I'm happy to answer questions about the stack here.