Comments (8)
Perhaps this ends up being the best way to achieve it:
func localizable(_ localizable: String.Localizable) -> LocalizedStringResource {
LocalizedStringResource(localizable: localizable) // < This initializer would need to be exposed
}
func localizable(_ localizable: String.Localizable) -> LocalizedStringKey {
"\(LocalizedStringResource(localizable: localizable))"
}
Text(localizable(.key))
.navigationTitle(localizable(.myDeviceVariant))
Label(localizable(.myPlural(1)), systemImage: "test")
I'm not a huge fan of the global functions, but it seems like it might make it easier than having to generate multiple sets of constants for different types.
from xcstrings-tool.
Ok i'll close this for now.
Just a heads up, #82 introduces a LocalizedStringKey.init(localizable:)
initalizer alongside the Text
one. I'm also taking the conversation/idea about the localizable(_:)
global functions to #81 👍
from xcstrings-tool.
Hi @IgorMuzyka, good question! In the initial release, I was keeping things focused entirely on LocalizedStringResource
since this was kind of advertised as the future in the WWDC session video.
As you pointed out though, there is lots of SwiftUI that doesn't provide initialisers/api for this which leads to you having to work around it like the example above.
I think that it's easy enough to add the extension that you mentioned, so I'll leave that to you because it'll only iOS 16+ and I hope that Apple will improve things later by adding more APIs that work with LocalizedStringResource
.
That said, we're working on some more backwards compatible improvements for SwiftUI in #60 which might help you. They are designed to be backwards compatible though, which requires them to work through Text
at the core but we should be able to provide extensions on all types that can go alongside LocalizedStringKey
based initialisers.
Have a look at that ticket and see if you think that the approach will help you or not 🙇
from xcstrings-tool.
@liamnichols thanks for speedy reply, that pretty much answers my question.
Not supporting iOS<16
and macOS<13
.
Sure i'll manage to extend this to fit my needs.
Can i ask you to validate that the following examples are a correct use of generated code?
Notice: they all work as expected; at the moment i only have English localization(unsure if this won't break when more added).
// Example 1
let panel = NSSavePanel()
panel.title = String(localizable: .exportSavePanelTitle)
panel.nameFieldLabel = String(localizable: .exportSavePanelNameFieldLabel)
// Example 2
let adjustPhotoAccessMessage: LocalizedStringKey = .init(
String(localizable: .libraryAccessRestrictedAdjustMessage(settingsLink))
)
And one more followup question.
If i would make a fork, which files should i adjust to change the generated Localizable.swift
?
from xcstrings-tool.
Ah I see, I think that I misunderstood your initial question. At first, I thought that you just wanted something like this:
extension LocalizedStringKey {
init(localized: LocalizedStringResource) {
self = "\(localized)"
}
}
// Usage
Button(.init(localized: .localizable.myKey)) {
flag.toggle()
}
But it sounds like you are actually suggesting a series of constants on LocalizedStringKey
just like we generate for LocalizedStringResource
, which would give you constants such as LocalizedStringKey.localizable.myKey
?
I think that the problem with ☝️ is that it would break the type inference that allows a syntax like this:
Text(.localizable.myKey)`
Because the above example would be ambiguous since the compiler wouldn't know if you meant Text(LocalizedStringResource.localizable.myKey)
or Text(LocalizedStringKey.localizable.myKey)
.
Example 1 is correct usage, but example 2 is now. For example 2, by using String(localizable: .libraryAccessRestrictedAdjustMessage(settingsLink))
you are first resolving the localization using the system/app language (not from the SwiftUI environment) and you are missing out on other built in features, such as markdown rendering for bold/italic etc.
Using "\(.libraryAccessRestrictedAdjustMessage(settingsLink))"
instead would cause the LocalizedStringKey
to keep hold of the LocalizedStringResource
(not the resolved localization) until the point of rendering, which would allow Text
to use the Locale
from the SwiftUI environment and then to apply markdown formatting etc.
If i would make a fork, which files should i adjust to change the generated Localizable.swift?
All the magic happens in StringGenerator.swift, but I would avoid forking the current code on main
right this moment because I'm shortly going to push a massive refactor to it.
from xcstrings-tool.
With #60, we plan to add the following extension to Text
:
extension Text {
init(localizable: String.Localizable)
}
This will be compatible right back to iOS 13 and would allow the following usage:
Text(localizable: .myKey)
Which is great, but it's constrained to Text
only so in the many places where SwiftUI provides the LocalizedStringKey
convenience initialisers, it would be useless. For example:
public func navigationTitle(_ titleKey: SwiftUI.LocalizedStringKey) -> some SwiftUI.View
Instead, you'd have to use the Text
-based modifier:
public func navigationTitle(_ title: SwiftUI.Text) -> some SwiftUI.View
In the Xcode 15.2 .swiftinterface file, I see 160 occurrences of _ titleKey: SwiftUI.LocalizedStringKey
, so there are a lot of these convenience initialisers/modifiers 🙈
In theory, I guess that we could also generate our own versions, such as the following:
public func navigationTitle(localizable: String.Localizable) -> some View {
navigationTitle(Text(localizable: localizable))
}
// Usage:
navigationTitle(localizable: .myKey)
It would be nice, but might bloat the generated code a bit. Perhaps it could be something hidden behind a toggle though.
from xcstrings-tool.
@liamnichols you might be correct about me missing out on markdown formatting, but the thing is when i need formatting it's either already in Localizable.xcstrings
or done via string interpolation as suggested. This seems to work correctly as long as i wrap everything at the end with LocalizedStringKey
.
I see that your approach is to extend Text
and go from there. However my only interest in this library is with producing constants and utilizing them with LocalizedStringKey
.
Besides Text
i also use Label
, so as you might have pointed out extending initializers for SwiftUI
are work intensive and pointless , when we can just hand over localizable to LocalizedStringKey
or Text
.
from xcstrings-tool.
@liamnichols i think i'll live with interpolation for now, nothing inherently wrong with using it.
You can close this issue, questions exhausted.
And many thanks for implementing this tool and answering questions swiftly.
from xcstrings-tool.
Related Issues (20)
- Integrating XCStrings Tool into a Swift Package Target has wrong package git url HOT 2
- ExtractionState config HOT 3
- Demonstrate use of language overrides in documentation HOT 3
- Feature Suggestion: Support to other build systems HOT 1
- Default values with UnsafeRawPointers do not compile HOT 4
- Ensure that snapshots compile
- Multiple commands produce generated source when working with embedded watchOS app HOT 5
- Generate.swift in the Release files look different HOT 3
- Support SwiftSyntax 5.10
- Improve SwiftUI support on iOS 15 HOT 16
- String containing a single `%` is parsed incorrectly HOT 1
- Duplicates in Localizable.xcstrings in 0.2.0 HOT 9
- Set default value to be fallback documenting comment HOT 2
- How to use with Github Actions? HOT 3
- Duplicate accessors generated in extensions on both `String` and `LocalizedStringResource`
- Support deferred formatting
- Generated @available has trailing whitespace HOT 5
- Build errors after updating from 0.4.1 to higher version HOT 3
- Add note to documentation about unwanted target dependencies
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xcstrings-tool.