Repository 

In software development, a repository (or repo) is where a project lives. It stores source code, configuration files, assets, and, in internationalized projects, translation files. Every change made to any of these files is tracked, timestamped, and reversible. Developers use repositories through version control systems like Git, with platforms like GitHub, GitLab, and Bitbucket serving as remote hosting environments for team collaboration.

For localization, the repository is the starting point of the entire workflow. Translation files such as .json, .po, .yaml, or .strings sit inside the repo alongside the code they support. When a developer adds a new string, it lands in the repo first. When a translator completes a translation, it returns to the repo through a pull request or an automated sync. The repository is where source and translation stay in sync, or fall out of it.

🔗 Why repositories matter for localization teams #️⃣

Keeping translation files in the same repository as the source code has a significant practical advantage: localization becomes part of the development cycle rather than a separate process running alongside it. When a new feature ships with new strings, those strings are visible in the repo immediately. Localization tools that connect directly to the repository can detect the change automatically and trigger translation workflows without any manual file handling.

This is the foundation of continuous localization. Rather than exporting files, emailing them to a translation team, and reimporting the results, teams connect their TMS directly to the repository. Source files push to the platform when code is committed. Completed translations return as pull requests. The whole exchange is tracked in version control, meaning every change is auditable and reversible.

📁 Key points about repositories in localization #️⃣

• Translation files in a repository follow the same branching model as code. A feature branch can contain both new source strings and their translations before merging to the main branch, preventing untranslated content from reaching production.
• Repository connectors (integrations between a TMS and platforms like GitHub or GitLab) automate the push and pull of translation files, removing developers from the manual parts of the localization loop.
• Locale naming conventions in a repository matter. Inconsistent file naming, such as mixing en_US.json and english.json across directories, creates errors when TMS tools try to detect and parse locale files automatically.
• Public repositories open a path to community-driven translation. Open-source projects commonly invite contributors to submit translations through pull requests, using the repository as the collaboration layer.
• A well-structured repository makes localization easier to scale. Keeping one file per locale, using consistent key naming, and separating translation files from application logic all reduce friction when adding new languages.

🔄 Repository structure and localization #️⃣

A common pattern in software projects is a locales/ or i18n/ directory at the root of the repository, containing one file per language. For example:

/locales
  en.json
  de.json
  fr.json
  es.json

Each file maps translation keys to their localized strings. When a new language is added, a new file is created. When an existing string changes, only the affected files need updating. This structure is what TMS platforms and CLI tools expect when syncing with a repository.

How Localazy connects to repositories #️⃣

Localazy integrates with GitHub, GitLab, and Bitbucket, allowing teams to automate the full localization loop from code commit to translated file delivery. The Localazy CLI can be added to CI/CD pipelines to push new source strings and pull completed translations automatically on every build.

See how to connect your repository in the Localazy CLI documentation.