String extraction

Sweeping every hardcoded label out of the code into a translatable file, leaving a lookup key behind where the text used to be.

getting text out of the codecollecting all the wordspulling out hardcoded stringsextracting UI textscanning the code for every labelstring harvestinggenerating the translation file from the codestring extration

See it

Live demo coming soon

What it is

String extraction is the sweep that finds every user-visible sentence sitting in your components and moves it into a message catalog, leaving a translation key behind in the code. It is usually a tool, not a human: i18next-parser, FormatJS extract, Lingui extract, or the classic xgettext walk the source, collect the marked strings, and write or update the source-language catalog.

Run it in CI on every commit so the catalog is generated, never hand-edited. That gives you two useful signals for free: new keys that need translating, and orphan keys nobody references any more. Extraction also carries developer comments through as translation context, which is the cheapest quality win in the whole pipeline.

Gotcha: extractors only see what they can statically read. A string built at runtime, or a key assembled as 'errors.' plus a variable, silently never makes it out. And the sweep always misses the unglamorous copy: alt text, aria-labels, placeholder attributes, form validation messages, toast text, page titles, email templates, and hardcoded strings inside utility functions. Grep for quoted text after the tool claims it is done.

Ask AI for it

Extract all user-facing strings from this codebase into an i18n message catalog. Wrap each one in the t() call for our i18n library with a semantic dot-notation key namespaced by feature (for example 'checkout.summary.total'), and write the English source text into locales/en.json. Include alt text, aria-labels, placeholders, button labels, validation and error messages, page titles, and empty states. Convert any sentence built by concatenation into a single string with ICU placeholders so translators can reorder it. Keep locales/en.json valid JSON, so put translator descriptions somewhere JSON can hold them: the i18n library's supported description metadata, extractor-recognized source comments next to each t() call, or a separate metadata catalog keyed by the same keys. Then verify extraction actually carries those descriptions through into the TMS format. List anything you could not extract statically instead of guessing.

You might have meant

translation keymessage catalogi18ntranslation contextstring concatenation