Design tooling · Built with Claude

Keeping design and translation in sync.

A Figma tool built with Claude, combining conventional string matching with optional AI help to connect design text to translations across six languages.

The problem

Myko was available in six languages. The designs lived in Figma, while the translation strings were managed separately. I wanted to bring those strings into the design workflow, so I could switch languages and review the copy in context.

Building with AI

I used Claude to help write, debug and iterate on the plugin. I defined what it needed to do, tested it on the designs and challenged incorrect matches and confusing behaviour.

AI also became an optional assistant inside the tool. Conventional code handled the first matching pass; I could ask Claude for help with layers that still needed a key or a clearer match.

01.From strings to screens.

The starting point was a CSV: a key for each string, with a column for each language. Conventional code scanned the text layers and checked existing keys and straightforward matches. I could review those results and link a key manually without using AI.

When I needed help, I could trigger AI Match for selected layers or the wider list. Code shortlisted relevant CSV entries, then Claude received the layer text, name, parent frame and candidate keys with sample values. It suggested an existing key, with a confidence label and a reason.

Inspect in context.

Select a bound layer to see its key and translations, edit a value and check its recorded history.

Bring updates together.

Import CSV or JSON files to add strings and review changes to existing values.

Keep a record.

Changes from imports and inline edits are logged with the key, locale and before-and-after values. The history can be exported as a CSV.

02.Learning where AI needed context.

AI selected among existing CSV keys; it did not write or translate the copy. It worked from the supplied text and metadata, with no view of the rendered Figma screen.

A shortlist could omit the right key, and repeated words could fit several journeys. The confidence label was the model’s own assessment, not a measured accuracy score. Its suggestion still needed review.

When context was too broad

Matching the words was only the start.

Labels such as “Continue”, “Auto” and “Cancel” appear across many screens. Finding the same words in the CSV did not guarantee the right key: the match also needed to fit the screen and journey.

Testing showed how broad frame names and reused matches could hide those differences. More specific context and a visible review step were important, particularly for short, generic labels.

Same visible labelContinue
Radiator pairingpairing.trv.install2.continue
Gateway pairingpairing.gateway.start.continue

Identical copy. Different journeys. Different keys.

What I would improve

Make review the source of truth.

The implementation could store AI suggestions in memory before explicit human approval. Nearby text was collected, but was not included in the matching request even though the prompt referred to it.

I would separate suggested, accepted and remembered matches more clearly, learn only from reviewed choices, and ensure the model receives the context the interface promises.

SuggestShow the candidate and the reason.

ReviewLet the designer correct the key.

RememberReuse an accepted choice when the context fits.

What I took from it

Building the tool made the decisions tangible.

Working with Claude let me turn a recurring design problem into something I could use and test. It also made the limits visible: useful automation depends on the quality of the context and on clear boundaries between a suggestion and a decision.

This was a working internal tool and an ongoing experiment. I have not measured time saved or matching accuracy.

Back toSelected work →