Ace the delivery narrative; improve your go-to-market speed by 2.5x
Here’s what we’re covering in this chapter:
How can you improve your release speed by 2.5x? Localize faster, and localize smarter.
Automating more of your localization workflow.Here’s a model of how greater automation can work.
How to categorize and split your deliverables. We’ll talk about how to devise different playbooks per stream and begin to split them.
In our recent interview series, we talked with Pleo about how it had improved its go-to-market time on localization changes. The European business expenses app had a bumper globalization year in 2022, and had launched in 10 new markets, bringing their total to 15. “It was one market per month, sometimes two.”
Over the year, Diana had improved the app’s go-to-market speed by 2.5x.
“The first market took us seven weeks, and then the last one took us three,” said Diana. It’s 2023 and the team are starting to build out a deeper localization maturity and focus on a deeper rapport with users.
There’s plenty of advice you can follow to improve your speed-to-market.
From the interview: Watch Diana talk about hypergrowth vs sustainable growth
1. Ensure you invest in core materials
When it comes to a localization delivery pipeline, every time you redouble your efforts, you are wasting time.
When we asked Diana the main way Pleo improved its go-to-market speed, here’s what she said:
Having “a ready playbook, a core asset list, and all the dedicated resources frontloaded… having glossaries and style guides prepared.”
Natalia, the Terminology Manager @ Google, used to work for a major LSP. We asked her what she’d advise about LSP engagement and she said:
“The one thing I would see recurrently is the assumption that a localization services provider is going to know everything without actually getting any information from the client. There’s an expectation… that a linguist would know what they’re going to encounter, how to translate it.”
Lots of that can come from core materials. “Style guide, glossary, identification of content types, formats, context, audience type,’ listed Natalia. “That’s usually one of the biggest mistakes I’d encourage everyone to invest time on.”
What is the nature of the l10n you undertake in different circumstances?
📝 Core asset list
What assets do you need to launch somewhere new? How far is each market localized?
What key terms do you have? How are they translated?
Who are we talking to? What’s the audience here?
What are the contexts and formats for the different types of content? Where and how are users digesting it?
What are your brand guidelines around things like tone of voice?
2. Playbooks should be a different asset stream
In HubSpot in 2013, they began to separate the marketing and product asset streams within localization.
Robert, Product Program Manager @ HubSpot described the split:
“As we got the product internationalized, we could stay fairly close because we were operating at a really small scale. That made it easier to keep the quality tight… over time, we needed to ramp up the volume of content we were pumping into these markets.”
In time, marketing and product content split their workflows and their processes. “The needs of scale began to separate us… and then also the quality requirements started to change in your product.”
“Public-facing marketing content needs to be polished to the max” whereas with the product content, they found they were better able to use automated tools to generate some of the content.
Teams and stream pods
In Pinterest, there are also team divisions to help them handle different requirements of these streams.
“One pod works on product internationalization” said Francesca, the Head of Internationalization & Design Program Management there. “Which means international product UI strings… We do functional and linguistic QA on our core product and features. We internationalize the UI, the iconography if needed, taxonomy, and so forth.”
“I have a team working on Pinterest scaled platforms. So they translate, internationalize the Pinterest websites. That includes the Business Site, the Help Centre, educational platforms, and seasonal websites.
Different depths per country
With the exception of Slack, all of the businesses moderated the level of localization they provided depending on the country.
Robert @ HubSpot explained: “With Japanese, you have to have somebody who is ingrained in Japanese culture and language to have an app which is perceived as high quality. You don’t necessarily need someone in Finnish. We don’t have an internal Swedish speaker, but we offer a Swedish UI.”
3. Your product localization playbook should be automated as much as possible
Agile delivery + machine learning
There is less of a distinction between content and software than there once was.
CI/CD stands for “Continuous Integration / Continuous Delivery” (sometimes, “Continuous Deployment”). There are lots of articles which describe in more detail what CI/CD means, but it refers to a framework for how teams should plan and release code, with emphasis on speed, accuracy, and automation in deployment.
Whether or not you choose machine translation, machine learning is a must for this kind of content.
Robert, Product Program Manager @ HubSpot argues: “add machine learning as soon as you can. There are so many tools and this was ten years ago – the landscape wasn’t as robust as it is now. Add machine learning and automation to your process, because you can leverage so much of the work you’ve done in the past to ensure quality with speed in the future.”
More automation in product localization
Back in 2013, HubSpot’s experiments with machine translation were “slightly below the quality we were shooting for” – but machine translation is improving, and the guide is being written in Q2 2023, following the breakthrough in LLM technologies pioneered by OpenAI with ChatGPT.
Robert explained the Babel system which Hubspot used for machine translation. Babel simultaneously provides a machine translation offer which is live for the customer and routes the translation to a third party translation vendor for QA.
“Babel allows us to get code to translation and get it back within minutes for the machine translation layover. And it very rarely takes more than 24 hours to get a solid human translator on the string. The engineer or dev doesn’t even see it happen, he or she just sees the code come in, and they pull it into their repository.”
Pleo aims to automate away the function as much as possible.
‘If you ask the engineers’, said Diana, Localization Content Manager @ Pleo, everything will be automated, and there will be no longer need for us. So that's kind of the end-goal for engineering.’
4. Is it a project? Think carefully about scope
Many of the professionals I spoke to referred to a lack of time or a high-paced environment as a factor.
“It’s tech, so everything was supposed to be done yesterday” said Francesca, Head of Internationalization @ Pinterest. In our forthcoming report based on a survey of localization professionals, we’ll show that there is broad agreement that pressure on the speed of release has an impact on quality of localized changes.
All of the interviewees without exception referred to scale and the difficulties of scaling their process.
“You can definitely get to a level with too much complexity,” argued Iggy, Localization Manager @ Deliveroo. “We have this concept of globalization – your user experience should in theory be the same in every language we offer.”
Diana had come to the conclusion that localizing fewer things, to a higher standard, is better. ‘I prioritized an MVP of localization based on what we had produced. So the apps, the website, the most popular landing pages, the most popular help center articles,’ she said.
Split your asset streams by longevity and price to produce, and begin to attempt to reduce the scope of things which can’t scale.
Depends on asset
Machine translated & checked
Built from scratch
5. You’re going to need LSPs, so manage the relationship carefully
Natalia, Terminology Manager @ Google and former Director of Quality at an LSP, argued LSP use is “an absolute need. If localization is not your core business it’s too hard.” (She added that this was not true of Google, arguing it was a special case.)
“If you really want to produce large amounts of content in all the languages, it’s going to be very difficult to sustain that internally. So you need to really understand what your resources are.”
“To make the most out of those resources, which might not be having [an LSP] localizing content, but thinking of how the shape of that market is going to look in a language.”
More than one interviewee argued that long-term engagement with an LSP was preferable if possible.
“We got really tight with a [translation] vendor,” said Robert, Product Program Manager @ HubSpot. “That part of the quality process we took on early was finding a good vendor and sticking with them.” Robert argued that a better depth of knowledge on their part improved the quality of their work.
(Diana from Pleo didn’t like the idea of suppliers marking their own homework. Instead, she used in-house checkers to check every word they translated rather than get another LSP involved. We have our own ideas about quality checking here – see below!)
6. Make requests easier, not harder
Many l10n pipelines are dominated by requests from other departments.
A common failure mode in any business is for a service department to keep on top of their requests by making it extremely difficult to request things from them. The best performing localization teams made it easier to request localized changes to features or translations of their content.
It was true of our interviewees:
Slack automated the localization request system within the Slack app, so requesters didn’t have to leave their channel.
Pleo made it possible to tag a feature or piece of content for l10n in Github and to automate the delivery flow to and from the development environment.
HubSpot used the Babel system described in detail above.
Robert, Product Program Manager @ HubSpot argued: “If you start to scale, and there’s long times between questions getting asked and answered, trust gets diminished. At that point, you start to incur debt, because you have problems that are going unsolved.”
7. Continuous localization quality assurance should be elastic, and be more than translation
Quality controls are essential in localization, especially if you are looking at routing more of your localized content through fast, automated or even machine translated systems.
A free localization leadership webinar by Global App Testing featuring industry leaders from some of the world’s biggest brands.
Where you’re delivering localization quickly, you should consider elastic LQA.
Elastic LQA is an approach to LQA which emphasizes availability of QA supply, thus reducing the friction for a buyer who needs to access that supply. In the case of Global App Testing that means “crowdtesting”, where a large group of users and testers are available to review different software products, sites, and assets, in 190 countries and territories.
Because that pool contains 90,000 people, there are LQA experts available in any one of those countries and it means we can guarantee review of a localized asset or feature within 48 hours.
LQA, Localized QA, Translation QA
Some nomenclature, quickly.
“Localized QA” refers to functional QA in a specified local environment, and is great for engineering-focused teams to do things like compatibility testing, and ensuring that your software still works in general as expected in a local environment.
LQA, or “localization QA” (we don’t use “language QA”) refers to the process of checking localized changes outlined below.
Why not language QA? Well, many early-stage localization attempts are focused exclusively on translation. And whether you’re translation-first or not, it is not worthwhile to limit LQA solely to translation checks.
In our view as a localization QA vendor, translations create the following risks:
Translations have a habit of ruining the design of things. “Overlong or truncated strings” are strings of text which extend beyond the bounds, or are cut off at the bounds, of their respective boxes. But these are just two examples – your site or product design is likely to be impacted by translation in various ways, generally to do with text spacing.
Cultural issues & mistakes
The immediate way that businesses understand cultural checks is to do with sentiment risks, for example, images which are considered explicit in some cultures creeping into multimedia. But things like assumptions made during onboarding can be just as important. “Required” last names, address formats, will all lead to customer dropoffs during forms.
Although it is not (usually) the job of a localization manager to chase up your engineers, a QA bug can have a bearing on the measurements above. In particular, integrations and access. Local banking and checkout partners are one of the most common reservoirs of functional bugs.
When you are looking at localization as a commodity, then you want QA which is fast, thorough, and cost-effective. That’s where Global App Testing can help you, and we’re only an email away.
Key takeaways from Chapter 2
Ready your core materials ASAP
Get all of the core materials in a centralized place; this will make strategic governance easier as well as improving your localization speed
Divide your delivery streams
Identify “commodity” localization and work as hard as you can to automate that, including by experimenting with machine translation tooling
Choose elastic LQA
Get QA which is flexible and demand-oriented, instead of relying on a supplier used to walking slowly in waterfall
Calculate your costs
Our next chapter will be about getting to the investment narrative; for which you need to understand your costs