Software Internationalization 101: How to Go Global Without Slowing Down

Going global is a big vision for companies and it's just as big an undertaking for their development teams. Since we started internationalizing HubSpot’s marketing software over a year ago, we’ve realized there’s way more to it than translating “color” to “colour”. To create a truly global product from the ground up, organizations have to make a commitment to solving for customers worldwide.

When we started our internationalization (i18n) and localization (l10n) efforts, our goal was to make our application feel just as natural for users in Munich or Tokyo as it does for our US-based customers. That meant we couldn’t put it off (we already had customers in 70+ countries at the time) or outsource a solution. (This might’ve worked in the short-term, but it wouldn’t get us thinking habitually global. And, we wouldn’t have had ownership over our source code; not very HubSpotty.) So, we went all in.

But there was a catch, a cultural caveat. Our dev team is fueled by flexibility, speed, and complete autonomy. We didn’t want i18n to disrupt that rhythm so we needed to find a way to upgrade the engine while driving the car. It didn’t take too long to realize that this would be a herculean task. i18n usually entails large spreadsheets, product freezes, a lot of back-and-forth between developers and linguists (both of them often speaking different languages, literally and figuratively) and some mundane code writing. This traditional workflow wasn’t going to fly. We had to get creative, early and often, to avoid slowing down development.

A year later, we’re still on the road to product i18n. We’ve started to see real results, international customers interfacing with our software in beta, and some key learnings that helped us get here. I wanted to share these findings because I think they can help expand what i18n means to SaaS development teams and ultimately, get more of a dialogue started on the role company culture plays in i18n.

Get a Head Start on i18n

If you’re an early-stage, fast-paced SaaS startup, going global is probably the last thing you’re thinking about, at least from a product standpoint. There are a million and one things to do so you’re usually focused on building for today or tomorrow, not ten years down the line. HubSpot was no different and we built some technical debt early on that we had to dig our way out of when we started i18n.

Luckily, we started thinking about l10n before the business side of HubSpot really needed it so we were able to head off a lot of pressure from outside the product team. More importantly, getting a head start gave us ample opportunity to find the best plan of attack without implementing a breakneck timeline on the team.  

At the onset of the i18n project our development team was in the process of migrating away from our Python-heavy (Django) stack, built around server-side rendering, and moving onto a static, JavaScript stack. So we chose to marry up the i18n efforts with the stack migration and not pursue internationalizing the legacy code. Basically, we figured while the code was on the surgery table, we’d include the i18n work as well.  This allowed us to incorporate the i18n infrastructure in a very fluid and organic way.  The stack migration was a colossal task, but also incorporating an i18n-friendly infrastructure into the process was pretty remarkable and saved us a lot of energy in the long run.

We managed to have a bare bones platform in place within about 4 months and have since incorporated roughly 90% of the app to the new tech stack, internationalizing as we go without ever bogging the team down with an additional rewrite effort.

Getting a product to market and iterating is the foundation of development teams like ours. Having a head start on the business meant we could thoughtfully start implementing i18n, without disrupting that pace. There are many factors that go into determining the best time to start thinking about taking your product global, but being proactive will help avoid a mad rush when the continued growth of your company is on the line.

Consider Your Dev Culture Before Incorporating Global Cultures

Every development team is different. The i18n process that works for one team might not work for another because we all bring unique challenges and workflows to the table. That’s why having a solid understanding of how your team operates is crucial in shaping the optimal path forward.     

At a lot of companies, i18n can hold everything else up. Human translation takes longer (days to weeks) to process and instead of shipping updates in the interim, developers have to hold off until the translations are ready. It turns into a waiting game. When we were considering traditional i18n/l10n workflows, it quickly became clear that these constraints wouldn’t jibe with our team culturally. Our product organization is built on the premise that we ship quickly (around 300+ times a day) without much process or planning getting in the way. The goal is to get something in front of the customer as soon as possible so we can gather and implement their feedback just as quickly.  

Implementing a top-down approach to i18n would have been detrimental to. We specifically chose not to go down that path, forcing us to think differently. We’ve tried to build automation into a lot of tasks (like sending English strings files to our translation management system (TMS) and building in notifications for completed translations and pull requests) that would otherwise slow our developers down. The most important aspect of i18n for us has been coupling our required tech debt-relief activities and i18n into already planned development projects and then automating as much of the l10n process as possible. These decisions have helped us integrate i18n into our development culture without making it burdensome or attaching a negative stigma to the process.

Build l10n Into Your Process, Not the Other Way Around

You can probably tell by now that we put some serious time and effort into creating an environment that maximizes our developers’ strengths and lets us iteratively improve our product. So, the last thing we wanted was to hold our team hostage to a translation workflow. We work hard to instill a global mentality within the development team so that we’re always building with international customers in mind. But, we don’t want our developers to have to slow down to manage translations for their projects either.

To tackle this, we built an internal service to manage the translation workflow and the connection points between our code repos and our translation management system. The typical workflow looks something like:

• A developer makes changes to their app that requires an addition/amendment to English copy in the app. (They do this by interacting directly with a “strings” file that houses all the English copy for their project.) They commit their changes to GitHub.
• The automated service, that we affectionately call Babel, is constantly “listening” for any changes to the English source files. Once the developer commits the change, Babel notices and triggers the translation workflow.
• Babel is tied to our TMS via a public API connection that allows us to automate the process of shipping the “strings” files and authorizing them for translation.
• Within a few minutes, Babel is notified that machine translation for the added/amended “strings” is complete. It then pulls them from the TMS and assigns them a pull request in the GitHub project they originated from.
• The developer that made the change is notified that translated files are ready to be incorporated into their branch. They can then merge them at their leisure.
• As the human translations are completed (usually 2-10 hours later), pull requests are created by Babel and the developer can merge those into the project, too.

Waiting on human translations has traditionally been the long pole in the tent of deploying a localized product. So to counter that delay, we purposefully decided that after an app has been through initial translation we are comfortable with surfacing machine translated strings (for small bits of changed copy) while human translations are in progress. This has allowed our developers to focus on shipping code and not on copy translation.

Traditionally, once a new feature is sent to be translated, developers don't deploy changes until days or weeks later once human translation is complete.  

At HubSpot, Babel lets us ship constantly with machine translations until final human translations are complete. 

We’re working toward making this step invisible to developers. In the future, they shouldn’t even have to check or merge any translation-related PRs; it will just happen behind the scenes. But for now, by coupling various forms of translation with an automated service, we have cut down a process that can take days to a few minutes. Which leads me to the final thought…

Look for Translation Management Services (TMS) Built By Developers, For Developers

This point is highly tied to making i18n/l10n work for your team. Unfortunately, in the world of TMS, the software development community is second-tier. The bulk of translation work that is managed by TMS platforms is in the realm of digital documents, forms, books, marketing content, etc., not software product strings. This has led to developers being pigeonholed into using translation workflows that aren’t tailored to their goals, making the process disjointed and tedious.

Luckily for us SaaS companies, there are TMS platforms out there, like Smartling (what we use) that are becoming quite involved in the day-to-day lives of fast-moving development teams. Better yet, they’re starting to solve for our use cases. One indicator of a good, development-minded TMS is that they have a mature, well-documented API offering for developers to leverage. We’ve noticed that TMS platforms that make developers lives easier happen to have really sophisticated development teams themselves. Go figure.

When I was approached with the prospect of leading the charge on i18n, I didn’t really know what I was getting into. But there were two things I knew for sure. The first was that HubSpot was going global no matter what; we were already expanding rapidly and constantly bringing on new customers in new countries. There wasn’t a question of whether or not we would internationalize our marketing software, it was just a question of how.

The second thing was that i18n couldn’t leave us with culture debt. We’ve built a strong development culture that makes building products here challenging, autonomous, and fast. Our process couldn’t disrupt that. Now that we’re deep into i18n, I feel confident saying it hasn’t. The four lessons above haven’t just helped us fix the engine while driving, but replace it with a new, upgraded engine.

We’re still learning a lot everyday about how to make this easier for our developers and our customers. Our culture of transparency and constant iteration makes it seamless for everyone to give us feedback and for us to put the feedback into motion. That holds true both internally and externally, so if you have any questions about i18n, want to talk shop, or share your i18n experiences, leave a comment below. We’d love to take the discussion global, too.