To translate Figma text into another language, select a text layer and use Actions → Translate to in supported Figma products, then choose a target language. Figma documents this native AI translation workflow for Design, FigJam, Slides and Sites, with a related AI-tools control in Buzz. For repeatable multilingual design systems, Figma string variables and variable modes can help switch the same text layer between approved language versions.
People searching for how to translate Figma designs, Figma AI translate text, Figma localization plugin or translate Figma prototype need to distinguish generating a draft from delivering a working product. The language may be correct while its button is clipped, the linked prototype action is wrong or a developer receives a broken placeholder.
This guide explains Figma’s documented translation controls, variables and modes, responsive layouts, right-to-left scripts, component copy, multilingual prototypes and quality assurance. It focuses on reader understanding and functional product behaviour, not the appearance of automated translation success.
Quick answer: select text, translate, test the screen
In Figma Design, select an editable text layer and choose Actions → Translate to, where your account supports the feature. Pick the language, examine the result and verify what the text actually asks the user to do. For many screens, set up appropriate string variables or approved localization tooling and review in context. See Figma’s Translate text help and variables and modes guidance.
Fourteen essential rules for Figma translation
How to translate text in Figma Design
Figma’s official Help Center documents a native AI text translation action. Select a text layer in a supported Figma Design file, choose Actions from the toolbar, select Translate to and choose a target language. The same Help article describes text translation in FigJam, Figma Slides and Figma Sites through supported Actions menus, with a different inline AI-tools route in Figma Buzz. Exact feature eligibility, credits and visibility depend on product and plan.
This is a helpful way to preview translated interface copy, but it does not prove every word, component and interaction in a product has been localized. Verify the actual output on the design canvas. Some text may be image pixels, placeholders, strings in shared components or content supplied dynamically by software. Treat each of those as a separate case instead of assuming one selected layer captures the entire experience.
Figma AI text translation is a preview, not a localization release
Figma describes Translate text as a way to preview what UX copy looks like in another language. Previewing is valuable because different scripts and phrase lengths can expose problems in buttons, menus and dialogs before developers implement them. The translation draft should still be checked against its source meaning, industry terminology and product behaviour.
If a translated Save button actually triggers Publish, the interface is unsafe even if the target word sounds natural. A product writer or localization reviewer should connect each visible string to its true action, state and destination. Keep important conditions such as required, optional, not, undo and permanently delete consistent across design, prototype and shipped application.
Use string variables for repeated localized copy
Figma’s variable system includes strings that can be applied to text content, and collections may have different modes for different contexts. The official guide explicitly names switching languages between localized designs as a use case. You can maintain an approved string value for each language mode and apply it to relevant text layers, instead of editing every repeated word independently.
The number of available modes can depend on the plan, so verify your team’s practical setup before promising unlimited language variants. A collection with English, Spanish and Japanese modes can support design review, but the values still need genuine translation and QA. The existence of an alternate variable mode does not prove the copy is natural, legally appropriate or implemented correctly in the final product.
Plan consistent names for translation keys and modes
A repeated button such as Continue can appear in onboarding, checkout and a file-upload wizard, where the verb might require different target-language wording. Don’t force identical translations on different actions simply because the English source is identical. Organize variable names by functional context—such as checkout.confirm_payment versus onboarding.continue—rather than by short source string alone.
Preserve stable translation identifiers where developers or plugins depend on them. A target can change its display words without changing a key that identifies the user action. If a designer renames a shared variable or component without checking dependencies, previews and handoff files may become inconsistent across views.
Build a separate review for each target language
Language reviewers need to see real screen context, not isolated strings in a spreadsheet. Supply screenshots or a Figma prototype containing the relevant action, product state, dynamic values and intended user. A word such as Open could mean opening a menu, opening a file or an order status. The target must preserve that actual function.
Compare several states: the initial screen, any input error, confirmation, empty results and completion. Translate all consequential messages, not just the most visible marketing copy. An elegant home screen cannot compensate for unlocalized privacy consent, checkout requirements or password-recovery warnings.
Auto layout and text expansion need testing
Longer target words can wrap inside a button, force a card to grow or push a navigation label off the edge of a mobile display. Figma auto layout and constraints can help adapt layouts, but they must be configured and checked. Do not shrink every paragraph to an unreadable size to preserve a pixel-for-pixel English composition.
Review at actual phone, tablet and desktop frame sizes as relevant. Test long legitimate user names, currencies, date values and multiple lines of text, not only a short sample. A design can appear fine with one translated sentence and fail when a realistic production string or accessibility text zoom is applied.
Right-to-left scripts involve more than alignment
Arabic and Hebrew versions may need RTL text flow, but they can also contain Latin product names, numbers, URLs and mathematical expressions. Use appropriate script fonts and direction support without reversing literal identifiers. A visual mirror of a navigation layout should not reverse the semantic order of an instructional diagram or graph.
Test the actual user journey with fluent target-language reviewers. Verify icon placement, breadcrumbs, progress steps, focus order and the relation between text labels and controls. A screen that looks balanced can still route users to the wrong action if its localized reading order is inconsistent with the prototype.
Preserve dynamic variables and placeholders
App strings often include a person’s name, account balance, date or quantity. A target-language sentence might need to reorder these values, but the placeholder syntax must stay valid for implementation. Do not translate {user_name} into a different key simply because the phrase resembles English. Mark protected tokens and handoff requirements clearly.
Check zero, one and multiple-count messages, plus maximum valid values. Plural systems differ across languages and can require more than adding an s. The Figma visual preview can demonstrate a few cases, but product engineers must implement and test the actual internationalization rules in the running application.
Keep source design components and variants consistent
A design system can use components and variants for buttons, inputs, navigation and alerts. Changing one localized label should not unintentionally change what variant the component represents. For example, a danger-styled Delete button must not turn into a neutral Archive label; those operations are not equivalent.
Before changing shared components or their string variables, inspect every place they are used. If the component library feeds several product flows, a wording change may propagate widely. A reviewed target-mode library is useful only when its copy maps to the correct behaviour and remains versioned alongside the source design.
Protect numbers, currencies and exact identities
Names of people, companies, software products, dates, order references, version strings and prices are meaningful data. Translation should not replace a real product name with an invented generic word or silently convert SGD into EUR. A designer may prepare a region-specific example, but its numbers and units must be approved separately from language wording.
For screens such as invoices, travel booking and education enrolment, use realistic test values and verify their meaning with the product owner. A frame intended for testing a Japanese layout should not imply the application supports a Japanese bank, payment method or contract term that the actual service does not provide.
Use translation plugins only with authorized permissions
Figma has community plugins and integrations, some of which assist with bulk localization and content syncing. Their capabilities and data practices vary. Before granting a third party access to product designs, review the vendor, security practices, permissions, retention, pricing and supported formats. Do not assume a plugin offers complete or safe localization simply because it can process hundreds of text layers quickly.
Run a trial on synthetic content first. Test whether it handles component instances, string variables, hidden layers, rich text, mixed scripts and prototype labels without destroying links or styling. A tool that translates strings but disconnects them from their design or source keys is not production-ready.
Prototype behaviour matters as much as wording
A prototype screen may be linked to another frame through an interaction such as submit, cancel, retry or delete. Translation of the visible label must not misrepresent where the click goes. A target-language Cancel button that actually deletes the user’s changes is a serious defect. Review the interaction map while reading the target text.
Test the full path from entry to completion in every important language mode. Include at least one error and recovery route and one destructive confirmation flow. Ask a fluent reviewer what they expect each button to do before clicking, then compare that expectation with the prototype’s actual result.
Accessible names and visible copy should agree
A design can have visible labels and separate specifications for screen-reader names, error descriptions or alt text. If the translated visible button says Search but the accessible label says Delete, different users receive contradictory instructions. Keep localized accessible names and labels connected to their true actions.
Where Figma contains only design descriptions rather than actual working accessibility semantics, treat them as specifications for implementation, not proof the shipped product is accessible. Test the real application with appropriate accessibility tooling as part of release QA.
Keep an approved source and language review history
A fast-moving product may change a feature name, pricing structure or permission rule after localized frames are produced. Without version control, reviewers can approve a language edition that contradicts the latest source. Store approved source copy, language mode, reviewer, design version and important changes as a clear record.
Request fresh translation review when any consequential source changes, not just when the design looks different. A corrected privacy warning or refund rule needs to propagate into every authorized target version. Mark stale previews clearly to avoid screenshots of outdated designs being mistaken for the current released product.
Official learning resources: Figma Translate Text · Variable Modes · Apply Text Variables · Website Buttons and UI Translation · Master Art of Translation.
Thirty-six worked Figma localization problems
These fictional examples show how language, visual design, accessibility and application behaviour intersect. A translation is successful when the user experiences the same intended meaning and can perform the same authorized action.
1. A Save button actually publishes
Example: A designer translates the visible English label Save as a target expression meaning Publish, although the prototype only saves a private draft.
Review and fix: The target implies a stronger outcome than the software performs. Look up the component’s real click destination and use a verb appropriate to that transition. Ask a target-language reviewer whether others will see the document afterward; their answer must match the source workflow.
2. Delete and Archive share the same translated word
Example: A dashboard has one action to archive a record and another to permanently delete it. The target labels are identical because both English verbs loosely mean remove.
Review and fix: Users can no longer distinguish a reversible organization step from data destruction. Restore separate terms and test confirmation dialogs, warnings and undo conditions in the actual prototype. Wording must describe the true consequences.
3. A critical modal becomes unreadable in German
Example: A confirm-cancellation dialog has a text box that fits English but clips its final caution after translation into German.
Review and fix: Reflow its auto-layout container, adjust spacing or use an approved concise equivalent without deleting the condition. Check at realistic mobile widths and enlarged text size. A person must see the warning before pressing the destructive button.
4. A default language mode is wrong
Example: A designer creates English and Spanish string-variable modes but leaves Spanish phrases in the English default value for a shared button.
Review and fix: Many screens now show the wrong language despite individual frames looking correct. Inspect the variable collection’s mode values and explicitly test the default and each target mode. A mode switch must not change button behaviour or who receives content.
5. A repeated label has different meanings
Example: The source word Open appears in a menu button, document status and project ticket.
Review and fix: One reused string variable produces an unnatural or misleading target in at least one context. Split identifiers by action or state and provide context-specific translations. The viewer should know whether the control opens a file, shows a menu or reports a status.
6. A string variable is mistaken for a coded status
Example: A Figma status badge displays a translated string while the real application uses stable backend states.
Review and fix: Changing badge prose cannot itself update backend logic. Map each language mode to the same approved state code and test visually distinct pending, complete, failed and blocked statuses. Avoid an apparently green success state for something awaiting review.
7. A product name is translated into a generic noun
Example: A company’s brand name contains a common English word, and a machine translation treats it as ordinary vocabulary.
Review and fix: This obscures identity and can make a prototype appear to advertise a different product. Preserve the officially recognized brand name or authorized localized form, keeping literal product and model codes traceable.
8. A price symbol changes without financial conversion
Example: An English commerce mockup shows SGD 120, while a French layout displays EUR 120 after AI translation.
Review and fix: Currency is not a language synonym. Use a separate verified conversion or keep the original denomination. Check numerical formatting, locale assumptions and actual checkout conditions before a localized mockup becomes marketing evidence.
9. A sign-in action becomes sign-up
Example: The source UI offers a Sign in button for existing accounts, while the target says Create account.
Review and fix: A returning user may expect registration and think their credentials are invalid. Translate identity-management states distinctly and follow the target prototype’s navigation to the correct screen. Test with a fictional existing user and a new registrant.
10. A translated warning loses negation
Example: A login security screen says ‘Do not share this recovery code’ but the target phrase becomes ‘Share this recovery code’.
Review and fix: The new wording directly weakens user security. Mark not, never, only after and unless as protected semantic components in QA. An authorized security reviewer should confirm the target before release.
11. RTL mixed-script text breaks a URL
Example: An Arabic interface includes a Latin support address beside Arabic explanatory text, and the design team manually reverses its character order.
Review and fix: The string may no longer be copyable as a valid destination. Apply suitable direction settings and test the actual value without manual character reversal. A right-to-left presentation should retain technical identifiers and mathematics exactly.
12. A progress indicator reverses the task order
Example: A three-step onboarding prototype labels Account, Verify and Pay. The target designer mirrors all arrows without considering sequence.
Review and fix: Users may believe payment comes before verification. Evaluate reading direction and actual step semantics together rather than automatically mirroring every diagram. A target user should follow the same required order.
13. A component variant maps to the wrong option
Example: An icon button has Danger and Neutral variants. A target string-mode value accidentally triggers a different variant.
Review and fix: The translated label and the visual warning may now disagree, encouraging mistakes. Verify variable-to-variant values and use the correct component for the underlying action. Test in the context of a destructive operation.
14. An accessible name conflicts with visible text
Example: A design specification displays a Search label but an associated accessibility annotation still describes Delete item.
Review and fix: A sighted user and screen-reader user could expect opposite outcomes. Review visible, accessible and tooltip language as one interface contract. The implementation team should test the real shipped app for semantic accessibility.
15. A disabled action sounds available
Example: A button is disabled until verification, but the target help text says verification is complete.
Review and fix: That creates an apparent bug and falsely reports user status. Preserve prerequisites and pending language. Test an unverified and verified account in the prototype and ask readers what must happen before the action is available.
16. A placeholder key is translated
Example: A message template contains `{order_id}` and `{customer_name}`, but a generated translation changes those keys.
Review and fix: The application may fail to insert data or expose literal placeholders. Protect tokens, delimiters and resource keys. Review a target rendering with realistic inserted values, including long surnames and numbers.
17. Plurals are previewed only with one item
Example: A text variable shows ‘1 message’ in a language with complex plural forms, but the designer assumes the same sentence works for every count.
Review and fix: The target may be grammatically wrong or ambiguous for zero, two or other values. Specify proper plural-handling requirements and test representative counts. A static Figma preview does not automatically implement internationalization logic.
18. A long Chinese name overflows a compact card
Example: A screen has been tested only with short example names and a single translated label.
Review and fix: Real user content can be longer in any language, regardless of average script density. Test extreme valid names, multiple lines and right-to-left combinations alongside translated interface copy. Responsive components should expand or truncate according to approved meaning.
19. A form’s required marker disappears
Example: An English signup mockup shows a required email field, but the localized design removes its mandatory explanation to free space.
Review and fix: The target user may believe the field is optional while validation rejects a blank. Preserve requiredness and input instructions. Test empty and malformed examples; error messages should explain the same actual rule.
20. The error message identifies another input
Example: The source highlights a missing postal code. A reusable target error component says Password required.
Review and fix: The user may search for an absent field and remain stuck. Tie error messages to the actual validation rule, not generic source strings. A target reviewer should identify the correct field and correction from the completed screen.
21. A date control has conflicting format guidance
Example: The UI expects YYYY-MM-DD, while translated helper text gives DD/MM/YYYY as an example.
Review and fix: A user following the target instruction may enter a rejected or wrongly interpreted date. Align the helper copy with the actual component and stored date value; review locale formatting separately from translation.
22. A filtered list uses the wrong inequality
Example: A product price filter reads ’50 dollars or less’, but the localized label means ‘less than 50 dollars’.
Review and fix: A product priced exactly 50 is included in one criterion and excluded by the other. Preserve inclusive or exclusive threshold words and test boundary examples against actual filter results.
23. An empty state makes a false universal claim
Example: After filters are applied, the source says ‘No results with your filters’. The target says ‘No such product exists’.
Review and fix: The target turns a narrow query result into a general inventory assertion. Preserve scope and recovery suggestions, such as removing one filter. A user should not abandon a search because a translation widened the claim.
24. A prototype has an unverified link destination
Example: A target link label says French handbook but the click opens an English-only PDF.
Review and fix: Translation of anchor text does not create a new resource. Open the linked file and accurately describe what it contains. If a reviewed French handbook does not exist, the target design must not imply one is available.
25. A payment button becomes a success message
Example: Before payment, the target button reads ‘Payment completed’ rather than Pay now.
Review and fix: The user may leave the checkout believing money has been charged. Keep the action and outcome separate in labels and confirmation states. Check success, failure and pending transactions in the prototype.
26. A map label identifies the wrong branch
Example: A booking interface has two clinics with similar names, and the target mockup replaces a branch label with a different location.
Review and fix: A fluent customer could book the wrong place. Preserve official venue names, addresses and identifiers, and verify the corresponding map pin. Do not choose a place based on a word-level translation guess.
27. A refund policy is made unconditional
Example: A modal states ‘Refund may be available after review’. A target draft says ‘Refund guaranteed’.
Review and fix: The translation invents entitlement and removes review. Preserve may, after and who decides. Any legally consequential wording should be reviewed by the responsible policy owner.
28. The target hides the Cancel route
Example: An expanded target button pushes a secondary Cancel button below the visible device frame.
Review and fix: The user may be unable to back out or recognize an alternative, even though the translation text is correct. Test full-screen navigation and scrolling on target device sizes. Layout should protect meaningful choice.
29. A Figma translation plugin receives excessive access
Example: A designer installs an external plugin for one synthetic prototype but grants it broad access to real unreleased product files.
Review and fix: Language quality cannot compensate for a confidentiality mistake. Review plugin scope, retention and vendor policies, and use a small non-sensitive trial. Do not assume popular plugins are automatically approved for private designs.
30. A variable mode change affects shared designs unexpectedly
Example: A global string collection is updated for Japanese, and a component library used by other teams now shows incorrect strings.
Review and fix: Shared libraries can propagate changes. Establish owner review, named source, target modes and versioned publication; test representative consuming designs before promoting the update to a team library.
31. The prototype’s button and description disagree
Example: One screen says Save changes, while a confirmation dialog says Content has been published.
Review and fix: A target user cannot know whether a private draft remains private. Trace the real action, its data state and the next screen. Correct both related strings as a coordinated workflow.
32. An instructional diagram reverses logic
Example: A FigJam board illustrates three stages connected by arrows; translated labels are inserted in the wrong positions.
Review and fix: The diagram now explains a different process without any obvious spelling error. Verify every target label against stage number, arrow and explanatory note. The target reader should be able to reconstruct the same sequence.
33. A health-themed app design overstates evidence
Example: The source mockup says preliminary feedback suggests possible improvement. The target says the product cures all users.
Review and fix: This is an unsupported medical promise, not an improved tone. Preserve study limitations, uncertainty and audience scope. Use appropriate clinical and regulatory review before shipping or promoting the design.
34. A component label becomes an accessibility barrier
Example: A tab that shows Profile details is translated as Delete profile because the source word is ambiguous out of context.
Review and fix: A user may avoid the tab or misunderstand the consequences. Open the actual prototype state and translate the control’s function; ensure the accessible name and tooltip align with its real destination.
35. A localized screen uses the wrong font for scripts
Example: An English font does not support the full set of Vietnamese accents or some Arabic glyph forms.
Review and fix: Missing diacritics can change meaning or make copy unreadable. Select verified script-compatible fonts and proof the actual rendered exports. Avoid replacing characters with approximations simply to satisfy a visual design.
36. A design looks correct but the app implementation differs
Example: A Figma language-mode prototype shows a translated confirmation label, but developers use a different resource key in production.
Review and fix: Design review alone cannot prove the deployed application behaves correctly. Include resource ID mappings in handoff and test the actual localized build, especially for consent, payment and destructive actions.
Step-by-step multilingual Figma design workflow
1. Inventory the UI strings and their actions
List source screens, text layers, string variables, components, prototypes, error messages, accessibility annotations, legal conditions and exact identifiers. Mark each string with its functional context rather than treating a short word as a standalone document.
2. Decide between one-off preview and managed localization
For a few strings, use supported Figma AI Translate text and review the output. For recurring components and several locales, plan string variables and language modes under the actual account’s capabilities. Consider external plugins only after security and permission review.
3. Translate naturally but preserve state
Check action verbs, person names, prices, count and date formats, negation, approval stages and protected placeholders. Ask product owners to clarify ambiguous source wording before producing a polished target.
4. Run responsive and bidirectional layout tests
Switch each language mode, use target script fonts, and review auto-layout, card resizing, button labels, navigation hierarchy and mixed-script identifiers on realistic device frames. Adjust design rather than dropping essential meaning.
5. Navigate the real prototype
Give a fluent reader a specific task and compare their expected result with the actual connected frames. Include sign-in, a form error, a confirmation and a destructive operation. A fluent label that leads to another action is not correct.
6. Validate the implementation handoff
Preserve stable resource IDs, actual string keys and variable definitions. Verify source and target modes and review the built application with developers where possible. An approved Figma mockup must not be mistaken for a completed production localization.
7. Maintain versions and ownership
Record the authorized source, target language, reviewer, library version, outstanding changes and release date. Recheck target copies when product behaviour, legal conditions or pricing changes. Remove stale language-preview screenshots from current documentation where appropriate.
Frequently asked questions
How do I translate text in Figma?
Select a text layer and use Actions → Translate to in the supported Figma product, then choose a language. Figma’s official help describes this native AI feature, with access dependent on the product and account.
Can Figma translate an entire app automatically?
Do not assume one text-layer action localizes an entire working product. Component copy, visual text, accessibility, dynamic strings and implementation need separate review.
What are Figma string variables for localization?
String variables can control text content, and modes can hold alternate language values. Designers can switch modes to preview consistent localized text in supported plan configurations.
Are Figma language modes available on every plan?
Figma’s variable system is broadly available, but the number of modes per collection depends on the plan. Check your workspace before planning many target languages.
Can Figma AI translate in FigJam or Figma Slides?
Figma’s help describes Translate text in Design, FigJam, Slides, Sites and a related route in Buzz where supported. Check the actual editing environment and feature availability.
Does translation preserve Auto Layout?
The layout structure may remain, but longer target strings can overflow or produce new line breaks. Test responsive frames and adjusted fonts, spacing and components.
How should Arabic or Hebrew designs be handled?
Review RTL direction, mixed Latin IDs, URLs, progress order and fonts. Do not reverse mathematical expressions or protected identifiers merely for visual symmetry.
What should be done about plural forms?
A static preview is insufficient for all counts. Specify and test real plural rules and dynamic placeholder handling in the implemented application.
Can a Figma plugin translate all component text?
Capabilities differ by plugin. Review app access, vendor policy, supported component types and output QA before using any third-party bulk translator.
Does Figma translation also localize alt text and screen-reader labels?
Do not assume so. Visible copy and accessibility specifications require coordinated review and testing in the actual product.
What is the most useful quality test?
A target-language user should predict and complete the same real action, see the same data and maintain the same privacy and safety controls as a source-language user.
Final Figma localization checklist
Check the approved source version, translation tool and plan, every text layer, shared string variable and language mode, component action, prototype destination, required or optional fields, dynamic placeholders, plural behavior, numerical data, currency, legal conditions, error states, font coverage, accessibility labels, right-to-left navigation, privacy, plugin permissions and the final implementation handoff. A native speaker should be able to complete the same real task based only on the translated interface.
Figma translation is a design capability and a product responsibility. Use the native AI controls to create useful drafts, variables to organize repeated multilingual content and functional tests to catch meaning that gets lost in the interface. A good design remains understandable and accurate when the user moves from a screenshot to the actual product.
Official resources: Figma AI Translate Text · Figma Variables and Modes · Locale Modes · Text String Variables · Translate Website UI · Master Art of Translation.
The final user-experience test in the target language
Before a localized interface is approved, give a fluent target-language tester a concrete task in the final prototype: register an account, recover from a form error, examine a price and cancel an action without losing work. Ask what they believe each button will do before they click it, then compare their expectation with the actual connected frame and the source-language flow. Where the translated text predicts a different outcome, fix the copy or interaction rather than insisting the words look natural. Repeat at realistic mobile sizes and with long names or numerals. This test catches clipping, misleading verbs, inaccessible controls and incorrect statuses that a translation spreadsheet cannot reveal.