Re: [swift-evolution] Localization support for string interpolation
Hi. On 29.04.16 05:31, Brent Royal-Gordon via swift-evolution wrote: >> – Inserting a number into a sentence often requires adjusting other parts of >> the sentence (nouns, verbs, articles) to the number. And while English has >> only singular and plural, other languages distinguish more cases – up to six >> for Arabic. >> >> – Inserting a name or noun into a sentence often requires adjusting other >> parts of the sentence to the gender of the person or noun. While in English >> gender usually is only reflected in pronouns, its impact is pervasive in >> some other languages. >> >> – Formats for numbers and dates should be specified at a high enough level >> that they can be automatically translated by internationalization libraries. >> For example, don’t specify the order of year, month, day and the characters >> to be used around them; specify just whether you want to have a long or a >> short form and which components, and let an internationalization library >> handle the rest. > > This is all true, but it's also all handled by Foundation on Apple platforms > and hopefully by Corelibs Foundation elsewhere. We ought to be able to hook > into this existing machinery. That's what I think, too: Let Foundation handle the "how to translate", my proposal is just "syntactic sugar". Since I did not see any more concerns about the proposal, I'd like to push my proposal forward. Can anyone give me a hint what to do next? Would sending a pull request be the next step? (The evolution readme just says "Ideas should be thoroughly discussed on the swift-evolution mailing list first." Have we reached this point?) Thanks for your input, Daniel ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [Idea] if let value!
That's the idea of "let?".
"let!" would always execute the block (and crash if the optional is
nil.)
"if let!" is meaningless: "let!" would be true (if the optional is set)
or crash (if the optional is nil).
On 2016-05-18 14:27, Vladimir.S wrote:
The idea to process the 'if' block only if anOptional is not null
In case of
let! anOptional {
}
IMO it is not clear that this block will be executed *only* if
anOptional is not null.
if let! anOptional {
// here only if anOptional != null
}
- seems like similar to standard 'if let' construction so should not
confuse too much and IMO will be remembered after the first
appearance/using.
On 18.05.2016 15:15, Daniel Höpfl via swift-evolution wrote:
Would it be possible to drop the "if"? I don't see why we need it.
On 2016-05-18 11:22, LM wrote:
I am experimenting with this:
If var! anOptional {
anOptional // unwrapped, shadowing
}
if let! anOptional {
... // same
}
This compiler codebase is truly remarkable, so it should also works
with
If var! opt1 where opt1 < 27 {
}
or
if var! opt1, opt2 {
// both unwrapped
}
LM/
On May 18, 2016, at 10:21 AM, Daniel Höpfl via swift-evolution
wrote:
Just an idea: Why don’t we think about it similar to try?
var anOptional : String?
let? anOptional { /* use it, but cannot change it */ }
let! anOptional { /* use it, without checking, cannot change it */ }
var? anOptional { /* use it, can also change it, */ }
var! anOptional { /* use it, without checking, can also change it */
}
Is it allowed to set it to nil in the var case? Hard to say.
On 17.05.16 15:43, Vladimir.S via swift-evolution wrote:
It is common to shadow optional value name with unwrapped value
with
same name:
if let someGoodValue = someGoodValue {...}
What if we'll have a syntax to not repeat the variable name to
achieve
the same target:
if let someGoodValue! {...}
What do you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [Idea] if let value!
Would it be possible to drop the "if"? I don't see why we need it.
On 2016-05-18 11:22, LM wrote:
I am experimenting with this:
If var! anOptional {
anOptional // unwrapped, shadowing
}
if let! anOptional {
... // same
}
This compiler codebase is truly remarkable, so it should also works
with
If var! opt1 where opt1 < 27 {
}
or
if var! opt1, opt2 {
// both unwrapped
}
LM/
On May 18, 2016, at 10:21 AM, Daniel Höpfl via swift-evolution
wrote:
Just an idea: Why don’t we think about it similar to try?
var anOptional : String?
let? anOptional { /* use it, but cannot change it */ }
let! anOptional { /* use it, without checking, cannot change it */ }
var? anOptional { /* use it, can also change it, */ }
var! anOptional { /* use it, without checking, can also change it */ }
Is it allowed to set it to nil in the var case? Hard to say.
On 17.05.16 15:43, Vladimir.S via swift-evolution wrote:
It is common to shadow optional value name with unwrapped value with
same name:
if let someGoodValue = someGoodValue {...}
What if we'll have a syntax to not repeat the variable name to
achieve
the same target:
if let someGoodValue! {...}
What do you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] [Idea] if let value!
Just an idea: Why don’t we think about it similar to try?
var anOptional : String?
let? anOptional { /* use it, but cannot change it */ }
let! anOptional { /* use it, without checking, cannot change it */ }
var? anOptional { /* use it, can also change it, */ }
var! anOptional { /* use it, without checking, can also change it */ }
Is it allowed to set it to nil in the var case? Hard to say.
On 17.05.16 15:43, Vladimir.S via swift-evolution wrote:
> It is common to shadow optional value name with unwrapped value with
> same name:
>
> if let someGoodValue = someGoodValue {...}
>
> What if we'll have a syntax to not repeat the variable name to achieve
> the same target:
>
> if let someGoodValue! {...}
>
> What do you think?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Localization support for string interpolation
On 24.04.16 23:33, Chris Lattner wrote:
>
>> On Apr 21, 2016, at 12:42 AM, Daniel Höpfl via swift-evolution
>> wrote:
>>
>> Hi there!
>>
>> TL;DR: Here’s my idea for a better localized strings handling in Swift.
>> It includes both, support for string interpolation support for
>> NSLocalizedString, and a new string delimiter `...` that can be used
>> instead of NSLocalizedString("...”).
>
> FWIW, this is closely related to the idea of extending string interpolation
> to support generalized “printf” style modifiers, which would allow very
> expressive formatting inline in a string interpolation. This has not yet
> come to pass, but a write up of the ideas are available here:
> https://github.com/apple/swift/blob/master/docs/TextFormatting.rst
As I understand it, TextFormatting is focused on what happens inside the
interpolation brackets. The localization support has its focus on the
string parts outside the brackets.
I left out how to localize the parts inside the brackets on purpose
because that always involves developer’s decision. How to find the
translation of the string parts does not have to.
My proposal is just a Swiftyfied version of NSLocalizedString and, as
TextFormatting says: "Cocoa programmers can still use Cocoa localization
APIs for localization jobs"
So: Yes, these two proposals are related but IMO not that closely.
Greetings,
Daniel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Localization support for string interpolation
On 21.04.16 18:29, Uli Kusterer wrote: > Yeah, idea here is principle of least surprise. Most lcoalization > tools pre-populate the translations with the keys, so having the > positional indices in there would mean nobody forgets it and then > gets back a translation with the contents reversed If you want to play around with it, I added a branch in the proof of concept repo that uses positional arguments in the keys. > (admittedly, since > you're using the same %@ format for everything, at least your code > won't crash. In ObjC, if someone swapped out a %@ and a %d, you got > some "hilarious" results). Correct. While it is possible to use different placeholders (%d, %f, ...) depending on the type of the interpolation argument, I don't think it is worth it. What you said is one reason, then it makes genstrings harder since finding the type requires to parse more than just the string and while there might be cases where you want to have e.g. "%+17.3f" in the translated text, you normally should use a (localized) formatter here anyways, so always having the description() here is probably okay and makes the keys/translations more consistent. Greetings, Daniel ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Localization support for string interpolation
On 2016-04-21 12:41, Uli Kusterer wrote:
[...]
One request: Could you perhaps use positional syntax? In some
languages, the word order of the placeholders needs to change, and
there needs to be a way to detect that the translator swapped two
placeholders. In NSLocalizedString, that is done via %1$@, %2$@.
Using it in the translated string already works (see test cases).
I assume you want it to be part of the key? Like:
DHLocalizedString("first: \("a"), second: \("b")")
Localizable.strings:
"first: %1$@, second: %2$@" = "vor %2$@ kommt %1$@";
Then one would have to change
.
Could be done but I'm not sure if I'd like to have to include the
position in the key, even if there is only one argument. Could be an
exception, of course.
Greetings,
Daniel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Localization support for string interpolation
Sorry, I don't see the problem.
< and > are considered normal characters, that's fine.
The trick of DHLocalizedString is that it does not do the string
interpolation. This is already handled by Swift.
If you call DHLocalizedString("<\(quote)> by <\(person)>"), the compiler
generates something like:
DHLocalizedString(DHLocalizedStringStore("<",
quote.description(),
"> by <",
person.description(),
">"),
tableName = nil,
bundle = nil)
DHLocalizedString concats the strings (stored in the
DHLocalizedStringStore), replacing every even position by "%@". The
resulting string is used as format argument of NSLocalizedString, using
the even positions of the array as arguments. DHLocalizedString does not
care about the contents of any of the strings parts.
All of this works because Swift always starts interpolated strings with
a string literal, "\(4)" becomes ["", "4", ""] (not sure if it adds the
empty string at the end, too). The parts that come from interpolation
are always in the even positions.
My proposal has two parts:
a) Make NSLocalizedString work like DHLocalizedString does.
b) Make `xxx` a synonym to NSLocalizedString("xxx") (and give me a way
to set the default values for tableName/bundle in this case)
On 2016-04-21 12:23, Adrian Zubarev via swift-evolution wrote:
I know that :D I mean < and > are considered as normal characters of
the string "<\(quote)> by <\(person)>“ so thats why this won’t
work that way.
--
Adrian Zubarev
Am 21. April 2016 bei 11:32:05, Daniel Höpfl via swift-evolution
(swift-evolution@swift.org) schrieb:
Maybe using "<\(quote)> by <\(person)>"
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Localization support for string interpolation
Hi Adrian,
"\(key)" is already part of Swift (see
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/StringsAndCharacters.html#//apple_ref/doc/uid/TP40014097-CH7-ID285>).
Maybe using "<\(quote)> by <\(person)>" as example was not the best
idea, I should have used "“\(quote)” by \(person)". I changed the gist
accordingly.
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@swift.org) schrieb:
Hi there!
TL;DR: Here’s my idea for a better localized strings handling in
Swift.
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
<https://gist.github.com/dhoepfl/203f8b9bb8014593772a3b12d807ebce>
Greetings,
Daniel
# Localization support for string interpolation
## Introduction
I'd like to see some kind of advanced localization support in the
Swift
standard library. Currently all we have is what Cocoa provides but
that
does not work well with string interpolation. More or less, you can
not
use string interpolation if you have to use `NSLocalizedString` and
friends.
[I implemented a proof of
concept](https://github.com/dhoepfl/DHLocalizedString),
`DHLocalizedString`, that fills this gap. I would like to see
something
similar being part of the Swift standard library. While it is
possible
to implement localized strings as a custom library, this lacks
support
from genstring and other tools.
I’m not sure if `NSLocalizedString` is considered part of the
Swift
standard library (being part of Foundation Functions). Since there
is
decent Unicode-string support in Swift, I would like to see
localization
as part of the language, too. This proposal also includes a new
string
delimiter `` ` `` that deeply integrate localized strings in the
language.
## Motivation
String interpolation greatly simplyfies text handling but makes it
hard
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
interpolation:
```swift
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
string
interpolation. I’m not sure about the key format to use but my
proof of
concept simply replaces every interpolation with `%@` which seems
reasonable.
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` ``?)
for
localized strings. Imagine you could write the previous example as:
```swift
print(`<\(quote)> by <\(person)>`);
```
This syntax needs some work on how to specify `tableName:`,
`bundle:`,
and `comment:`. For `tableName:` and `bundle:`, I'd love to have a
construct to specify it for all localization tags within the file
(e.g.
`#localization(tableName: ..., bundle: ...)`).
If Swift gets multiline strings (`"""string"""`), `` `string` ``
could
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
possible
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
this
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
string
interpolation took place. (`"<\(quote)> by
<\(person)>".localized()`)
### Custom function
See above: The drawbacks are: Not having support in standard tools
and
the operator syntax not being as good as it could be.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] Localization support for string interpolation
Hi there!
TL;DR: Here’s my idea for a better localized strings handling in Swift.
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
Greetings,
Daniel
# Localization support for string interpolation
## Introduction
I'd like to see some kind of advanced localization support in the Swift
standard library. Currently all we have is what Cocoa provides but that
does not work well with string interpolation. More or less, you can not
use string interpolation if you have to use `NSLocalizedString` and friends.
[I implemented a proof of
concept](https://github.com/dhoepfl/DHLocalizedString),
`DHLocalizedString`, that fills this gap. I would like to see something
similar being part of the Swift standard library. While it is possible
to implement localized strings as a custom library, this lacks support
from genstring and other tools.
I’m not sure if `NSLocalizedString` is considered part of the Swift
standard library (being part of Foundation Functions). Since there is
decent Unicode-string support in Swift, I would like to see localization
as part of the language, too. This proposal also includes a new string
delimiter `` ` `` that deeply integrate localized strings in the language.
## Motivation
String interpolation greatly simplyfies text handling but makes it hard
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 interpolation:
```swift
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 string
interpolation. I’m not sure about the key format to use but my proof of
concept simply replaces every interpolation with `%@` which seems
reasonable.
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` ``?) for
localized strings. Imagine you could write the previous example as:
```swift
print(`<\(quote)> by <\(person)>`);
```
This syntax needs some work on how to specify `tableName:`, `bundle:`,
and `comment:`. For `tableName:` and `bundle:`, I'd love to have a
construct to specify it for all localization tags within the file (e.g.
`#localization(tableName: ..., bundle: ...)`).
If Swift gets multiline strings (`"""string"""`), `` `string` `` could
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 possible
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 this
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 string
interpolation took place. (`"<\(quote)> by <\(person)>".localized()`)
### Custom function
See above: The drawbacks are: Not having support in standard tools and
the operator syntax not being as good as it could be.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
