Beyond one-size-fits-all: personalizing AI for global content

Full transcript

Welcome and introductions

Marta: Hello, everyone, and welcome to our webinar today: Beyond One-Size-Fits-All — Personalizing AI for Global Content. Welcome, everyone, and thank you for coming to the session today. Today we're going to be diving into how you can stop treating AI translation as a generic black box and start using your own data to drive human-level quality. We're moving beyond "good enough" to publish-ready translations.

The agenda is quite straightforward. We'll start with the problem with "good enough" AI, then explain why we think personalized AI is the solution and how that works. We'll see what that looks like inside Lokalise with a live demo and some examples, wrap up with the key takeaways, and leave time for Q&A at the end — so if you have any questions during the webinar, please put them in the Q&A box.

Today I'm joined by two speakers. We have Alesia, a Product Manager at Lokalise. She's been focusing especially on improving translation quality for our AI translations, reducing manual reviews, and accelerating continuous localization. She has a very interesting background: before her product manager role she worked as a Customer Success Manager, guiding enterprise teams on best practices, and she's been in the industry for over five years. That customer-side perspective helps her translate practical requirements into product strategy. We also have Adam, a Senior Lead Product Manager at Lokalise, also on the AI and Machine Learning team. He has a strong background in launching disruptive products in startups and scale-ups with global reach, and he's been at Lokalise for a while now, helping build innovative AI-based solutions that aim to radically transform the localization industry. Without further ado, we'll have Adam start the presentation.

The problem with "good enough" AI

Adam Šoltys: Hello, everyone. My name is Adam, from the AI and Machine Learning team at Lokalise, and I'd like to talk with you about AI translation quality — about generic and custom AI.

Most of the time, GenAI — generic AI — already delivers good translations. A translation that's very likely to be fluent, and often accurate too. But it might not sound like you. There might be the wrong formality, some weird terminology choices, and it can feel inconsistent with your other content — just a little bit out of context. In the end, it might sound like a stranger wrote it: not somebody who is familiar with your brand. Is that good enough? Sometimes, maybe — but probably not all of the time.

The problem with generic, one-size-fits-all AI is that it doesn't know you. It doesn't know your tone or your terminology. It doesn't know your past translations or your overall content, and it doesn't know your business and product context. That's why it sounds like a stranger. The impact is that translations can feel off-brand and inconsistent in voice — and as a result, harder to trust. If you want to improve that trust, you need to invest in expensive human review and in fixing those translations, which somewhat defeats the purpose of using AI translation in the first place. You'd use AI translation to get localization done faster and cheaper, but if you still need humans to review and fix it, it really weakens the case for AI.

And why does AI keep "forgetting" who you are? By default, there is no long-term memory. This isn't like using ChatGPT with memory turned on, where it learns about you individually — if you're doing localization at scale, that doesn't work so easily. When we trigger a translation, the model doesn't know your past history, and it doesn't learn from what it just translated for the next translation. It keeps forgetting. There's no learning curve — every time, it feels like it's translating your content for the first time.

It's like having a new intern who just joined your company. That intern can be a very capable linguist, but they don't know you: they don't know your past translations, your brand, or your terminology at all. So they can only provide generic translations at the beginning, which makes it very inefficient.

Have you experienced this with AI translations — did your translations feel slightly off, like a stranger wrote them? Looking at the poll results: I see that everyone has experienced this, some of us all the time, some of us sometimes. It's a very common problem with AI translation.

Personalization with RAG: how it works

So how can we solve that problem? With personalization. Customizing or personalizing AI is the real solution here, because generic AI translates well — but not like you. Custom AI translates like you. That's the difference.

The way we do personalization at Lokalise is through RAG, or Retrieval-Augmented Generation. What it does is retrieve the most relevant past translation examples and glossary terms, and construct something like a cheat sheet for the AI to make the translation. For every specific translation, the best and most relevant examples from the past, and the most relevant terms from the glossary, are put together in the form of a cheat sheet and provided to the LLM.

Think about it in parallel with the intern I mentioned before. It's still an intern who is very capable in translation — but in this case, for every translation the intern needs to do, you provide them with a perfect cheat sheet: a list of the most relevant past translations showing how you translate, what tone of voice you'd like to use, plus cherry-picked terms from your glossary. Not the whole glossary — just the terms relevant to that particular translation. And you do it every time there is a new translation. It's really like giving a cheat sheet of your brand's perfect answers before any test even begins. That is basically how RAG works.

RAG is one way to personalize AI; the other very effective way is fine-tuning the LLMs. But compared to fine-tuning, RAG is always up to date. If I translate one sentence now, then immediately afterwards, the first sentence can be used as context for the second one. There's no re-training necessary — it's always aware of your past translations, even if they happened a minute ago. And unlike fine-tuning, there's no costly and slow model re-training, while having the same or a very similar impact on translation quality.

The other big advantage of RAG is that it works seamlessly with any mainstream LLM — it works with Claude, with GPT, with Gemini. In our case, we do intelligent routing between different LLMs depending on content type and language. For example, for translations from English to French we might use GPT; from English to German we might use Claude — and in both cases, RAG is used in the same way. If you were fine-tuning, you would need to fine-tune multiple models, which is much more expensive and trickier — and every time there's a new model, which happens every couple of months from each vendor, you'd need to re-train. With RAG, that's not necessary. It's always up to date from every perspective.

Under the hood, from the customer's perspective, the only setup needed is the source text — what you want to translate — plus a Translation Memory (or some translation history with reviewed past translations that can be used as context) and a glossary. The second step is retrieval: Lokalise identifies your most relevant past examples and uses them to augment the prompt to the large language model. That augmentation is the cheat sheet I mentioned. And with that, the LLM generates a highly personalized, human-like translation using all this context.

To put it as a simple comparison: with GenAI, the prompt is essentially "translate this sentence," and that's it. With custom AI powered by RAG, the instruction is much more like "translate this like we would do" — leverage these past translation examples and follow the prescribed terminology. That's the difference between GenAI and custom AI in a nutshell.

A practical example: English to Czech

Let me show you a practical example of how RAG works in practice — a translation from English to Czech. I'm a native Czech speaker, which is why I'm picking this example.

The text to translate is "Pet parents get bonus points." With GenAI, the likely Czech translation renders the word "parents" literally — using the Czech word that literally means "parents" — and adds a qualifying word meaning something like "domestic" or "household" pets, which is normal in Czech. But with the literal translation of "parents," the phrase seems overly enthusiastic. In Czech, it's something a super-enthusiastic person would say to another person — not something you would see in marketing communication. It's still an understandable translation; a native speaker would absolutely understand it.

Now let's look at how it works with custom AI that uses RAG. In this case, the cheat sheet contains retrieved examples from the past. Before the AI does the translation, it sees those past examples — and it sees that the words "pet parents" were previously translated with the Czech word for "owner," not "parent." That's not the literal translation, but it's a more natural, more neutral translation in Czech that works for a wider audience. The past translations also omitted the extra "household" word — not because the generic version was wrong, but because this brand prefers shorter, punchier translations. And what the custom AI produced in the actual translation simply replicated how the brand did it in the past.

So that's the difference: the generic translation isn't horrible — it's not that nobody would understand it — but the custom AI translation sounds like the brand sounded in the past, consistent with all the brand's other translations. That's what custom AI does really, really well, and that's where it beats generic AI.

RAG versus style guides

You might feel you can achieve this with a style guide, because a style guide is also a way to customize. So what's the difference between a style guide and RAG? A style guide is a form of personalization, but it's more of an instruction: "please sound warm," "be informal," "be enthusiastic," things like that. That works, but it's not as effective as giving proven examples through RAG.

With AI, past examples are far superior to a style guide. If you show the AI what a related example from the past looks like, it can pick up the style and terminology very easily and seamlessly, and it usually works much better than an instruction. The style guide tells; RAG shows how it should be done.

Still, a style guide has its place. It's most useful when you don't have enough context from the past — when you're starting to translate into a new language, or you just don't have high-quality past translations. But if you have good examples from the past — and it doesn't need to be many, it can be a couple of hundred per language — RAG will most likely outperform a style guide in translation quality and customization.

The impact: human-level acceptance rates

Why should you think about custom or personalized AI? Because of its impact — it can be really massive for translation quality. What we've seen consistently is that the acceptance rate of translations provided by custom AI — in our case, we call the personalization feature "custom AI profiles" in Lokalise — can reach human level. It can reach the same acceptance rate as professional human or human-reviewed translations. It depends on the customer, content type, and language, but it can be up to 90–95%.

This is not some theoretical number. It comes from guided evaluations with enterprise customers using real content and real workflows, where our customers' own human reviewers and translators evaluated whether the translations provided by custom AI were good enough to be published — whether they accepted them or not. That's where this number comes from.

And this has a tremendous impact on the business case for localization: you can realize up to 97% savings if you reach this acceptance rate. If custom AI provides the same translation quality as your human-reviewed translations would have, the impact on the business case is massive. It depends on the situation, the content, and mostly on the quality of your past translations — the context you can provide. But if you have high-quality past translations, you are able to achieve these numbers. It's really amazing what custom AI can do for localization.

At Lokalise, we use RAG to personalize AI through our custom AI profiles. It's a feature that has been in beta for several months already, and it will be generally available on selected plans from next week. Now I'd like to give the stage to Alesia, and she will show you how it actually looks and works directly in our product.

Live demo: custom AI profiles in Lokalise

Alesia Nikalaichyk: And now it's exciting demo time. This is how the AI profiles page looks. In general, for those of you who aren't familiar, we have two translation agents in Lokalise. We have Standard, which is AI or MT (machine) translation without context. And we have Pro AI, which is advanced AI translation that takes context into account and uses features such as scoring and routing between different LLMs.

Pro AI is already using standard context, such as glossary and style guide, but it doesn't take into account your past translations — the personalization Adam was talking about. By default, you can think of the base profile as your Pro AI, and each profile provides a configuration, a set of rules, for Pro AI. If you want to tweak the rules so that it's not just the glossary and style guide being taken into account, you should look at the custom profiles, which are labeled with the "custom" tag and provide even more customization.

We have a profile based on Translation Memory that's available for activation — it takes examples from Translation Memory so it can add them to the cheat sheet and improve AI quality. If I click "activate," I see three generic steps, which let us set up the rules for AI and choose where the rules should apply, in the form of projects.

The first step is configuring the routing. By default, we recommend all users use the routing, because we know — and we see, based on the data — which model performs best on which type of language and content. Only if, for specific reasons, you're not allowed to use all the models in the pool — this is where you can customize it for yourself.

The next step lets us select which context, in the form of past examples, we send to the AI. This is where we highly encourage people to select high-quality translations only. Instead of sending the entire TM, you can select the languages you're confident in. In this case, I set it up for English, and I can add more languages — basically telling the AI that I'm confident in the quality of my translations from English to Polish and Russian, and this is what I want to send.

You can also think about Translation Memory as a very big asset — a very big database with a lot of content. Some decisions may have been made by reviewers, by humans, some time ago, based on context that was relevant at the time — for example, old branding or an old style the customer required. So we also suggest filtering the Translation Memory by recency, so we provide only the most recent content to the AI and leave out old examples that don't reflect the current tone and style.

In the next step, we select the projects where we want this setting activated. In this case, I'll activate it for my "AI profiles webinar" project, and we'll see the summary: the status of the profile changed to active, and this set of rules applies to a specific project. In all the rest of our projects, we're still using the base AI profile — Pro AI with standard context like glossary and style guide.

Let's look at how it works in practice. I'm opening this project, and in the team settings I can double-check that there is indeed an AI profile applied, with examples being sent for specific languages. We'll try to replicate the example Adam gave with Czech — but as I'm not fluent in Czech and I speak Russian, I'll reproduce it with the nuances of the Russian language.

Let's imagine we're translating the phrase "such a lovely day," and I'll double-check that there was nothing in my Translation Memory at this point in time. I see only generic suggestions from standard AI and MT engines, and I can translate it with Pro AI, which takes context into account. In this case, it translated it literally — "such a lovely day." It sounds fine, but let's say I don't like it: I want our branding to sound slightly different, and I'd rather translate it with a word that is more like "wonderful," not "lovely." We can check that this is now saved in the Translation Memory for future use.

Now let's assume we're translating something similar — "today is such a lovely day" — which shares similar phrasing but starts differently. We ask the AI to translate it, and we see the translation is similar to how we translated it before. Because we saved it to Translation Memory and this example was added to the cheat sheet — that we want "lovely" translated as "wonderful" — the AI replicates this in new translations that aren't exactly the same. That's what personalization means in this case.

Avoiding voice collision between content types

An AI profile based on Translation Memory works really well, especially when the Translation Memory represents one specific style, and when it's clean and recent — for example, when it's used for a single content type, such as product strings. It also works well when there are different Translation Memories for different content styles — one TM in one project for legal, one for marketing. But there are cases where the styles get mixed.

Think about content types that intentionally should sound different: marketing should sound very creative, and legal should sound quite formal. These can get averaged out by the AI if we send a cheat sheet with examples mixed from marketing and legal at the same time.

Look at this example: "Please be advised." It's technically correct English, and fluent, but it sounds like legal boilerplate — it doesn't sound like marketing. Whereas "Don't miss it" sounds like marketing: this is how marketing typically persuades and drives action with users. On the other side, that style looks really weird and inappropriate for legal content — something like "you forgot your bag" — whereas "as required by law" provides the right level of neutrality for the legal style.

So if you see your marketing becoming a little stiff and your legal becoming a little creative — that's exactly the voice-collision problem in a nutshell. The best solution is to use different datasets to provide context for the AI for these two different types of content — which can mean two different Translation Memories, split by type and tone, or using different profiles.

Three data sources for RAG: TM, tagged keys, reviewed keys

The next reasonable question is: how can we split the data if we already have this voice-collision problem and a Translation Memory with a lot of mixed content inside? Here we can think about two kinds of data sources.

The first, which we've just shown, is Translation Memory. You can think of it as a complete archive: it's large, it grows over time, and it often contains a mix of content types, quality levels, and decisions your linguists made at different points in time under different constraints. It's still very useful for consistency, especially when the data is clean and recent. But there are cases where it's possible to do better.

If we picture separate clusters for legal and marketing, we see two subsets of past translations — not the entire Translation Memory, but subsets split by tone of voice: one for marketing content, one for legal. They're much smaller than the TM, because these aren't your entire marketing and legal content — they're smaller sets of deliberately chosen translations that represent the highest quality and the best signal for the AI. This is what we refer to as curated, manually cherry-picked examples, which can be the best quality signal for large language models when translating with AI.

Now, second demo time — how this looks in the product. So far I showed you the Translation Memory profile, but you can also create other types of profiles, with very similar steps except for stage two, where you select a different set of examples as the dataset.

At the first step, you can name the profile — because you create profiles for different purposes and need to identify them — and similarly configure the rules, for example which LLM routing to use. The next step is very similar: selecting the languages you're confident in. But the key difference is here: instead of relying on the entire Translation Memory, we can select a different data source. The first is tags, where you specify the tag name. In the product, it's a small tag that we can label as a high-quality signal for AI, and you can add this tag to more content across your projects and keys. Some of you are probably thinking that's a lot of work — but you can filter and apply it in bulk to files, projects, and content you're confident in: select the content in specific projects using filters and bulk-tag it by clicking "add tag." In this case, the AI forgets about the Translation Memory — it will only look at these tagged keys, and only they will be sent as context to the AI. The next steps are the same: you select the tag and assign it to the project.

There's also a third type of AI profile, where instead of relying on tagged data, you select the reviewed translation status as the data source — the little glasses icon. If you already have an established human review process, where people check translations and mark them as reviewed, then essentially we'll look only at the translations marked as reviewed. We'll again forget about the Translation Memory and completely ignore tagged keys. On top of this, we can filter by projects: we can say we don't want just any reviewed translation — we want reviewed translations only from a specific project, for example our marketing content project where we think the quality is best. We're collecting the examples in this project that the AI can use, and assigning them to another set of projects — essentially saying we want to use our high-quality marketing data whenever we're translating any marketing content, because any marketing content can benefit from that set of high-quality examples.

To sum it up: depending on the use case, we have three different types of RAG data source. The first, Translation Memory, works when your TM is clean and recent and represents a single tone of voice — the benefit is that it's instantly available, so you don't need to manually select data or apply tags. Tagged keys can be a really good approach when you need a cleaner, trusted dataset — for example, when you don't trust the Translation Memory or you don't know which examples in it are good; this is where you create a curated set of examples and can split content by tone of voice. And reviewed keys are similar to tagged keys, but really powerful when you already have an established review process, because you don't need any extra effort for tagging.

RAG is very fast at leveraging new examples — the effect is similar to learning and unlearning. Depending on the data source: if you use TM, then whenever a new translation gets saved to the TM — or with reviewed status, whenever new translations get reviewed, or with tags, whenever they get tagged — that's exactly when those examples get added to the cheat sheet and start being served to the AI. It works the other way around too: if you try AI profiles and the quality is still not there, it's likely something is confusing the AI, and as soon as you remove those bad examples, the output can start improving. The third power of RAG is that it's very selective — it uses only the most relevant past examples in the cheat sheet.

But there's always a "but": you need to be really careful to send the right type of examples. If you send bad examples — obsolete copy, old terminology, old branding — the AI can think that's the customization you want. It will make the output sound like you — but like the past you, not the most recent you.

Customer feedback and key takeaways

Here's what our customers are saying. One customer said it's really sustainable and scalable, because it runs automatically under the hood and provides personalized translations. Another customer mentioned that the impact is as if the model is learning from new examples, and that over time it gets closer to their preferred style. And another user said that AI profiles and RAG really calmed down a lot of the issues they'd been having with AI — meaning that over time, AI translations started to improve: once people made corrections and saved content to the TM, the AI accepted the changes and started reproducing the correct format in similar cases. This is exactly like the example with "lovely" and "wonderful": as soon as I added my preference, the AI started to reproduce it.

I want to leave you with three key takeaways. First: generic AI might not always be enough for production translations — not because the capabilities aren't there. It can still translate fluently, but it may just not sound like you, and because that personalization is missing, people need to make edits and rework, which damages the reputation of AI overall.

Second: the answer is personalization, which drives quality — sending your own data and your own examples is what often makes AI output close to human work, or almost indistinguishable from it. With a very important caveat: the translation examples and context need to be recent and good.

Third: the impact is actually measurable with custom AI powered by RAG. It's not just a sentiment that it "feels better" — it's something we validated with actual customers on their own data, as Adam mentioned, and it has the potential to achieve up to 95% publish-ready content. On this note, I'd like to hand over to Marta to get you up to speed on past webinars, and then we can move to Q&A.

Related webinars

Marta: Thank you, Alesia, and thank you, Adam, as well. Before we move into Q&A, a small promo: we've had some other webinars you might find interesting, because they relate to this topic. In autumn last year, Alesia hosted a webinar about translation quality, quantified — we have a feature inside Lokalise called translation scoring, and she covered why translation QA and scoring are important. Earlier in autumn we also had a webinar with Sasho, one of our engineering managers at Lokalise, covering custom AI as well — in particular, a deep dive comparing RAG and fine-tuning models, which is another way to customize AI. If you haven't attended, I'd advise watching them on demand.

Now let's move on to the Q&A section. We have some questions that have been coming in — thank you very much for that. If we don't answer your question live, we'll send the answer to you via email, along with the recording of this webinar.

Q&A

Q: How can I add context about the short-term rental industry to Lokalise, so I can get AI translations relevant to the STR industry and each specific market?
Adam: You can enter it into a style guide — if you don't have past translations to reflect it, add a brief description there. More powerful: if there is terminology specific to your industry, add it to the glossary. And the most powerful option: if you have past translations that reflect the language of the industry and the market — the way you want to sound — and you have them in Lokalise, use them for a custom AI profile, either via Translation Memory or tagged translations. That's the most powerful way to ensure custom AI uses the right language.

Q: How does RAG differ from translation units in a TM? Can custom AI leverage a TM?
Adam: Yes. The TM is just one of the data sources that examples can be retrieved from. RAG is more of a method: it retrieves examples from the TM (or another source), augments the prompt, and lets the LLM generate translations taking them into account.

Q: Is this RAG workflow customizable per specific customer based on their source material, or built to work with a specific type of source material? What prep needs to be done to use it most effectively?
Alesia: It's personalized for every customer, because it takes your specific translation examples — from your specific Translation Memory or your tagged example keys — and sends them to the AI. So it will sound as close to you as possible, compared to cases where content is translated in a generalized way, trained on the overall industry domain, because it takes your own examples into account.

Q: Does a RAG-based LLM still use glossaries, style guides, and visual/textual context as well?
Adam: It still uses the glossary and key descriptions, and it can use style guides. But if there are relevant past examples that RAG can retrieve, we don't use the style guide — examples are more powerful than a style guide, and having both can be confusing, since they might contradict each other, which is actually very common. If there are no relevant past examples, the style guide is still applied. So all these extra sources of context are still used.

Q: Context is important, as we know. The problem we encountered with RAG is that at times even the most relevant segments RAG retrieves are not really relevant to the current translation. How do you make sure the reference provided to the LLM is good enough?
Adam: This is a common problem, and there are two important parts. One is to make sure the source for RAG is set up right — don't set up the same RAG source for all types of content. If you're translating UI content, the source should contain only translations related to the UI, so it doesn't mix with, say, your marketing content. That separation is important: different custom AI profiles with different sources per content type. The second part is how the retrieval itself works — we are constantly improving this. There's quite a bit of matching in that algorithm, and we keep developing it to retrieve the most relevant translations. That said, "relevant" doesn't necessarily mean sharing the same keywords: even examples that don't look similar can still be relevant, because they show your style and brand voice, and LLMs are powerful at inferring the type of language you want from different kinds of translations. It can happen at scale that RAG doesn't retrieve a very relevant example — but even something seemingly less relevant can really help the LLM understand what your style should be.

Q: What are acceptance rates based on, and what quality evaluation do you use?
Adam: The way we calculate acceptance rates — both in our product and in guided evaluations — is that we present an AI translation or a human translation, and "accepted" means the reviewer or user accepted it, used it in their product, or published it without making any change. They took it, deemed it publish-ready, and didn't change a single character. If they rejected a translation, or used it but changed it, we consider that a rejection — it doesn't count towards acceptance. So when we say 90% of translations are accepted, it means nine out of ten translations the user looked at were used and made publish-ready without any changes. That's the methodology behind our acceptance rate.

Q: What if your Translation Memory is mostly based on non-human-checked AI translations? In our company, only the Dutch translations have been somewhat edited by the copywriter before me, so the memory is not a super reliable source.
Alesia: This is exactly where the other types of RAG — tagging specific keys or marking translations as reviewed — are very helpful for addressing this so-called cold-start problem, where there's no good context for the AI. If most of your translations were AI-generated, the AI has probably already picked the terms it considers most relevant for your domain — so sending it examples of unchecked, unedited AI translations gives the LLM no new context. What we suggest is to organize a human review process for at least 500 segments — you can appoint external linguists, or use services from Lokalise — to create a starter set where you invest in personalization and people check the translations. Then you can reuse that same set of human-verified translations for all your subsequent AI translations, which improves the output even for future AI translations that never go through human review.

Q: I worry that all translations would need human-based localization first, like in the Czech example. We don't have the capacity at the moment for locals to check all the languages.
Adam: It's not about checking all the content in all the languages. For RAG to work, you need a solid basis — for example, 500 examples per language to start. That's already going to be powerful, even if it's just 500 translations. More is better, but even 500 will definitely make a difference. So you can approach it this way: establish that basis in each language you provide — do the first 500 human-reviewed translations — and then custom AI with RAG can scale it to the next million, much faster and much cheaper, scaling the quality of those 500. And if you don't have the capacity, Lokalise is super happy to assist — for our partners, we can help with setting up that basis.

Q: Can I set the start date of the Translation Memory that is used for every language individually?
Alesia: At this point, no, it's not possible. You either need to define one date you're comfortable with for all the languages you're sending examples for, or you can work with the other types of RAG. But this is something we're aware of — we'll look into this feedback going forward in more detail.

Marta: We don't have time for more questions today. If there was a question that wasn't answered, we'll get back to you over email — and remember that you'll get the recording of the session. So thank you, Alesia, thank you, Adam, and thank you everyone for joining the webinar today. See you next time!