Continuous Localization – Agile Strategies for Global Growth

Full transcript

Host: Hello everybody, and welcome to today's session, all about unlocking global growth with agile localization strategies, brought to you by Lokalise and the Product-Led Alliance. Please say hi in the chat and let us know where you're tuning in from, and drop any questions for our speakers into the chat as we go.

Eric Silberstein: Pleasure to introduce myself as the first Lokaliser here — I'm Eric Silberstein. Currently a sales engineer, I joined Lokalise two years ago after a stint as a translation project manager and higher education in localization project management. So I'm here with experience in localization and helping our users optimize their localization practices with our tool.

Rebecca Grier: Hi, I'm Rebecca. I'm a UX research manager here at Lokalise. I've been in UX research across many business sectors, in many places, for quite a long time, and I've had the great fortune of living in many different countries. I'm going to be speaking about the why and the how of doing UX research internationally.

Sören von Sebelin: Hello everyone — I'm Sören von Sebelin, tuning in from Hamburg, Germany. I'm a product manager, and I've managed digital products for around fourteen years now across various industries, from games — I'll share a few fun stories there — to SaaS and e-commerce.

Rebecca: developing for everyone — why and how to do international user research

McDonald's is a name everyone knows, and while it's very much an American company, nearly fifty percent of its sales are international — and the menu isn't the same across the globe. How they figure out what goes on the menu where is done by research. One of the main reasons to do user research is a great user experience, and UX has six components: who are your specified users, what are their specified goals, what's their specified context of use, and when accomplishing those goals, how do they define effective, efficient, and satisfying? Understanding where there are commonalities and differences between users is critical to a great experience.

Our brains sense the real world, and those sensations pass through a filter in long-term memory that finds patterns, which are then passed to working memory, where we make decisions and take action. Some of those patterns are universal and biological — the Gestalt principles (symmetry, continuation, proximity, similarity, closure), or math like three plus three equals six. Some are cultural, depending on where and how we were raised — a Berlin TV tower, hurling equipment in Ireland, American football goalposts, a lucky cat in Japan, or a word in Irish, Hindi, or Russian Cyrillic script. And some are individual, based on unique life experience — hard to represent directly, though "expert" patterns (an air-traffic-control display, a chess position, a lab panel, an advanced equation) stand in for how idiosyncratic this category can be.

These cultural patterns can only really be understood through international research — and one of the reasons that matters is that ninety-six percent of research done by companies and academics is conducted with just twelve percent of the world's population, largely from "WEIRD" nations (Western, Educated, Industrialized, Rich, Democratic) — Europe, the US, Canada, New Zealand, Australia — which tend to be more homogeneous and represent a small share of the world's population. International user research can be a real differentiator.

Three areas to consider when doing it: legal and ethical considerations (informed consent, the right to quit without consequence, confidentiality, and being mindful that something normal in one culture — like video recording — may be stressful in another; Europe's legal standards tend to be the strictest, but always check locally), logistics (time zones and travel; session length, since high-context cultures give longer answers, relationship-based cultures need more warm-up time, confrontation-avoidant cultures take longer to give negative feedback, and "flexible time" cultures may mean waiting ten to thirty minutes for a participant to show up; and local hospitality norms, like offering tea before a session in Ireland), and localized moderation (simultaneous interpretation is genuinely hard, so collaborating with a local UX researcher, or an interpreter experienced with UX research specifically, matters — plus awareness of gender norms, such as female researchers getting more open access to women in some contexts, and body-language differences like eye contact, personal space, greetings, and even what a smile or a nose-blow signals in a given culture).

Crossing borders in research isn't simple, but it's how products go global.

Eric: planning for localization and localization strategy

If Rebecca's research tells you which locales to expand into, the next question is how to plan for actually getting into those markets with your product and marketing. One person can't be an expert in every culture's nuances, so the goal is finding the tools and processes that let researchers and localizers succeed as a team.

Users think about images, color, space and direction, and cultural references. On color: the UN recently rebranded its Sustainable Development Goals using color symbolism research to make the colors more globally relevant. Red, for instance, means power, love, danger, or "stop" in Western culture — but in South Africa, red is associated with mourning, as seen at Winnie Mandela's funeral. On space: English text tends to expand the most when the source word count is low, so it's nearly impossible to know in advance exactly how much a short UI string will expand across languages, which matters a lot where screen real estate is tight. On bidirectionality: translating into Hebrew or Arabic (right-to-left) can flip the meaning of a left-to-right image sequence — a classic example being an ad that shows someone tired, then drinking a cola, then energized: read right-to-left, it could look like the opposite story.

No single person can be an expert in all of this — which is where a localizability check comes in: involving localization stakeholders early, during initial project planning or drafts, so they can flag issues with color, imagery, or language before you build. This can come from a language service provider or even multicultural colleagues within your own company.

From there you can build a localization strategy, and everything ultimately comes back to ROI. Start with the lowest-hanging fruit: cultural compatibility (does this content and language make sense for this market — e.g., marketing a plant-based burger patty may land very differently in different US states, let alone countries), resource availability (do you have people or budget to review a given language, and what languages does your language-service provider specialize in), scalability (how many dialects need separate handling, e.g. Latin American Spanish variants), technical considerations (bidirectionality, other character sets, mirrored images), and quality bar (is machine translation acceptable for help docs, or does higher-touch content need human review — legal requirements can force this too, as with Canada's French-English service requirement). Once you know your lowest-hanging-fruit languages, you can prioritize content by tier — from a fully localized, human-reviewed priority-one experience down to a minimum-viable localization, like a multilingual support chatbot, for priority five.

Q (from Charlie): Can you give examples of how continuous localization within agile workflows has accelerated global product launches and enhanced user engagement?
Eric: One of our long-time Lokalise customers, Revolut, started with spreadsheet-based localization and couldn't do simultaneous rollouts — they had to ship English first and add target languages a month later. They've since built a workflow where hundreds of commits a day push strings to their translation management system, with custom logic routing translations by priority to an in-house team or a language service provider. That accelerated their translation volume from under a million words a month to more than a million words at peak, letting them roll out target languages at the same time as their base language.

Sören: lessons learned from managing global products

On delivery: I was responsible for a game launched in more than twenty-five countries within a year while continuously delivering updates, mostly through live events that drove short-term revenue and retention through micropayments. One day after releasing a major event, we got a bug report and thousands of complaints: Arabic-speaking users saw "string not found" in the main event screen; Japanese customers complained the event concept itself was misinterpreted; and conversion in Brazil plummeted. Digging in: we'd released before all translations were ready, and Arabic — usually a longer turnaround — simply hadn't been finished by the localization team, who had no way to flag that back to us in time. In Japan, the event was themed around Valentine's Day gift-giving, but the direction of who gives to whom is reversed compared to how it was framed. In Brazil, key services were still hosted on European servers, causing a performance issue that didn't show up in other regions.

What we changed: we automated translations into a proper translation management system, made sure someone on the team always confirmed translations were in before release, and built in enough lead time for releases rather than rushing them. We also built a community of international users we could directly ask which upcoming concepts resonated (AI can help sanity-check ideas today, but talking to real users in each market is still the gold standard), and we added local performance monitoring so response-time issues by region became visible early.

On discovery: on a separate SaaS product, we shipped a new dashboard that adopted far more slowly than expected, even though QA and performance checks were clean. Digging into the data (which was hard to extract), European markets performed much better than South American ones — it turned out European users valued the customization we'd heavily marketed, while our South American users cared much more about sharing and collaboration features we had built but barely mentioned. Some wording was also misinterpreted based on our tooltips. What we changed: we added in-product, in-context feedback so users could easily flag confusion; we added localized mini-surveys with follow-up questions; we mildly incentivized early feedback with early access to features, which also helped surface early adopters and UX issues; we set up a panel of cultural advisors we shared early concepts and prototypes with directly, before shipping; and we added user properties in our analytics tool (Amplitude, in our case) to make it easier to see adoption by market segment.

On segmentation: don't spread yourself too thin — know who you're targeting and respecting. Useful segmentation lenses include media habits (does this market use YouTube, Spotify, or radio?), culture (values, principles, and mental models — not just obvious things like holidays, but how people read information and hierarchy), seasonality (not just holidays, but school calendars and vacation timing), and regulation (like GDPR, or a law in a specific country that could reshape your roadmap). Once you're live in more than five or so countries, focus stays critical — it's easy to spread attention too thin across markets that aren't strategically core.

Q: What tools or platforms work best for automating localization within agile workflows?
Eric: This is very much Lokalise's wheelhouse — we're built for agile localization. The key question to ask of any tool is whether it's API-first: can you move all your content into a translation management system and back into its source (a CMS or repository) in an automated way? Lokalise has major connectors with most major content sources out of the box, and supports custom connectors where needed.
Sören: I'd add — connect directly into the translation management system via your delivery pipeline (e.g. through merge requests), so translations get pushed the moment they're final rather than mid-development; that's something your developers can own.

Q: What are some best practices for incorporating localization into the backlog and prioritizing it alongside features?
Eric: Localization and translation management work best when centralized — for visibility, and so effort by one team member benefits others. Centralizing lets you build supporting assets (glossary, translation memory) that enforce market-specific terms, formality, and style.
Rebecca: The first step is simply recognizing localization as a problem worth tracking — once it's on a central, measurable radar, you've won half the battle. Getting people to actually prioritize it before a catastrophe forces the issue is harder.
Sören: Awareness often comes from sharing real stories and painful examples — in our case, a costly outage made the case very clearly. Once we had awareness, we baked localization checks into our definition of done, our release-management checklists, and QA, so the happy path was always verified before release, across every product I've worked on with multiple languages. Eventually you can even start automating some of that quality-checking, though today's AI still isn't perfect at, for example, reliably identifying which language it's even looking at.

The session closed with thanks to all three speakers and a reminder that their LinkedIn profiles were shared in the chat for follow-up conversation.