iOS Strings
Localizable.strings, decoded correctly
Apple’s .strings format has carried iOS and
macOS translations for decades, and it hides a trap: Xcode still writes these files
as UTF-16. Tools that read them as UTF-8 see garbage and guess wrong. locamorph
decodes UTF-8 and both UTF-16 byte orders, imports the comments as translator
notes, and reads the locale straight from the lproj folder name.
Honest scope: locamorph imports .strings today but does not export
them yet. Translations flow in from iOS files and out through the editor,
XLIFF or any other format.
/* Title of the checkout screen */ "checkout.title" = "Récapitulatif de commande"; /* Main navigation */ "menu.home" = "Accueil"; "menu.projects" = "Projets";
In locamorph
How locamorph handles .strings
UTF-16 is not garbage here
Files are decoded as UTF-8 or UTF-16 in either byte order, so the file Xcode actually wrote imports cleanly instead of misdetecting as another format.
Comments become notes
The /* comment */ above each pair imports as that key’s
note, so translators see the context the developer wrote.
Locale from the path
fr.lproj/Localizable.strings is recognized as French without
anyone filling in a dropdown.
Plurals live outside this format in .stringsdict, which locamorph
does not read today; plural strings for iOS are best managed through
XLIFF, which Xcode exports and imports natively.
Ecosystem
Where .strings lives
Every UIKit and AppKit app localizes through .strings, across iOS,
macOS, watchOS and tvOS. Xcode 15 introduced String Catalogs
(.xcstrings) as the modern successor, but decades of projects and
tooling still speak .strings fluently.
Typical flow: import the existing Localizable.strings per locale to
seed the project, translate alongside your
Android and web strings, and hand
results back to Xcode through XLIFF.
Related
Keep going
Seed a project from your lproj folders
Import your existing iOS strings on the free plan, keep the comments, and translate every platform’s files in one place.