It depends, what languages are you targeting? It depends, what's your timeline? It depends, what kind of content are you translating? There is no answer in localization that applies universally.
Translators will tell you human translation is objectively correct for your company. They might be right! Does your use case justify the slower turnaround time and higher expense?
TMS vendors will tell you their software fits your workflow perfectly. This could also be true. What's your workflow? How many dev teams do you have? Do they understand how linguistics can impact a codebase? How much vendor lock-in do you want to avoid?
On and on it goes. This post is a list of the common question I help companies work through.
Should we use human translators, or are LLMs good enough?
Are you working with marketing content? If so, are you focusing on potential users just being able to operate your website, or do you want them to assume your company is native to their language / region?
If you want your users to be surprised to learn you're not native to their language or region, then you should be using a local marketing agency with human translators. If you simply want users of any language to navigate your website successfully, then a modern LLM with human QA can get you really far.
If you're translating UI elements in an app, modern LLMs can do a really great job. The word "Logout" and "Home" etc have been translated ad infinitum and are hard for LLMs to get completely wrong. The more complex your app, the more important it is to clearly communicate.
Do we need a Translation Management System (TMS)?
If you have a simple codebase with 1 additional language - and simple content that rarely changes - a TMS is likely unnecessary overhead. A developer could manage something like this with any modern LLM.
But string files have a way of growing. The moment you're coordinating translations across multiple codebases, adding languages over time, or involving people beyond a single developer — syncing those files starts competing with product work.
I encourage clients to think of a TMS similar to their Content Management System. You could build a tagging system, a content editor, and a deployment pipeline from scratch. But is that the best use of your developers' time when any off-the-shelf CMS could let them focus on their actual job?
The same applies here. A TMS gives you translation coordination, shared strings across projects, and deployment helpers; all things your devs would otherwise need to build and maintain themselves. It's almost always worth the minimal cost to let devs focus on your product.
How long will it take to support <some language> in our app?
Honestly, supporting your first additional language is hard. But each additional language after that is simpler.
The most important thing to know is that what works for your first translated language might not apply for the next. It's very important to understand which group of languages you want to support long-term, and that determines your scope.
For example, if you don't plan to support Russian then you probably don't need to overthink plurals. If you do need to support Russian then that can have a large impact on your work ahead. Chinese, Japanese, and Korean languages have similar characteristics. Your target languages determine the ideal architecture.
Something else? We offer free 1hr consultation.
The answers above are general. The ones that matter are specific to your codebase, your timelines, and your target languages. We don't take affiliate money from any vendor, and the only thing we have to sell is you walking away with a better localization tech stack.
Because, really. It depends. Let's chat.