丁宇 | DING Yu
Lessons From Building a Translator App That Beats Google Translate and DeepL
How It Started
Recently, I made a new app called Kintoun. It’s a document translator that delivers very high quality translations and keeps the original layout almost perfectly.
At first, I didn’t expect much. But after comparing it with Google Translate and DeepL, I was surprised to see that my app actually performs better in many cases.
In this post, I want to share what I’ve learned while building it. Writing helps me organize my thoughts, and maybe some of this will be useful if you’re working on your own project too.
Lesson #1. Surprise: My app is actually better than Google Translate and DeepL
Let me show you some examples.
Document #1: Original
This is a Word document from Microsoft:
Document #1: Google Translate Result
I translated it into Japanese using Google Translate:
Google Translate couldn’t handle it well. The text wasn’t translated, and the layout and fonts got messed up. I tried with different documents and languages, and it was always the same.
Document #1: DeepL Result
Now let’s try DeepL:
DeepL did a much better job, but some parts, like “Appetizer,” were missing.
Document #1: Kintoun Result
Finally, here is the result from Kintoun:
Kintoun correctly translated all the text and kept the layout intact.
Document #2: Original
Sometimes documents have Phonetic Guide Text (also called Ruby text) to show pronunciation.
For example, Japanese documents often include Hiragana above Kanji.
Here is another document with phonetic guides:
Document #2: Google Translate Result
I translated it into Japanese using Google Translate:
Google Translate completely ignored the text with phonetic guides. The translation became incomplete and confusing.
Document #2: DeepL Result
Here is the result from DeepL:
DeepL could handle the phonetic guides, but it broke the layout. For example, the bullet points in the table disappeared.
Document #2: Kintoun Result
And here is the result from Kintoun:
Kintoun properly translated everything and preserved the layout.
I could show more examples, but you probably get the idea.
Honestly, it feels a bit surreal. I’m just a bad amateur programmer who would fail any serious technical interview, and I only spent about two weeks of spare time, besides my day job and taking care of my kid. How could I ever make something better than those big companies?
And yet, somehow, I did.
Lesson #2. Product distribution is as important as product development
I came across a Reddit post the other day, and it really hit me:
The pattern was always the same:
- Get excited about an idea
- Spend months building it
- Launch to complete silence
- Get depressed
- Repeat
This is exactly me, and probably many other indie hackers.
The post also shared how to break the cycle:
What Worked:
- Finding people ALREADY looking for a solution
- Instead of cold DMs, I searched for posts like "anyone know a tool that..." or "frustrated with [competitor]" and offered genuine help.
- Leading with help, not sales. My first message is usually answering their question thoroughly. Only AFTER providing value did I mention "I actually built a tool that might help..."
I read it carefully and have been keeping it in mind ever since. I also found the same advice from Dmytro Krasun, the maker of screenshotone.com:
If you don’t have any idea whom you are going to sell your product, don’t build it.
In practice, though, I didn’t really understand it until I released Kintoun and started promoting it. Right now, I only have some vague ideas about promotion. I don’t know which ones will work, or how exactly to execute them.
Looking back, I think I should have spent as much time figuring this out as I did building the app. Maybe even before starting development.
Or maybe I shouldn’t have built it at all until I had a clear idea about distribution, like the old “correct” way of bootstrapping: get customers first, then build (“fake it until you make it”).
Lesson #3. Inertia + Svelte is awesome
Maybe it’s just me being too dumb, but even after using Hotwire in production for a while, I could never really understand how it works.
For example:
- How am I supposed to redirect the page with a 302?
- How can I make five elements scattered across the page reactive without manually managing their IDs?
- How should I submit a form correctly? Should I use Turbo Stream, Turbo Frame, or both?
Of course, I could go back to jQuery and the good old Asset Pipeline. Actually, I’m still using that combination in production for work and side projects. But it would be a nightmare if I ever wanted to make the app even slightly reactive.
After evaluating a bunch of options, I eventually landed on Inertia.js and Svelte. The result was a complete game changer.
It became so easy and magical to render highly reactive views in the browser, integrated with Rails through Action Cable, without the messy APIs and state management of traditional SPAs.
Although Svelte has a smaller ecosystem compared to React, it’s much easier and faster to build with.
If you haven’t already, I highly recommend trying:
- Inertia-Rails: glue Rails and your front-end framework
- Svelte: easier than React
- livestores: push server state to front-end via Action Cable
Final Thoughts
Building Kintoun has been one of the most fun projects I’ve worked on. Unlike many of my other side projects, this time I got real feedback very quickly, from my wife.
She found Kintoun very useful. She uses it a lot and even said it’s better than the expensive translation service she uses at work. To me, that feedback is very direct. I built something, and I can see people around me actually like it. It’s very fulfilling.
At the same time, I’m still trying to figure out how to let more people know about it and use it. That’s the next challenge, but it’s also part of the journey, and I’m excited to keep going.
Thanks for reading. If you’re curious, you can check out Kintoun. I hope you find it useful too. And if you have any feedback, I’d love to hear it.