[swift-evolution] Localization support for string interpolation
daniel at hoepfl.de
Thu Apr 21 04:31:50 CDT 2016
"\(key)" is already part of Swift (see
Maybe using "<\(quote)> by <\(person)>" as example was not the best
idea, I should have used "“\(quote)” by \(person)". I changed the gist
On 2016-04-21 11:21, Adrian Zubarev wrote:
> I took a quick look at your proposal and one thing I didn’t liked
> was the string itsel: "some text <\(key)>“
> This looks odd to me. I’d suggest something like "some text
> @(key)“ or "some text \[key]“ instead. But it is not up to me.
> Adrian Zubarev
> Am 21. April 2016 bei 09:42:18, Daniel Höpfl via swift-evolution
> (swift-evolution at swift.org) schrieb:
>> Hi there!
>> TL;DR: Here’s my idea for a better localized strings handling in
>> It includes both, support for string interpolation support for
>> NSLocalizedString, and a new string delimiter `...` that can be used
>> instead of NSLocalizedString("...").
>> Markdown hard to read? See
>> # Localization support for string interpolation
>> ## Introduction
>> I'd like to see some kind of advanced localization support in the
>> standard library. Currently all we have is what Cocoa provides but
>> does not work well with string interpolation. More or less, you can
>> use string interpolation if you have to use `NSLocalizedString` and
>> [I implemented a proof of
>> `DHLocalizedString`, that fills this gap. I would like to see
>> similar being part of the Swift standard library. While it is
>> to implement localized strings as a custom library, this lacks
>> from genstring and other tools.
>> I’m not sure if `NSLocalizedString` is considered part of the
>> standard library (being part of Foundation Functions). Since there
>> decent Unicode-string support in Swift, I would like to see
>> as part of the language, too. This proposal also includes a new
>> delimiter `` ` `` that deeply integrate localized strings in the
>> ## Motivation
>> String interpolation greatly simplyfies text handling but makes it
>> to localize. You can not pass a string with interpolation to
>> `NSLocalizedString` because the key could be unpredictable.
>> ## Proposed solution
>> `NSLocalizedString` should be extended to work with string
>> let quote = "Never trust the internet!"
>> let person = "Albert Einstein"
>> print(NSLocalizedString("<\(quote)> by <\(person)>"));
>> should look up the key:
>> ```"<%@> by <%@>" = "%2$@ said: “%1$@”";```
>> and print:
>> ```Albert Einstein said: “Never trust the internet!”```
>> So, `NSLocalizedString` (and friends) would “just work” with
>> interpolation. I’m not sure about the key format to use but my
>> proof of
>> concept simply replaces every interpolation with `%@` which seems
>> The proof of concept also includes an postfix operator `|~` (think
>> of a
>> flag) to reduce the impact localized strings have in line length.
>> Actually, I would love to replace `"` by a different marker (e.g.
>> `~|string|~`, `''string''`, ``` ``string`` ```, or `` `string` ``?)
>> localized strings. Imagine you could write the previous example as:
>> print(`<\(quote)> by <\(person)>`);
>> This syntax needs some work on how to specify `tableName:`,
>> and `comment:`. For `tableName:` and `bundle:`, I'd love to have a
>> construct to specify it for all localization tags within the file
>> `#localization(tableName: ..., bundle: ...)`).
>> If Swift gets multiline strings (`"""string"""`), `` `string` ``
>> also have ```` ```multiline``` ````.
>> ## Impact on existing code
>> I see very little impact. There might be code out there that uses a
>> interpolated string as argument for `NSLocalizedString`. The key
>> used in
>> this case would change, breaking the translation. It would be
>> to include a check for interpolated strings as arguments to
>> `NSLocalizedString` calls in the code update tool.
>> ## Alternatives considered
>> ### Use `NSLocalizedString` as is
>> One can use `NSLocalizedString` as it was used in Objective-C but
>> means that string interpolation cannot be used.
>> ### `localized()` function for String class
>> I did not find a way how to get the function called before the
>> interpolation took place. (`"<\(quote)> by
>> ### Custom function
>> See above: The drawbacks are: Not having support in standard tools
>> the operator syntax not being as good as it could be.
>> swift-evolution mailing list
>> swift-evolution at swift.org
More information about the swift-evolution