i18n management
for development teams

Translation is one step in a larger process. i18n management covers everything that happens around it — how translation keys are created and named, how they are organized into namespaces, who is responsible for translating and reviewing each string, and how translations stay in sync with the codebase as features ship.

Without deliberate management, projects accumulate translation debt: orphaned keys nobody uses, inconsistent naming that makes searching impossible, missing translations that slip into production, and merge conflicts in translation files that slow every release. A software localization platform like SimpleLocalize gives teams the structure to prevent this — centralized key storage, namespace-based organization, role-based access, and automated sync with CI/CD.

The most common pattern is hierarchical keys that mirror your UI structure: dashboard.sidebar.menuLabel, settings.notifications.emailToggle. This makes keys predictable, searchable, and easy to scope to a namespace.

Namespaces group keys into logical units — typically one per feature, page, or module. For example, a SaaS app might use common for shared strings, dashboard, billing, and onboarding for feature-specific keys. Each namespace can be loaded independently, which improves runtime performance and keeps translation files small. See the namespaces documentation for setup details.

Tags add a cross-cutting dimension. Tag keys by release (v3.2), by team (growth), or by priority (critical). Unlike namespaces, tags do not affect file structure — they are metadata for filtering, reporting, and bulk operations.

Teams running several products — a web app, a mobile app, an admin panel — face a choice: duplicate common translations in each project, or share them through a central system. The shared approach scales better. In SimpleLocalize, you create shared namespaces (e.g., common, errors) that every app imports, alongside app-specific namespaces that only one project uses.

Each app's CI/CD pipeline uploads and downloads only the namespaces it needs. This keeps deployments independent — shipping a change to the web app does not require redeploying the mobile app. When a shared string changes, every app picks it up on its next sync cycle automatically.

The most reliable way to manage i18n is to treat translation sync as a CI/CD step, not a manual task. After each merge, your pipeline uses the SimpleLocalize CLI to upload new or changed keys. Auto-translation fills in the gaps. A subsequent step downloads the translated files or publishes them to the Translation Hosting CDN.

This works with GitHub Actions, GitLab CI, Bitbucket Pipelines, or any runner. The result: developers add keys in code, translations appear without manual handoffs, and every release ships fully localized. Read the continuous localization guide for a full walkthrough.

Translation debt accumulates silently. A key gets renamed in code but not in the translation file. A feature is removed but its 200 keys stay behind. A new language is added but only half the strings get translated before launch. Over months, these small gaps compound into a maintenance burden that slows every release.

The fix is a combination of tooling and process: use the CLI to detect unused keys and remove them regularly, enforce translation coverage thresholds before deploy, and use automations to auto-translate new keys so no language falls behind. Tags can mark keys as deprecated before removal, giving translators time to adjust. The goal is to make translation maintenance a routine part of your development process, not a periodic cleanup.

Set up auto-translation to fill new keys immediately after they are uploaded. Use the translation editor's filters to find keys with missing translations per language, and enforce coverage checks in your CI/CD pipeline before deploying. For critical strings, configure fallback behavior in your i18n library (e.g., fall back to the default language) so users never see raw translation keys.

Each app or package in the monorepo gets its own namespace (or set of namespaces). Shared packages like a component library use a common namespace. Each app's CI step uploads and downloads only the namespaces it owns. This keeps translation files scoped to each deployable unit while sharing common strings through the centralized translation editor.

Regularly audit your keys: use the SimpleLocalize CLI to compare keys in your codebase with keys in the platform and delete orphaned entries. Use namespaces so each file stays focused on a specific feature or module. Set up automated cleanup as a CI step — after uploading new keys, run a purge of keys no longer referenced in the source code.