I have already give a workable implementation above.
let count = 10
> let says = NSLocalizedString("
> blabla
> \(count)
> blabla
> ", comment: "
> blabla
> ")
to
let says =
> String.localizedStringWithFormat(NSLocalizedString("blabla%@blabla",
> comment: "blabla"), String(count)
When encounter `NSLocalizedString`, Swift looks into its key, if it
s key
contains \(foo), just replace it as
`String.localizedStringWithFormat(NSLocalizedString("blabla%@blabla",
comment: "blabla"), String(foo)`. If not, keep it unchanged.
That is enough.
In current situation, Swift still first calculates the value of string
first, then `NSLocalizedString` work. So it just needs to add a little work
to check if there is any `\(foo)` in the string, instead of calculating
the value of string.
Zhaoxin
On Wed, Nov 2, 2016 at 2:09 PM, Jens Alfke <[email protected]> wrote:
>
> > On Nov 1, 2016, at 10:56 PM, Zhao Xin <[email protected]> wrote:
> >
> > I am not talking to eliminate "%" style function. I am talking to add
> more compatibility to `NSLocalizedString` with `\(foo)` style.
>
> I don’t think the ExpressibleByStringInterpolation protocol provides
> enough information to make this work. It hands the implementation a list of
> values to concatenate, some of which are strings, but as far as I can tell
> there’s no way to tell which of those strings are the pieces of the string
> literal and which of them are the results of expressions. So
> NSLocalizedString would not be able to reassemble the string template that
> you gave it, to look up in the localization table.
>
> If I’m wrong about this, show me a workable implementation of it. :)
>
> Also, ExpressibleByStringInterpolation is marked as being deprecated and
> will be “replaced or redesigned in Swift 4.0.” Maybe to solve this
> limitation?
>
> —Jens
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
