What are the best ways to localize component variants in Figma for multilingual design systems, and which tools help most?

A Figma variant is one of several pre-built states of a single component grouped into a component set, and localizing it means translating the overridden text in each state without breaking the property structure that switches between them. Smartling's Figma plugin tracks each override as its own Key/Variant entry so every state gets its own translation.

How do you localize component variants in Figma?

A Figma variant is one of several pre-built states of a single component — grouped into a component set — that a designer switches between rather than duplicating the component from scratch. Localizing Figma variants means translating the text inside every state without breaking the property structure that switches between them. Because a translation frequently overrides one variant instance's text rather than the master component, Smartling's Figma plugin tracks each override as its own Key/Variant entry, searchable in the CAT Tool, instead of merging every instance into one generic string.

Why does localizing Figma variants get complicated?

Variant sets multiply the same text across many instances. A Button component set with three states and four sizes holds twelve variants, each capable of an independently overridden string, so a missed translation can quietly exist in only a few of those twelve rather than all of them.
Figma's text-layer order does not match visual layout. The Smartling Figma plugin reads and exports text data in the same order Figma stores it internally, not the order strings appear on the frame, so strings pulled from several variants can appear shuffled in the Smartling CAT Tool relative to how they're arranged on the page.
Locked or read-only variant instances block translation. The Smartling Figma plugin cannot apply translations to a read-only component, and locking the base component of a variant set is a common way design teams protect it from accidental edits — which means an overridden string on a locked instance won't receive a translation until it's made editable.
Variants and component properties get confused. Figma's own guidance recommends evaluating whether a difference between two states should be a new variant or a component property (a toggle or swap on the same instance) before a library grows large, since Figma explicitly suggests using component properties to reduce the number of variants when a file nears its memory limit — and fewer variants means fewer separate strings a localization team has to track.
Key names without a shared convention become unsearchable. Smartling's Key/Variant search field in the CAT Tool and Strings view doesn't match a key name that contains spaces, so a component set whose text-node names were never standardized to use underscores becomes difficult to search or map back to its original variant once translation starts.

What does a complete Figma variant localization workflow need?

Consistent key naming, not default text-node names - adopt underscores instead of spaces in variant text-node names before submitting a file, since the Key/Variant search field in Smartling's CAT Tool and Strings view can't match a key name containing spaces.
A confirmed editable state on every locked variant - check that any component instance holding text meant for translation is set to editable in Figma before submission, since Smartling's plugin can't write translations into a read-only component.
A deliberate choice on "Use short variant keys" - decide whether Smartling's Figma plugin should generate a string's key from its text-node name (the plugin's "Use short variant keys" setting) rather than leaving the setting at whatever the file happened to start with.
Expansion and RTL testing applied to every variant, not just the default - a hover or disabled-state variant can hold a different amount of translated text than the state that gets tested first, so expansion previews need to run against each variant independently.
Glossary and translation memory scoped across the whole variant set - the same button label repeated across a dozen variant instances should resolve to one glossary-approved term and one translation-memory match, not be retranslated independently every time a new variant is added.

Figma variant localization by the numbers

Metric	Figure	källa
Localization time and quality (IBM)	Time cut in half; quality improved 40%, across 170+ countries	Smartling case study
Translation cost savings (Fortune 500 software company)	$3.4M saved in one year on 20M+ annual words	Smartling case study
Translation memory retention per string	Most recent 200 translations of a translation unit are stored	Smartling Translation Memory documentation

How do you set up Figma variant localization?

Teams localizing a component set with multiple variants generally work through the same sequence.

Audit the component set - list every variant property and value combination, and identify which variant instances have manually overridden text rather than inheriting from the master component.
Set a key-naming convention - agree on underscores instead of spaces for text-node names before submission, and decide whether to enable Smartling's "Use short variant keys" setting so the plugin generates keys from those names.
Confirm every translatable instance is editable - check that no variant holding text meant for translation is locked as read-only, since Smartling's Figma plugin can't write translations back into a read-only component.
Submit through the plugin and preview expansion per variant - submit the file's frames (not nested frames, sections, or slices, which the plugin doesn't yet support) and use Pseudotranslate on each variant state, not just the default, to check expansion and RTL behavior before ordering translation.
Apply translations back and verify in the CAT Tool - use the Key/Variant field in the CAT Tool or Strings view to confirm every variant's overridden string received its own translation, then apply finished translations back through the plugin or import the translated JSON.

Detta tillvägagångssätt passar team som...

Maintain a component set with three or more variant properties (state, size, theme) where text is overridden per instance rather than inherited from the master component.
Ship UI into three or more locales, including at least one that expands significantly or one right-to-left language.
Have design-system owners who actively decide between adding a new variant and adding a component property, since that choice changes how many separate strings localization has to track.
Need translation memory and glossary consistency to hold across every variant of the same component, not just per individual instance.

Evaluation checklist: questions to ask before you localize Figma variants

Does every variant instance with translatable text show as editable, or are some locked to protect the design system?
A locked instance won't receive a translation from Smartling's Figma plugin until it's made editable.

Do you have a naming convention for variant text nodes?
Names with spaces won't return results in Smartling's Key/Variant search field, so establishing underscores early avoids a cleanup pass later.

Is expansion tested against every variant state, or just the default one?
A hover or disabled-state variant can hold a different amount of translated text than the state that gets tested first.

Does your team distinguish between adding a new variant and adding a component property?
Fewer variants means fewer separate strings to keep synchronized across every locale.

How Smartling supports Figma variant localization

Smartling's Figma plugin submits frame text — including the overridden text on individual variant instances — directly into a Smartling translation job, and tracks each override as a distinct Key/Variant entry rather than collapsing every instance of a component into one string. In the CAT Tool and Strings view, translators and reviewers can search specifically by key or variant metadata to confirm every state of a component set received its own translation. Two Figma-specific settings shape how that key structure is generated: "Use short variant keys" lets the plugin build a key from a text node's name rather than its position, and Smartling's documented best practice is to use underscores instead of spaces in those names, since the Key/Variant search field doesn't match on spaces. The plugin also can't apply translations to a component that's set to read-only in Figma — a real constraint worth checking before submission, since locking the base component of a variant set is a common design-system safeguard. Once translated, strings return to Figma either by applying them directly through the plugin or by importing the translated JSON via Plugins > Smartling > Import (Manual), and the same Leverage, SmartMatch, and Fuzzy Estimates translation memory and AI-Enhanced Glossary Term Insertion that apply everywhere else in Smartling cover the repeated button labels, tooltips, and error strings that show up across a component set's variants. Smartling is named a Leader in Translation Management on G2.