Software localisation has changed dramatically. In the 1990s, projects involved millions of words and long timelines for global tech giants. Today, startups ship code continuously, expect localisation to match their agile sprints, and need software localisation partners who understand that poor localisation can block releases.
At Sandberg, we’ve helped some of the world’s largest and fastest-growing tech companies bring their products to new markets. Based on that experience, here are seven key things to consider when selecting a localisation partner for modern software development.
If you’re still deciding which localisation strategy fits your organisation best – whether to centralise, outsource, or mix models – you might find this guide on choosing the right localisation strategy useful before diving into partner selection.
1. 💌 Consistent brand terminology and voice in your UI
Your UI copy – from button labels to error messages – shapes how users experience your software. As your product itself has to do the talking, making sure you get translations that align with your brand is an absolute non-negotiable.
The stakes are high. Research shows that global UX localisation can increase conversion rates by up to 400%, while poor localisation drives away 90% of users after just one negative experience.
Terminology management is the foundation of good software localisation. You need a centralised terminology database that captures your product-specific vocabulary, feature names, technical terms and UI patterns. Your localisation partner should help you build and maintain this database, flagging terms that need decisions, identifying inconsistencies in your source content, and ensuring approved terminology is used consistently by all linguists.
Voice and tone matter even in functional copy. The personality of your product comes through in how you communicate with users. Consider error messages: “Oops! Something went wrong. Let’s try that again” vs “Error: Operation failed. Code 404.” Both communicate the same information but reflect completely different product personalities. Neither is wrong, but whichever voice you choose needs to work consistently across all your supported languages.
Cultural adaptation of UI voice may also be necessary. Your casual, conversational tone in English might need to become more formal in Japanese, where indirect communication is preferred and hierarchy matters. The way people expect to be addressed, the level of formality they anticipate and the directness of communication all vary significantly across markets.
Make sure your software localisation partner can provide guidance on functional copy that maintains your product’s personality while working within technical constraints. You need cultural consultants as much as translators – people who understand not just what your words mean but how they’ll be received. They should be able to advise on microcopy – those button labels, error messages, form instructions and system feedback elements that have the most direct impact on task completion.
2. 🛠 Internationalisation expertise (not just translation)
Before a single word gets translated, your software needs to be internationalisation-ready. Many companies discover this after they’ve already committed to launching in Germany and found that their carefully designed UI buttons cut off half the text because no one planned for the fact that German requires roughly 30% more space than English.
Internationalisation is the technical foundation that makes localisation possible. Your partner should be able to advise you on best practices or at least work effectively within an internationalisation framework you’ve already established. This includes:
- Text expansion and flexible layouts: Some languages need up to 30% more space. Your design system should scale dynamically.
- Character encoding: Proper Unicode support is non-negotiable for accented and special characters.
- Right-to-left (RTL) support: For Arabic or Hebrew, mirrored layouts must still preserve logical flow.
- Date, time and number formatting: Avoid confusion and errors across locales.
- String handling: Eliminate hard-coded text and concatenated strings that break translations.
Ask your potential software localisation partner about their experience with internationalisation QA. Do they flag hard-coded strings? Do they test for text truncation? Can they provide feedback on whether your product is technically ready for localisation, or will they just translate whatever you send them and leave you to discover the problems after deployment?
The best localisation partners maintain a collaborative relationship with your engineering team, providing feedback on technical implementation and catching issues early in your development process. They understand that localisation quality depends as much on engineering decisions as on translation quality.
3. 🤝 Direct linguist contact and integration with your team
Modern software teams increasingly want direct access to the linguists localising their content. That means your linguists must be part of your workflow – using your tools, understanding your product and communicating directly with your designers and developers.
You may prefer to build trust with a small pool of linguists who understand your product, brand and style. For this reason, you’ll often want to allocate named linguists, and you may want to be involved in the process of onboarding new ones, sometimes even offering direct training.
Furthermore, your linguists need to integrate with your development workflow. This means they should be comfortable using GitHub for string file reviews, Jira for issue tracking and Slack or similar tools for real-time communication. They need to understand agile methodologies and sprint cycles.
4. ⛑ Language leads who act as cultural UX consultants
If you’re a more established tech company, you might have your own dedicated localisation department. You may use a mix of suppliers: localising into some languages in-house and outsourcing others. This means you might be experienced in the general process of localisation, but perhaps not in the specific language you’re looking to buy.
Often, though, you’ll have internal language leads – linguists fluent in the target language who act as guardians of terminology, tone, brand voice and style. Language leads are normally heavily involved in your QA process and may be external linguists’ main point of contact.
If you’re a startup, this structure probably doesn’t exist yet. You may want external linguists to step into the language lead role, especially if you’re expanding into a new locale where you have no internal expertise.
As part of that role, lead linguists may be asked to help you develop the style guide for a new locale or provide feedback on an existing style guide. They may also be expected to perform quality checks on work done by other external linguists, analyse support tickets from their region to identify UX issues that your metrics don’t capture, and even conduct user testing with native speakers.
Your language leads should also be involved in planning how your design system works across cultures. They can advise you on typography choices (does your selected font family support the characters you need?), layout adaptations for different reading patterns, and navigation structures that match cultural expectations.
Our software localisation services
We take the linguistic content of your app or service – along with any documentation and marketing material – and translate and adapt it for your target market.
5. 🧑💻 Product expertise and user perspective
Context is everything in software localisation. Translating a button labelled “Submit” requires knowing whether it’s for a form submission, a payment transaction, or content publishing. The same word in your source language may require completely different translations depending on context.
The problem with decontextualised string files is that they strip away all the context that makes accurate translation possible. A list of strings in a spreadsheet or resource file gives the translator no information about where the text appears, what action it triggers, or what the user is trying to accomplish. Screenshots help, but they quickly become outdated as your UI evolves. Access to your actual product – ideally a staging or development environment or string comments that can be externalised in localisation tools – allows linguists to see translations in context and make better decisions.
Your linguists should ideally be subject-matter experts. For financial software, they should understand financial terminology and user expectations in their market. This domain expertise ensures terminology accuracy and helps linguists understand your users’ mental model.
You’ll often want to give linguists access to unreleased versions of your software, meaning an NDA is required. At a minimum, you usually want your linguists to have downloaded and interacted with the release version of your product. This level of product familiarity takes time to develop, which is another reason why consistency in linguist assignment matters.
Making sure you know who your linguists are is key to making this work, so keep this in mind when choosing a supplier. A software localisation partner with high freelancer turnover can’t provide this level of product expertise and cultural insight. You need linguists who grow with your product, accumulating knowledge over months and years, not people who translate your strings once and move on to the next client.
6. ♻️ Continuous localisation and agile integration
Your localisation process these days is much more cyclical than linear. Whereas before, linguists would send a translation and never hear anything back, today there are multiple rounds of quality assurance and feedback before you settle on the final translation.
If you’re operating in a continuous delivery environment, localisation must keep pace with your development sprints. You’re shipping code every two weeks. Your localisation process needs to match that cadence. String freezes, release cycles and sprint-based translation delivery should be clearly defined and respected by both sides. Your software development happens continuously, and localisation needs to be continuous too.
Your Translation Management System (TMS) should integrate with your version control systems. Your software localisation partner should work within tools that connect directly to your GitHub repository, pull new strings automatically, and push completed translations back without manual file shuffling. API integrations between your development environment and the translation workflow reduce your developer time wasted on translation handoffs and context-switching.
Your QA processes need to be systematic across languages, devices and cultural contexts. This means:
- Testing text rendering and layout integrity in every target language
- Checking functional behaviour (buttons work, links connect, forms submit correctly)
- Validating cultural appropriateness of content and imagery
- Performance testing across varying network conditions
- Progressive loading strategies for markets with slower internet connections
- Testing on actual devices used in target markets, not just the latest iPhone
Automated testing catches basic issues like missing translations, broken variables, or formatting problems. But cultural appropriateness and contextual accuracy require human review. Your software localisation partner should employ both automated and manual QA, with clear documentation of what each catches.
Linguistic Quality Assurance (LQA) should follow a documented rubric that defines error severity and categorisation. Critical errors (incorrect meaning, offensive content, broken functionality) versus minor errors (style inconsistencies, punctuation preferences) should be weighted appropriately. Your partner should be able to provide you with LQA scores and track quality trends over time.
7. 📊 Metrics and accountability
A strong localisation partner should care about what truly matters: user outcomes, not just word counts. This means sharing metrics between your teams and looking at the bigger picture of how localisation is impacting your business.
Track task completion rates, error rates and user satisfaction scores across markets to identify where cultural adaptation works and where it needs improvement. If your users in Germany complete your onboarding flow at a 20% lower rate than users in the UK, you have a problem that probably goes beyond translation quality. Something in your user experience doesn’t match German user expectations or cultural norms.
Monitor your support ticket themes by market – patterns often reveal UX issues that quantitative metrics alone don’t capture. If your Spanish-speaking users consistently ask the same questions that English-speaking users never ask, your Spanish translations might be unclear or your UI might not provide enough context in that language.
Your partner should help you understand what good looks like:
- Quality scores
- Terminology consistency rates
- Turnaround times
- Market-specific conversion rates
Companies with properly localised experiences typically see sustained growth rates 2 to 3 times higher than those with poor localisation. Your ROI measurement should account for the long-term value of market entry, not just the immediate translation costs. A market that requires $50,000 in localisation investment but generates $500,000 in annual revenue has delivered 10x ROI. That’s worth measuring and celebrating.
Compare your customer acquisition costs (CAC) across markets. If CAC in Japan is significantly higher than in other markets, poor localisation might be causing high bounce rates and low conversion, requiring more marketing spend to acquire each customer. Good localisation can actually reduce your CAC by improving conversion rates.
Additional considerations for a software localisation partner
These are just a handful of things to bear in mind when searching for a software localisation partner. You might require additional services such as:
Cultural review of text and graphics: This involves making sure your content won’t offend or have negative connotations in a certain market.
Translation environment flexibility: Whether it’s Phrase, Lokalise, Crowdin, or something more specialised, your localisation partner should have experience with it or be willing to learn it quickly.
Design system documentation: If you have a design system, your localisation partner should understand how to work with your component libraries and maintain consistency across localised versions.
Machine translation post-editing (MTPE): For some content types or when speed to market is critical, machine translation with human post-editing can be a cost-effective approach.
The key is finding a partner who can scale with you, starting where you are now and growing as your international presence expands. A partner who only offers one approach (only human translation or only MTPE, only certain tools or only certain languages) will eventually become a constraint rather than an enabler.
Finding the right localisation vendor for your software company
Each project is unique, just as each company is unique. We’ve worked with software companies of all shapes and sizes, from established enterprises to fast-growing startups. The commonality is that everyone needs localisation partners who understand the technical, cultural and operational challenges of modern software development.
The shift from traditional translation to continuous localisation, from linguistic accuracy to cultural adaptation, from isolated translation vendors to integrated team members – these changes reflect how software itself has evolved. Your localisation partner needs to evolve with these changes.
When evaluating potential partners, look for evidence of technical competence, cultural understanding, process maturity and relationship orientation. Understand their QA processes, their tools and their approach to continuous delivery.
Most importantly, look for partners who ask good questions rather than just promising fast turnaround and low prices. The right partner wants to understand your product, your users, your development process and your business goals before proposing a solution. They’re invested in your success, not just in processing your word count.
Interested in talking to us about your localisation set-up? Have any questions that weren’t answered in this post? Get in touch here.
Part of this article was initially published in 2020 by Amy Cottrell, a former Sandberg team member, and has since been edited and revised with up-to-date information and new analysis.
