Data format

STRINGS converter

A .strings file is Apple's localization resource: a flat list of "key" = "value"; statements, one per translatable string, usually named Localizable.strings and stored inside a per-language .lproj directory. It is what NSLocalizedString and its SwiftUI equivalents look up at runtime.

Private for supported formats — processed in your browser

Convert supported files

Runs on your device

Drop STRINGS files here

Batch files can each use a different output. Nothing uploads for local conversions.

Working inputs include camera RAW, browser-local audio/video, PDF, CBZ/CBR comics, office documents, ebooks, markup, 3D models, structured text, images, and archives.

Where STRINGS comes from

The format comes from NeXTSTEP in the late 1980s and survived the transition to Mac OS X and then iOS essentially unchanged, which is why its syntax looks like a property-list fragment rather than anything designed for translators. Files were historically UTF-16, and modern tooling accepts UTF-8. Apple has since layered .stringsdict on top for plurals and, more recently, String Catalogs (.xcstrings) as a JSON successor — but .strings remains the format most existing projects ship.

How STRINGS works

  • Each entry is `"key" = "value";` — the trailing semicolon is required, and both sides use C-style escapes.
  • Comments in /* … */ immediately above an entry are the conventional place for translator notes and are extracted by Apple's tooling.
  • Keys are arbitrary identifiers; by convention many projects use the English source text as the key, which brings gettext's trade-off along with it.
  • Plurals are not expressible here — they live in a separate .stringsdict property list.
  • Historically UTF-16 with a BOM; UTF-8 is accepted by current tooling and is what most editors now produce.

When to use STRINGS

  • Localising an existing iOS, iPadOS or macOS application
  • Handing Apple-platform strings to a translator in the form their tools expect
  • Migrating an older Apple project's strings into XLIFF or a cross-platform catalog
  • Comparing two locales' resources to find missing entries

Strengths and limitations

Strengths

  • Trivially simple grammar that any tool can read or write
  • Native to Apple's toolchain with no build step beyond copying
  • Comment convention gives translators real context

Limitations

  • No plural support at all — that requires a second file in a different format
  • A missing semicolon silently truncates parsing in some tools
  • No structure: everything is one flat namespace
  • The UTF-16 legacy still produces mojibake when files meet tools that assume UTF-8

Compatibility

Xcode reads and writes .strings natively, and every translation platform supports it because iOS work demands it. Outside Apple's ecosystem support is incidental. Novus Convert parses the quoted key/value grammar locally, tolerating the comment form, and converts to and from the other localization formats.

Keys and translated values are preserved. Comments are not treated as structured notes, and plural rules cannot be represented — a catalog with plurals converted into .strings will lose the plural forms because the format has no way to hold them.