Team Workflows: Sharing Translation Settings via Git

Your translations belong in your repo, not in someone else's cloud. XCStrings Translator is built around this principle: the .xcstrings file on disk is always the source of truth.

You Own Your Data#

Most translation tools store your strings in their database. Your translations live on their servers. If the service goes down, changes pricing, or shuts down—you're stuck exporting, hoping the format is compatible with whatever you migrate to.

With XCStrings Translator, there's no database. No cloud sync. Your .xcstrings file is your translations. It's JSON. It's in your repo. It's yours.

This means:

• No lock-in. Switch tools anytime. The file format is Apple's standard.
• Full history. git log shows every translation change, who made it, when.
• Offline works. No internet? No problem. The file is local.
• Backups are free. Your repo's backup strategy covers translations too.

Git-Friendly Config#

XCStrings Translator saves project settings to .xcstrings-translator/config.json:

{
  "provider": "openai",
  "model": "gpt-4o",
  "customPrompt": "This is a fitness app for casual athletes...",
  "batchSize": 10
}

Commit this file. Now everyone on your team uses the same AI provider, the same model, and the same custom prompt. Consistency without coordination.

What's not in the config: API keys. Those stay in each developer's macOS Keychain. Never in git, never in plain text.

Team Workflow#

Developer A adds German translations:

# Work in XCStrings Translator, save
git add Localizable.xcstrings
git commit -m "Add German translations"
git push

Developer B adds French translations:

git pull  # Gets A's German translations
# Work in XCStrings Translator, save
git add Localizable.xcstrings
git commit -m "Add French translations"
git push

Git handles the merge. The .xcstrings JSON format has distinct keys for each language—conflicts are rare. When they happen, you resolve them like any other code conflict.

Code Review for Translations#

Because translations are in git, you can review them in pull requests:

git diff main...feature-branch -- Localizable.xcstrings

Reviewers can catch:

• Typos or grammar issues
• Tone inconsistencies
• Missing translations
• Broken format specifiers

You can't do this with external translation databases. There's no PR, no diff, no blame. Translations just appear (or don't).

Sharing Context#

The custom prompt in your config is shared. Write it once, everyone benefits:

{
  "customPrompt": "This is a meditation app for busy professionals. Use a calm, reassuring tone. Keep sentences short."
}

When a new developer joins, they clone the repo, open the project, add their API key—done. They're using the same translation context as everyone else. No onboarding doc needed.

That's It#

Your app's code is in git. Your assets are in git. Your translations should be too.

XCStrings Translator doesn't try to be a translation management platform. It's a tool that makes the files you already have easier to work with. When you're done, you have the same .xcstrings file Xcode expects—just with more translations in it.

No vendor dependency. No sync issues. No wondering where your translations actually live.

They live in your repo. Where they belong.

Related#

• Getting Started — Set up your first project
• Writing Custom Prompts — Craft the perfect shared prompt
• Project Settings — All config options explained