Loco support for Xcode string table formats
Apple recommends XLIFF files for the interchange of localizable strings, and dissuades developers from editing string tables outside of Xcode. Please refer to the Xcode documentation and check out this useful video from WWDC23.
As well as Xcode-specific .xliff
files, Loco also supports .xcstrings
, .strings
, .stringsdict
, .plist
, .bplist
formats.
See the following pages for detailed guides on importing and exporting Xcode strings in various formats:
Plural variations
Plurals are managed in the main Loco interface the same way for all platforms, but managing plural forms in Xcode has been changing over the years. Loco provides a couple of ways to work with Xcode plural variations:
XLIFF
Xcode XLIFF files have a<file>
section corresponding to either a.stringsdict
property list, or (more recently) string variations held in.xcstrings
files. Loco can import and export plural rules embedded in XLIFF, so there's no need to handle them separately..stringsdict
For older projects you can export.stringsdict
files directly from Loco, which contain only the pluralized strings in your project. This is generally used if you're also exporting.strings
files directly.
See also: Managing plural forms in Loco.
Formatting substitutions
Loco automatically detects string formatting when you import entries containing valid printf-style syntax, like this:
"user_score" = "%1$@ scored %2$d%%!";
After importing this string, it will be identified as being in Objective C format and any translations made from it will be validated to ensure they match.
It's common to share translations between iOS and Android, but the syntax of the Objective C implementation is quite different to the Android Formatter. Loco recognizes both styles of formatting and can convert between the two in most common cases.
See also: What is string formatting? and Working with string formatting across platforms.
Limitations
Loco doesn't yet support the full range of string variation features available in Xcode >= 15. Currently we support a single plural variation per string, and only for the configured plural forms for the given language.
It's on our roadmap to implement:
- Complex plural variation with substitutions.
- Device variations.