<aside> 👉 Every company’s situation is different in terms of the scope of work involved, languages targeted, etc. This is intended as an exercise to help you understand roughly what you’ll need to plan for.
</aside>
You’ll generally have a lot less in app content than you do on your website, help center, etc. You can think of app localization as a form of marketing or market testing. Also, in some markets like Japan, not being localized is a direct barrier to adoption and usage. You can quietly turn on new interface languages and set up a before|after AB test to evaluate how key metrics for adoption churn, upgrades, etc changed as a result.
A typical app will have somewhere between 5,000 to 20,000 words of in app content, towards the higher end if the app is more complex or has embedded help content. Translation services are generally priced by the word. Pricing is a function of how much review is involved, and which languages are targeted (some languages are easier to staff than others).
The gold standard in terms of quality is a four step process that includes the following steps:
I tell customers to expect this to work out to 35-40 cents per word when all of these steps are factored in (the actual cost will be lower, especially if a blended human|AI process is used but its best to over-estimate a bit for budgeting purposes). That works out to between $2,000 to $8,000 per interface language. That typically works out to a next extra 20 to 80 paid seats for a typical SaaS product. You read that correctly. It is one of the best growth levers, and relative to the revenue it enables, dirt cheap. Some of the companies I have worked for generated well over half of their revenue outside the US.
<aside> 🤔 Can’t we just get AI to translate everything for free?
We are big fans of hybrid machine + human translation approaches. That said, it is generally not a good idea to rely on unsupervised machine translation especially for high visibility content. Machine translation has improved a lot. The risk isn’t that it will translate “Sign Up Now!” as “Your Mom Has Sex With Goats!”. The issue is that native speakers will pick up that the translation is machine generated (translations are often decent but stilted or robotic sounding, and also contain grammatical errors that look sloppy to native speakers). Not what you want at the top of a signup funnel. Another issue is that in app content often consists of short phrases or single words. These are difficult for machine translation engines to deal with so they will often translate a noun phrase as a verb and vice versa (human translators get confused too, but they know to ask for clarification in situations like this).
TL;DR you can definitely use machine translation to pre-populate translations and for UI testing, but you’ll want to have humans in the loop to tweak or rewrite them. As AI translation improves, reviewers will have to make fewer changes, so unit costs will come down. Most translation management systems have AI|machine translation as a built in option for workflows. Even better, they intelligently route to different providers depending on the language targeted because some AI|MT platforms do better than others with specific languages.
Caveat: this is all a moving target right now with the rapid evolution of LLMs.
</aside>
I recommend picking a couple of languages. One language, like Spanish, that is widely spoken in many regions (over 30 countries and large parts of the US). Plus another language spoken in a region where you are seeing organic demand. At Notion, for example, we had huge user communities in Korea and Japan, even when our app was English only. We figured that adding these languages could only help. Korea and Japan are two of the company’s top regions today.
The next step up from experimental localization is to localize all customer touch points. This typically includes: