I let my coding agent do the whole localization job, from messy keys to approved translations

A developer built locli, an open-source CLI and MCP server that lets coding agents like Claude Code, Cursor and Codex localize apps end to end — consolidating duplicate string keys across iOS, Android, web and backend into one lower_snake_case identifier per text, translating via context-aware uploads, and validating placeholders, plural forms and glossary terms before a human approves each release. The developer reports running six apps with roughly 2,650 keys on it, with locli also localizing its own web app; the CLI and MCP server are MIT-licensed with no dependencies.

Every app I ship exists on iOS and Android, some on the web too. After a few releases the strings were a mess: Localizable.xcstrings under keys like "Sign in" , account.login and login button , all for the same button R.string.login btn auth.signIn Three names for one text means three translations, three chances to drift, and nobody knows which one is right. Say "localize this app" to my coding agent, and get it done properly : not a quick translation that breaks a placeholder or puts a German sentence into a toolbar button. So I built locli https://locli.dev , and now this is what my agent Claude Code, but Cursor and Codex work the same does on its own. Hard-coded strings go into the app's own catalog: the String Catalog on iOS, strings.xml on Android, ICU JSON on the web or backend. The code switches to looking them up by key. Every text gets one lower snake case identifier with a feature prefix: account login settings language title cart checkout The same identifier on iOS, Android and web . So "Sign in" is one key, translated once, used everywhere. Where a platform really needs different wording, it gets a variant of that key instead of a new one. This is the part I used to dread. The agent finds keys that mean the same thing account.login on iOS, account login on Android , merges them into one, keeps every translation, and switches the code to the new name. It only stops and asks me where two values really conflict, for example two different German texts for the same button. It never just picks one. locli push uploads the keys and texts it never overwrites what a translator changed . Then the agent translates, using: locli context reads the code and knows that cart checkout is a toolbar item and cart title a screen title Every upload is checked: placeholders like %lld or {count} in every language, plural forms per language Polish and Arabic need more than "one" and "other" , glossary terms. The one thing the agent can't do is ship. I go through the changed texts in the locli web app, each with a diff, and approve the release. Only then does locli pull write exactly that release into the app. Builds stay reproducible, and a bad translation never reaches the store just because an agent was confident. I run six of my own apps on it, about 2,650 keys across iOS, Android, web and backend, and locli localizes its own web app. Dogfooding found real bugs, and each got a fix and a test: current Xcode saves String Catalogs as version 1.1, which the CLI refused at first. In your app's repository: npx @locli/cli init or tell your agent: "Set up locli for this app's texts." For Claude Code there's a plugin: /plugin marketplace add mariohahn/locli /plugin install locli@locli The CLI and MCP server are MIT and have no dependencies: github.com/mariohahn/locli https://github.com/mariohahn/locli . One project is free. I'd love to hear how messy your keys are, and where this breaks on your project.