There is a class of translation problems that does not originate in code. It originates in Figma. Designers write text in components -- button labels, empty states, modal headings, tooltip copy, notification messages -- and that text needs to be translated. The problem is that in most product organizations, nobody is treating it as a string.
It is not in the i18n file. It is not in the TMS. It is not in the PR. It lives in a component layer in a design system, visible only to people with Figma access, until a frontend engineer renders the component and hard-codes the English text because there is no translation key for it yet.
How Design Text Escapes the Localization Pipeline
The pipeline failure is a handoff problem. Engineers know how to add a key to a locale file and call `t('key.name')` in code. They do that for feature-specific strings because the feature spec includes the strings and the engineering task includes adding them to the i18n file.
Design system components are different. They are built once, used repeatedly, and their text is usually written by a designer in the component itself. When an engineer implements a component from the design system, they are following a specification. If the spec shows text rendered directly in the component, they render the text directly. The translation pipeline is never consulted because there is no explicit handoff step that says "this text needs a translation key."
The result: your design system ships with hard-coded English strings in reusable components. Every product surface that uses those components gets the hard-coded English. Six months into your localization project, someone discovers that the empty state that shows up across fourteen screens says "Nothing here yet." in English for all users, because nobody ever added a translation key for it.
Which Figma Text Is a String
Not all text in Figma needs a translation key. Design tokens, annotations, labels on artboards, component documentation -- these are design artifacts, not product copy. The test: if this text will be visible to end users in the shipped product, it is a string and needs a translation key.
Specifically, the text layers that consistently escape the localization pipeline:
- Button labels in design system components (not feature-specific instances -- the base component)
- Empty state copy: "No results found," "Get started," "Nothing to see here"
- Error state copy in reusable UI components (form validation messages, network error overlays)
- Placeholder text in input components: "Search...", "Enter your email"
- Tooltip and help text in UI components
- Notification and toast messages in alert components
- Navigation labels in nav components if they are rendered as text rather than filled by a content model
The distinguishing factor: text that lives in a reusable component rather than a feature-specific screen or content block. Feature text usually gets tracked. Component text usually does not.
The Fix: Annotating Strings in the Design System
The localization-ready design system convention is to annotate every text layer in a component that needs a translation key with the key name, either in the layer name or a Figma component property. This annotation is not visible to end users -- it is metadata for the engineering handoff.
A practical convention: prefix text layer names that represent translatable strings with `[t:key.name]`. So a button component's label layer becomes `[t:button.label]`, an empty state heading becomes `[t:empty.heading]`, and so on. When an engineer implements the component, the layer name tells them: this text needs `t('button.label')` not a hard-coded string.
This convention requires discipline from both designers and engineers. Designers need to add the annotation when they write text in a component. Engineers need to look for the annotation and add the key to the locale file if it does not exist. Neither step is difficult; the problem is that without an explicit convention, neither step happens.
Design Tokens vs. Translation Keys
Teams that use design tokens sometimes conflate design token management with translation key management. They are different systems solving different problems.
Design tokens define visual properties: colors, spacing, typography. They are consumed by the design system and by code. Translation keys define content: the words rendered to users. They are consumed by the i18n layer in code. A component can use both: a button has a background color (design token) and a label text (translation key). These live in separate systems and should be managed separately.
The integration point is at the component level. When a designer defines a button component, they choose a background color (design token) and write a default label text (which needs a translation key). Both decisions need to propagate to the implementation. The design-to-localization handoff is specifically the propagation of translation keys -- not design tokens, which have their own tooling.
Adding Design System Strings to the Translation Pipeline
Once you have identified the text layers in your design system that need translation keys, adding them to the pipeline is straightforward:
- Create a `design-system` namespace in your locale files (e.g., `en.json` under `{"ds": {...}}`). This separates design system strings from feature-specific strings and makes it easier to track which components have been fully localized.
- Add initial translations for all design system string keys as part of the design system version release, not as a later follow-up task.
- Treat design system string changes as release-blocking localization tasks the same way you treat feature string changes. A design system release that changes button label copy requires translated strings before the release ships to non-English users.
The Figma Handoff Checklist
A practical checklist for design-to-localization handoff when a new component or component update is being implemented:
- Identify all text layers in the component that will be visible to end users.
- Verify that each text layer has a translation key annotation (or add one now).
- Check whether the translation key exists in the locale files. If not, add it to the source locale (English) and queue it for translation.
- In the implementation PR, include the new or updated locale file entries. Do not defer locale file updates to a separate PR.
- For component updates that change existing text, treat the source string change as a stale translation signal and queue the affected keys for translation review.
The goal is that no component ships with a hard-coded English string where a translation key belongs. Every text layer that is visible to users is managed in the localization pipeline. The design system is the last place strings hide -- building the handoff convention makes it the first place they are found.