How to evaluate i18n string extraction
More extracted strings do not automatically mean better extraction. Evaluate whether the results contain real user-facing copy, what the tool misses, and how much review your application needs.
Start with the task and scope
A migration from hardcoded text and an audit of an already-localized application are different tasks. Finding existing translation keys is different from identifying new strings. Choose the workflow you need, pin the tool versions and source commits, and record scan roots, ignored files, framework adapters, and tuning.
Hedgeling scans supported source formats and supplies build-time wrapping for supported frameworks. The published i18next-cli comparison distinguishes its instrumentation and existing-key extraction behavior. Consult the linked report for the configuration used for each tool; do not compare raw counts across different scopes as if they were recall scores.
Measure precision, recall, and review effort
- Precision: how many surfaced candidates are genuine user-facing strings? Label a representative sample and record ambiguous cases.
- Recall: how many known target strings were recovered? This requires a reference set; extraction counts alone cannot establish it.
- Review effort: how much configuration, manual handling, and validation did the result need? Report this alongside speed.
The flagship report measures precision on samples and recall with a strip test. Its time-saving figures use stated assumptions; they are estimates, not measured customer productivity gains.
Read the evidence and its limits
- Flagship benchmark: tuned configurations, migration versus audit results, sampled precision, strip-test recall, and limitations.
- i18next-cli comparison: tool configurations, labeled results, and the measured repositories.
- Mega benchmark: extraction across a larger collection of real codebases.
Some repositories were used during development of the extractor. The report identifies that limitation. Published results do not guarantee performance on your codebase and do not establish translation quality.
Try a representative sample of your application
- Select a small, representative area: components, validation messages, forms, and any runtime content you need to localize.
- Run extraction and inspect diagnostics. Keep code examples, test fixtures, and program identifiers distinct from UI copy.
- Label both candidate strings and a known reference set. Record the sampling method and any exclusions.
- Build the localized application and check actual rendered screens before broadening the rollout.
Start with the React + Vite guide or the coding-agent workflow. Read this page as Markdown.