Apparently, a LocalizedStringKey
will automatically generate the localization key depending on the type of the values interpolated. For example, if you have the following Text
s
Text("title key")
Text("name key \("Club")")
Text("count key \(8)")
Text("price key \(6.25)")
Your Localizable.strings file should look like
"title key" = "Sandwiches";
"name key %@" = "Name: %@";
"count key %lld" = "%lld sandwiches";
// You can change the format specifier in the value, but not in the key.
"price key %lf" = "Price: %.2lf";
Be careful if you want to support 32-bit systems (iPhone 5 or earlier). In a 32-bit system, Int
is Int32
, the key of "int32 key \(Int32(8))"
is "int32 key %d"
. You can always convert an integer to Int64
like in "count key \(Int64(8))"
to enforce consistent keys across different systems.
Remark 1: For people who want to know how it works. When you use a string literal or an interpolated string such as "count key \(8)"
in Text
, the compiler will consider the string as a LocalizedStringKey
, because Text
has an initializer
init(_ key: LocalizedStringKey, tableName: String? = nil, bundle: Bundle? = nil, comment: StaticString? = nil),
and LocalizedStringKey
conforms to ExpressibleByStringLiteral
and ExpressibleByStringInterpolation
and thus can be implicitly initialized from a string literal or a string interpolation.
Remark 2: If you're not sure what the key is, you can get the answer yourself by po a LocalizedStringKey in the debugger like this:
po LocalizedStringKey("count key \(8)")
Update
Be sure to enable the build setting "Use Compiler to Extract Swift Strings" in your target. This way, when you use other Xcode tools like exporting localizations or the new String catalogs, the compiler can choose the correct format specifiers according to the interpolated value types. It can also identify your localized strings when you use the new String(localized:)
Swift API.