Maximizing Productivity in Localization: The Ultimate Key Management Tool

Discovery of Localization Keys

As you might have read in the introduction, today we are going to talk about localization keys and their importance. You may be wondering, why this topic? Let me explain.

I only discovered localization keys’ importance recently through my co-founder, who was working as a PM at Lydia at the time. He's now our CTO, and he's the one who really opened my eyes to this whole world of website translation.

For the ones that might have skipped an episode, quick background: Localization is what makes websites available in multiple languages. When you see a language selector on a website (not the Google Translate popup, but proper translations), it means teams have worked hard to translate and culturally adapt the content. That last part is super important - what makes perfect sense in France might sound odd or even meaningless in England, especially when it comes to wordplay. That's why localizing a product isn't as straightforward as it might seem, and we've covered this in several articles before.

What really surprised me was how challenging the whole localization process is, both from a copywriting and technical perspective. Good copy can make or break a business, so getting the words right is crucial. But even the technical side of managing all these translations is surprisingly complex.

So how does it work technically? When localizing a product, developers stop hardcoding sentences and words directly in the code. Instead, every piece of text that users might see gets replaced with a unique identifier - a localization key. Let me walk you through this process and show you how it all comes together...

What is the concept of this key?

Localization (or l10n for the tech-savvy) is more than just translation - it's about making content feel native to each region. Think translations, images, and cultural elements all working together to make your content feel like it was originally created for that specific audience.

In development, localization keys are unique identifiers for every piece of text in your user interface. Here's the interesting part: when a product is properly localized, you won't find actual text in the code. Instead, developers use these keys, which act like bridges connecting different translations of the same content.

Let me break this down with a simple example: imagine a landing page with a 'Get started' button. Instead of writing 'Get started' directly in the code, developers use a localization key. This key might link to 'Get started' in English and 'Commencer' in French (though the actual French translation would depend on the specific context).

Here's where it gets tricky. When developers need to add text, they face two choices:

1. Reuse an existing key if the same phrase appears elsewhere
2. Create a new key if they need something unique or want to manage this text separately

Creating these keys is surprisingly challenging. Developers need to make sure each key is:

• Unique across the entire product
• Meaningful to the whole team (translators, PMs, designers)
• Properly organized to avoid duplication
• Clear about its context and usage

When you see a 'Start for free' button on a landing page, it might look simple, but there's some interesting tech behind it. Before localization, developers would just hardcode it like this: 'Start for free'. Pretty straightforward, right?

But when it's time to localize the product, things get more interesting. Developers replace that hardcoded text with something called a translation function (usually abbreviated as 't') and a specific key. When the code is compiled, it creates different versions for each language the product supports.

Let me show you how this works with a simple diagram:

The translation function does a simple but powerful job during code compilation. It looks up each key's value across different languages (values that PM, translators, or UX writers have defined) and replaces the key with the right translation. Here's how it looks in English:

Let's walk through how localization keys fit into the product development process:

1. Designers create mockups in Figma, writing all content in the company's default language (usually English).
2. These mockups go through a review process before reaching the development team.
3. During development, every text element needs to be replaced with the appropriate localization key. From a developer's perspective, they see the Figma design like this:

That's how it should work in theory. But in reality, developers only have access to the left part. They need to manually create the right side, coming up with each localization key from scratch. As you can imagine, this manual process takes a lot of time and is prone to errors and typos.

Depending on the type of company, the use of localization keys is not necessarily the same. Some companies use specific keys for variant texts more frequently, like often in B2C businesses, where the goal is to optimize rapid user conversion. This leads to more A/B testing and therefore more key changes. Other companies reuse keys in various contexts. This practice is more common in B2B companies that focus on a specific industry and sometimes on words that need to align with legal contexts. Once a word is associated with a key, fewer changes are made.

The "Pain Points" for Developers

For developers, managing keys represents a major challenge. The manual creation of keys is a time-consuming task, especially in complex projects. Additionally, conflicts can arise when two developers create similar or contradictory keys, leading to errors. Finally, it is often difficult to find an existing key, which leads developers to waste time checking its existence or creating a new one.

The "Pain Points" for Designers

Designers face several challenges related to key management. They often lack visibility into key associations, which requires checking in Figma. Errors can occur if keys are incorrectly associated or modified, creating inconsistencies in the design. Additionally, key management slows down the process, as it is usually the developers who generate the keys. Finally, when a designer wants to modify text or an element, they must identify where the key is used, which can be difficult.

What we’re aiming to

Now that you understand localization keys, see where I'm going with this?

We're building a tool that eliminates all these friction points around key management. No more hunting for the right key, dealing with typos, or waiting on back-and-forth communications. We're integrating directly with Figma because, let's face it, localization should happen where the design does.

Our solution makes things simple:

• Everything in One Place: Keys are right there in Figma, where both designers and developers can see them.
• Designer Empowerment: Designers can check and modify elements without depending on developers.
• Major Time Savings: Developers spend less time on manual tasks and more time building features.

The tool automates key finding and creation, tracks translation progress, and shows what still needs work. It turns key management into something that just flows naturally with your team's workflow, making everyone more productive.

Keys are key

While we can't change how localization works technically right now, there's huge room to improve the current process. Moving localization directly into the design phase will make everything faster and more reliable.Want to understand the scale of this? Take Lydia - they manage around 25,000 keys. That's 25,000 pieces of text that need to be found when editing designs, created when missing, and kept consistent. With numbers like that, you end up with loads of duplicate and outdated keys that keep getting edited and translated because no one's sure if they're still being used or not...But that's another challenge we'll tackle later!

‍