{
  "id": 17288865,
  "title": "I let my coding agent do the whole localization job, from messy keys to approved translations",
  "url": "https://urgent.news/2026/10/30/i-let-my-coding-agent-do-the-whole-localization-job-from-messy-keys",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-30T21:05:19.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mario_hahn_69c72ae001e781/i-let-my-coding-agent-do-the-whole-localization-job-from-messy-keys-to-approved-translations-2adc"
  },
  "original_language": "en",
  "account": "After shipping several apps across iOS, Android, and web platforms, the writer's string management became a tangled mess. Some strings were hard-coded directly into views, while others resided in Localizable.xcstrings files with ambiguous keys. Android used different names altogether, like R.string.login_btn, and the web app had its own identifiers, such as auth.signIn. This proliferation of names for identical text led to translation inconsistencies and the risk of outdated versions slipping through. Determined to streamline the process, the writer developed locli.\n\nWith locli, the writer's coding agent handles every aspect of app localization. First, the agent moves all text into a centralized catalog - String Catalog on iOS, strings.xml on Android, ICU JSON for the web or backend. The agent then assigns unique lower_snake_case identifiers to each string, with a platform-specific prefix. So, \"Sign in\" becomes a single key that is translated once and used universally. When different platforms require distinct wording, variants of the key are used instead of creating new identifiers.\n\nThe agent merges duplicate keys, consolidating all translations under a single identifier, and updates the code accordingly. The process stops only if there's a genuine conflict between translations, like two different German versions for the same button. Contextual translation is key with locli, which uploads keys and texts while preserving any changes made by translators. The agent uses the project's tone and a glossary to ensure accuracy. Every upload is verified for placeholders, plural forms, and glossary terms.\n\nOnce translated, the writer reviews the changes using diff comparisons in the locli web app and approves the release. The agent then pushes the approved translations back into the app. The writer runs locli on six of their apps, totaling around 2,650 keys across all platforms, and has also used it to localize their own web app, uncovering and fixing bugs along the way. The tool is open-source, with MIT licenses for the CLI and MCP server, and can be installed with npx @locli/cli init or by telling your agent to set up locli for your app's text.",
  "summary": "Every app I ship exists on iOS and Android, some on the web too. After a few releases the strings were a mess: half of them hard-coded in SwiftUI views and Compose screens the rest in Localizable.xcstrings under keys like \"Sign in\" , account.login and login_button , all for the same button the Android app with its own names for everything ( R.string.login_btn ) the web app with a third set (…",
  "key_points": [
    "Writer developed locli to streamline app localization.",
    "locli centralizes text into a single catalog and assigns unique identifiers.",
    "Tool ensures consistent translations across iOS, Android, and web platforms."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}