Identifying a pain point
I work as a software engineer for a young ed-tech company that develops a worldwide Ruby on Rails SaaS app. We collaborate with our external translators who help us localize it into multiple languages. As you may already know, the Rails framework uses YAML file format for storing translations. This is a really nice default approach, but it has some cons, too. YAML files are best for computers and good-enough for programmers, but they are terrible for collaboration with non-technical translators. So we tried to find a simple and cheap solution.
Rails allows developers to use multiple different backends to store their translations. Therefore, a possible solution could be to use an SQL database for this purpose and to build a simple web interface for editing our content. But we have a problem here. We deploy an isolated instance of our app for every customer. That means every instance has its own database and we would need (A) to edit translations for each instance or (B) to introduce higher coupling into our infrastructure — by syncing translations, using a master database, or something like that. None of this was a suitable solution.
A better approach would be a micro-service for editing our existing YAML files. What we really need was a centralized interface for our external translators. We wanted to (1) upload our YAML files, (2) invite some translators, (3) let them do their job, (4) download the result. We were able to find and try such solutions. Unfortunately, they provide really cool features which we didn’t need, therefore they were too pricey for us.
I’ve been always interested in micro-services built as side hustles. I’ve read the “build something for yourself, be your first customer” advice too many times. This seemed to be a hot candidate for such an experiment. So, okay, challenge accepted! I bought the localedata.com domain in May 2017 and started working on it.
Building an MVP
After I decided to solve this issue on my own in May 2017, it was time to choose the right technologies and start typing the code. I picked the stack that I was already very familiar with, nothing fancy:
- Ruby on Rails as an application framework (obviously)
- Turbolinks with some vanilla JS for a better user experience
- PostgreSQL as a database
- Redis with Sidekiq for background jobs
There isn’t too much to talk about. The core of this project is pretty straightforward and I’ve been working on it alone. I haven’t use any wireframes or mockups. I just put a bunch of tasks and ideas into my Trello board and…
It takes about six months from the first project idea to the first public deployment. This seems to be a very long time, however, my productivity during the summer was quite low (among other things, I was walking the beautiful Wales Coast Path). It could probably be finished much sooner, but there was no reason to rush it.
Besides programming LocaleData, I’ve been working full-time for the company I am employed in. Sometimes it was quite hard to push myself to work on a side project in the evening, but the key seems to be just to do something regularly, preferably daily. New feature, minor enhancement, or even a small bug fix. Five minutes or five hours. That doesn’t matter. I just need to keep that momentum going, to see some real progress. I’ve found that this really helps me stay motivated.
I publicly deployed the first release in November 2017. I canceled the third-party subscription our company was using, uploaded our translation files into LocaleData and introduced this new tool to my teammates and to our translators. Long story short: They like it even better than the previous pricey solution (and, to my surprise, not only for its zero-price).
Do you want to try?
Just go to www.localedata.com and create your new account. If you have any questions or if you miss a feature, just send me a message.
Original article: The Story Behind LocaleData.com
Oldest comments (0)