Welcome to my Lingo.dev hackathon journey! Over the past week, I set out to build something cool using the Lingo API. What started as a vague idea transformed into a high-performance translation pipeline. Let’s look at what I built, how I built it, and the roadblocks I slammed into along the way.
The Brainstorming Phase
When the hackathon was announced, my first thought was the path of least resistance: “I’ll just build a production-grade app and slap a layer of Lingo localization on top.” But as I thought about it, that didn't solve a real, bleeding-neck pain point. While browsing GitHub, I noticed a very real problem: many amazing open-source repositories have their READMEs written entirely in their native language (like Chinese, Spanish, or Japanese). When developers try to read them, they copy-paste the text into Google Translate.
The result? Absolute chaos. Google Translate breaks the code blocks, turns terminal commands into literal verbs, and destroys the context of the markdown formatting.
"Ideas don't come fully formed, they refine by building them." — Mark Zuckerberg
This quote resonated with me. I had a problem to solve. Lingo.dev’s API natively protects Markdown syntax. So, I decided to build a web app—mostly because I already know React—that takes a README and translates it cleanly using the Lingo API.
Idea -> App -> Chrome Extension : Reduce friction
Almost immediately after deciding to build a web app, I realized a fatal flaw.
To use my app, a developer would have to open a new tab, go to my site, copy a massive README from GitHub, paste it, translate it, and read it completely out of context. That creates a massive amount of friction.
As a senior developer once told me: “If you can reduce the friction for the user, then you have a good product. Solve something in an easy way.”
How could I reduce the friction to zero? A Chrome extension. If I could put a "Translate" button directly on the GitHub repository page, the user could translate the docs without ever leaving the site.
Building the Chrome Extension
I had never built a Chrome Extension before, so I dove headfirst into the official Chrome Developer docs (with googling and with the help from ChatGPT, of course).
I implemented the frontend of the extension, injected a slick UI button onto the GitHub DOM, and wired up the Lingo API to fire when the user clicked it.
Boom! I clicked the button... and it failed.
Or rather, it took so incredibly long that the browser basically gave up.
I quickly learned a hard lesson: doing heavy-lifting API calls and data processing directly in the frontend extension is a terrible idea.
Creating the Backend
To reduce the friction on the browser, I decided to offload the heavy lifting. I spun up a separate Node.js backend using Express and the Lingo.dev SDK to handle the actual computations.
I wired the extension to send the raw markdown to my new backend. I tested it on a few small README files, and it worked flawlessly. The markdown stayed perfectly intact, and the translation was spot on. I felt like I had already won.
And then, I decided to stress-test it on calcom/cal.com.
I clicked translate. The button went into a loading state... for roughly two minutes. I honestly thought my server crashed or the code broke somewhere. I added some performance timers and ran it again.
It took 170.05 seconds. That is nearly three minutes. You cannot make a user wait that long. It completely defeated my entire philosophy of reducing friction.
The Optimization: Beating the 170-Second Nightmare
I started debugging the bottleneck. The Cal.com README is massive—over 15,000 characters. I realized that the standard "send and wait" approach (sending one giant payload to an LLM) was choking the API.
I asked myself: Why don't we break the file apart, send the pieces in parallel, and stitch them back together?
I researched the feasibility of this approach and dug into API rate limits. Here is the high-performance architecture I ended up building:
-
Intelligent Chunking: Instead of splitting the text at random character counts (which breaks sentences), we split the Markdown using the delimiter
\n\n(double newlines). This ensures each "chunk" is a collection of complete paragraphs, preserving semantic context. - The Bucket System: We set a limit of 5,000 characters. The backend adds paragraphs to a "bucket" until the next paragraph would exceed the limit. Then, it starts a new bucket.
- The Parallelism Problem: If you send all the chunks sequentially, it takes forever. If you send them in parallel, 10 chunks take roughly 10 seconds (the time of the single longest request).
-
Controlled Concurrency: Pure parallelism carries a massive risk. If we fire 100 requests at once, the API thinks it's a DDoS attack and blocks us with an HTTP 429 Rate Limit error. I solved this by implementing a Semaphore pattern using
p-limit. This keeps exactly 10 requests processing at any given time, keeping the pipeline full without overwhelming the server.
I pushed the new code and hit translate on Cal.com again.
It took 30 to 40 seconds. By utilizing controlled concurrency, I shaved over two minutes off the processing time. The speed difference was staggering.
Future Scopes
GitLocalize is live and working, but ideas keep refining. Here is what is next for the project:
- Token Optimization: Currently, we send code blocks to the API. To save Lingo credits and speed up processing, I plan to use Regex to strip code blocks before translation, and merge them back into the document afterward.
- PR & Issue Translation: Expanding the extension to automatically translate discussions and code reviews inside GitHub Pull Requests.
-
Offline Persistence: Allowing users to export and download the translated
.mdfiles directly to their machines. - Auto-Language Detection: Reading the browser's headers to auto-translate repos without the user ever clicking a button.
Check it out!
You can view the full source code and try the extension yourself here:
https://github.com/devananth/GitLocalize
Demo:
Thanks Note: A huge thank you to the organizers of the Lingo.dev hackathon. Building this forced me to dive deep into concurrent Node.js architectures and Chrome Extension manifests. It was a phenomenal learning experience. Happy shipping!
Top comments (1)
This could easily evolve into a broader “developer localization layer” rather than just a Chrome extension. The PR translation idea is especially interesting. Do you see this staying as a tool, or becoming a platform/API for other dev products?