Most i18n advice still assumes you already have a translation system and the team discipline to maintain abstract keys. We didn’t. On every project where we tried to go from zero translations to “ship it”, inventing keys and wiring up files slowed everything to a crawl. Developers procrastinated, strings stayed hard-coded, and localisation kept falling off the roadmap.

We flipped the process on its head: treat the literal strings as the source of truth, make t("Delete this account") the default, and let tooling worry about context and variants later. That single shift makes onboarding take seconds per string, keeps the code readable, lets grep/LLMs understand intent, and still leaves room to annotate edge cases once you actually feel the pain.

After building a VSCode extension to automate extraction, dedupe near matches, classify strings with an LLM, and generate framework-specific locale files, we finally got localisation over the line in real codebases. What surprised us most is how far you can get with “controversial but pragmatic” natural language keys—especially when the goal is 0→1 adoption, not theoretical purity.

We built a VSCode extension called Rokalise. It scans your project, transforms translatable strings, normalises natural keys, and can spit out JSON locale files ready for Next.js/React today (Rails, Laravel, Vue in progress). Happy to share how we handle collisions, context markers, and progressive enhancement if you’re curious—or hear counterexamples where this breaks.