# I let my coding agent do the whole localization job, from messy keys to approved translations > Source: > Published: 2026-10-30 21:05:19+00:00 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.