Drop Locale

xcstrings translator that runs in your browser

Drop a .xcstrings file in below, pick a target language, download the translated catalog. The .xcstrings file stays on your device.

Loading translator...

How it works

Drop a .xcstrings file on the page, click to choose one, or paste the contents straight in. The parser reads the catalog in your browser and tells you how many strings still need translation. Pick a target language and translation starts immediately. The translated catalog is reassembled from the same parsed structure so the original sourceLanguage, comments, key order, and any localizations you already had for other languages all survive the round trip.

Quality Warning

Please don’t rely on the quality of these translations to ship a finalized product. This is just a starting point. It’s machine translation and there are no guarantees about its quality.

What we do not do

The file itself never leaves your device. We do not see what you are translating, we do not store any of the strings, and there is nothing about your file in our logs. The privacy wedge in DropFormat is structural: the xcstrings parser, the Google Translate caller, and the file writer all run inside your browser tab.

What does leave your device: the individual strings go to translate.googleapis.com the same way they would if you pasted them into translate.google.com yourself. We are not in the middle. If your catalog contains internal product strings you do not want a third party to see, do not translate it here; use an offline tool.

What it supports

xcstrings (Apple String Catalogs) is the JSON-based localization format Xcode 15 introduced for iOS, iPadOS, macOS, watchOS, tvOS, and visionOS apps. Each translatable string is a top-level key under the strings field, with a per-language localizations map underneath. We preserve all of it on round trip: insertion order of keys, comments, extractionState, and any localizations for languages other than the one you are translating to.

Plural variations of the shape "variations": {"plural": {"one": ..., "other": ...}} are first class. The parser detects plural variations on the source-language localization and fans each CLDR case (zero, one, two, few, many, other) out into its own row in the review pane. Translate each case independently; on download the cases are re-assembled into one variation block under the target language. The case set in the output matches the case set in the input.

Placeholders like %@, %lld, and %1$@ pass through the translator unchanged. The protection layer that masks placeholders before translation and restores them after is the same one used for the PO, XLIFF, and ARB translators.

Keys marked "shouldTranslate": false are honored: those strings are preserved exactly as they appear in the source and are not sent to the translation provider. A banner at the top of the review pane tells you how many keys were preserved this way.

Not yet: device variations ("variations": {"device": ...}), substitutions with embedded variations, and width variants. Keys that use any of those shapes are preserved verbatim on download and counted in the same “preserved” banner so they are not silently dropped.

What we tolerate, and what we reject

Some malformed files we repair on the way in. Others we refuse to load so we do not make things worse. This list is the parser’s actual behaviour, generated from the format module itself, not aspirational copy.

Repaired automatically:

  • UTF-8 byte order mark (BOM) at the start of the file
  • Windows (CRLF) or mixed line endings
  • Trailing JSON commas before } or ]

Refused with an explanation:

  • Empty file. Add at least one string key and re-upload.
  • Does not parse as JSON. Fix the JSON syntax so the file parses, then re-upload.
  • Not an Xcode String Catalog (missing "strings" field, top-level array, etc.). Confirm the file was exported from Xcode as a .xcstrings catalog.
  • No translatable entries (all entries marked do-not-translate). Confirm there is at least one entry without shouldTranslate=false.

Common questions

Why is the translation in some cases worse than the Google Translate website? The free endpoint we use is the same one the Google Translate website uses, but the API does not always know about the context the website’s interface provides. For names, branded terms, or jargon, expect to override in the review pane.

What if I am translating something Google’s endpoint will not accept? The free endpoint occasionally returns the source unchanged for content it would rather not translate. Those entries show “kept original” in the review pane so you can hand-translate just those.

Does it cache anything? No. Each run starts fresh.

Will the output be valid JSON? Yes. The compiler serializes through JSON.stringify, so the file is always parseable. It will load cleanly in Xcode 15 or any xcstrings-aware tool.

What about my existing translations for other languages? Untouched. xcstrings is multilingual by design: each string can hold localizations for every language at once. We add a localization for the target language you pick and leave every other language exactly where it was.

What does the file source language even mean if the catalog is multilingual? The sourceLanguage field at the top of the catalog tells Xcode which language to treat as the “ground truth” against which other translations are reviewed. We never overwrite that field; the translation you generate is added as just another localization beside it.

Why this exists

Apple shipped xcstrings as the default localization format for new Xcode projects in 2023. Most Mac-only tooling expects you to either pay for a managed service or run their CLI against your local files. This tool sits in between: free, browser-based, no upload, designed for the “I just need a fast first pass on this catalog” workflow. Drop the .xcstrings, pick the language, get back a translated catalog in the same shape.

What is xcstrings?

xcstrings (“Apple String Catalogs”) is a JSON-based format Apple maintains for localizing iOS, iPadOS, macOS, watchOS, tvOS, and visionOS apps. Each translatable string is a top-level entry under strings, with optional comment, extractionState, and shouldTranslate fields, plus a localizations object mapping language codes to translation data. Each localization is either a simple stringUnit (state + value) or a variations block holding per-CLDR-plural-case stringUnits. Xcode reads .xcstrings at build time and generates the localized resources iOS frameworks load at runtime.