Developers often call localization a bottleneck, a boat anchor, a problem that slows them down and blocks a release.
And they’re right, especially when localization starts only after design and development, when everyone just wants to launch the product.
In September, Joel Sahleen joined Adam Asnes and Olivier Libouban from Lingoport for the webinar From Figma to Dev — A New Approach to Localization to discuss how localization can begin at the design stage and flow naturally into development.
This article highlights the key takeaways from their talk. You can watch the recording below or keep reading.
Speakers
i18n and 10n engineer who has worked at Spotify, Adobe, and Domo, and brings the “real-world” view of development teams.
VP of Product Development at Lingoport who leads the creation of tools like Localyzer and the new Figma to Dev plugin.
Host
Founder & CEO of Lingoport.
A New Approach to Localization: Figma Changes the Game
Figma already changed the way designers and developers collaborate. As Joel put it, it’s now “the equivalent of an IDE for designers,” which means designers and developers no longer work in separate worlds. Designers hand off specs, interactions, and assets directly from Figma.
The result is closer teamwork because Figma captures UI decisions in a way developers can use right away.
Where Does Design Fit in the Development Lifecycle?
In most software projects, design and development happen separately. Designers create prototypes, then pass them to developers. This causes problems because the design does not always match the system’s logic.
What Disconnects Figma from Development?
Figma allows designers and developers to collaborate from the very beginning. While designers plan the layout and user flow, developers can already see the sizes, colors, and behaviors they will later implement.
This approach reduces misunderstandings and helps teams deliver products faster. But there are still challenges, too:
- Limited plugin output. Most Figma plugins only send text out for translation or pseudolocalization but don’t return code-ready files.
- Lost design context. The connection between the visual layout and the code is often broken, because the visual context created in Figma doesn’t appear in the codebase.
- Manual developer work. Developers still have to rebuild keys, formats, and placeholders by hand.
- Higher risk of errors. Copy-paste work and handling plurals or variables often cause mistakes.
Joel Sahleen noted that the gap between Figma and development is where many projects lose efficiency. That is why connecting all the tools is so important.
We at Lingoport are always advocating early internationalization. If you’re curious how it can improve product quality and speed, check out our article How Early i18n Integration Transforms Software Development.
What If Localization Starts at the Design Stage?
When strings are created in Figma and translated early, teams gain three big advantages:
- Writers own the words. “Maybe developers shouldn’t be writing all the strings.” – says Joel. Let content designers and UX writers create text that matches voice and brand from the start.
If content creators understand placeholders, plural rules, and variables, what they write today will “support the code later on.” - Translators see context. Returning translations into Figma lets teams validate meaning in real layouts.
In short, Joel believes that bringing localization into the design stage integrates it with design and aligns it with development.
The Plugin That Turns This Approach Into Reality
Traditional localization is messy: spreadsheets, broken layouts, endless fixes before release. Lingoport’s Localyzer solves these problems. It moves strings between repositories and translation systems, adds context through screenshots, and checks for errors along the way.
The Figma to Dev plugin is part of Localyzer. It moves localization even earlier, to the design stage.
Here’s how it works:
- Select text in Figma. Designers choose UI text such as Register, Next, or Login and send it to Localyzer through the plugin.
- Send it for translation. Localyzer passes the text to a translation system. Each string goes with a screenshot and full context, so translators see exactly where it appears.
- Review it in Figma. When translations return, they appear inside the design. Designers see how each language fits and immediately fix any layout issues.
- Get resource files ready for code. Localyzer creates files in JSON, XML, RESX, Properties, and other formats. They go straight into Git repositories.
When developers add new text, Localyzer picks it up automatically and repeats the same process.
This plugin makes design, development, and localization connected. You can watch the demo in our video below:
Why It Matters
This new approach brings numerous benefits. It gives developers a real head start. Around 80% of UI text can be handled in Figma. The rest, like error messages and runtime variables, appear later in code. Localyzer picks up those changes automatically and lights them up.
Localyzer connects with TMS platforms or machine translation tools, and it validates syntax so developers don’t have to worry about broken code.
This continuous process makes localization part of product development from start to finish: from Figma to code, from prototype to production.
Conclusion
The hardest change isn’t technical. It’s cultural. Localization shouldn’t stay at the end of the product development workflow anymore. It should be part of design and development from the start.
Joel explained it well: “Instead of localization dragging behind, it’s already there at the start. It stops being a problem and becomes part of the solution.”If you’d like to see how Figma to Dev works in action, contact us today to learn more or request a demo of Localyzer.
