Drop Locale

Apple .strings translator that runs in your browser

Drop an Apple .strings or .stringsdict file in below, pick a target language, download the translated file. The file stays on your device.

Loading translator...

How it works

Drop a .strings file on the page, click to choose one, or paste the contents straight in. The parser reads the file in your browser and tells you how many strings still need translation. Pick a target language and translation starts immediately. The translated file is reassembled from the same parsed structure so the original comments, key order, and escape sequences 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 .strings 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 file 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

Apple .strings is the resource-bundle format that has backed NSLocalizedString on Mac and iOS since Mac OS Classic. Each entry is a quoted key, an equals sign, a quoted value, and a trailing semicolon, with C-style block and line comments between entries. We preserve all of it on round trip: insertion order, comment lines (both /* */ and // styles), blank lines, and the original quote style.

Escape sequences are first class. The parser unescapes \n, \t, \r, \\, \", and the \Uxxxx Unicode escapes Xcode emits for high code points. The compiler re-escapes them on the way out so the output file reloads byte-equivalent in NSLocalizedString and NSBundle.localizedString(forKey:value:table:).

Apple .strings has no native plural concept at the entry level. The Apple solution is the sibling .stringsdict XML plist format. Drop a .stringsdict file in this translator too: each CLDR plural case (zero, one, two, few, many, other) becomes a row you can review. The translated file is re-assembled into the original plist on download with the format-spec metadata (NSStringLocalizedFormatKey, NSStringFormatSpecTypeKey) preserved verbatim.

UTF-8 is assumed. Xcode has emitted UTF-16 .strings files by default for years; if your file is UTF-16 the translator detects this and asks you to re-save as UTF-8 before dropping it again. The output is always UTF-8. Modern Xcode accepts UTF-8 .strings files natively.

Not yet: locale-suffixed file names (Localizable.strings inside fr.lproj/) are not auto-renamed on download; the output keeps the original file name with a .translated.strings suffix. Move it to the right .lproj folder before adding it to your Xcode project.

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

Refused with an explanation:

  • Empty file. Add at least one "key" = "value"; entry and re-upload.
  • No translatable entries (comments only). Add at least one "key" = "value"; entry.
  • Syntax error (missing semicolon, unterminated quote, truncated string). Fix the .strings syntax so every line ends with "key" = "value";
  • Looks like a different translation format (PO, .properties, XLIFF). Use the /translate/ hub to pick the right translator.

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 a valid .strings file? Yes. The compiler re-escapes the structurally meaningful characters and emits one entry per line. The file loads cleanly in NSLocalizedString, NSBundle.localizedString, and Xcode’s Localizations editor.

What about format specifiers like %@ and %d inside values? The translator treats them as opaque tokens and passes them through unchanged. Placeholder protection (the same masking layer the PO and XLIFF translators use) keeps %@, %d, %1$@, and similar from being mangled by the machine translator.

What about .xcstrings (Xcode 15+ String Catalogs)? Those have their own translator at /translate/xcstrings/. Drop those there.

Why this exists

Most Apple localization tooling expects you to either pay for a managed translation service or run a 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 .strings file” workflow. Drop the .strings (or .stringsdict), pick the language, get back a translated file in the same shape.

What is .strings?

Apple .strings is the plain-text resource-bundle format defined by NSLocalizedString on the Apple platforms. Each file is a flat list of quoted “key” = “value”; pairs that NSBundle loads at startup to localize an application’s UI strings. The format has been around since Mac OS Classic in the 1990s and remains the default for legacy iOS and macOS projects (Xcode 14 and earlier; Xcode 15 added the .xcstrings catalog format as the new default, but .strings remains supported). The sibling .stringsdict format adds CLDR plural support via an XML plist. A typical resource bundle is a family of folders like en.lproj/Localizable.strings, fr.lproj/Localizable.strings, de.lproj/Localizable.strings; the runtime picks the right file based on the user’s preferred languages and falls back to the development language when a translation is missing.