EDIT: I'm now +0.75 on this, after @GetSwifty's clarification on Foundation's localization rules
I would still like to see
defaultLocalization become required, rather than be optional as I haven't seen a strong argument why it would be optional and leave the possibility of compile errors.
I'm +0.5 on this.
Add a new optional
defaultLocalization parameter to the
Package initializer to define the default localization for the resource bundle. The default localization will be used as a fallback when no other localization for a resource fits the runtime environment. SwiftPM will require that parameter be set if the package contains localized resources.
I find it awkward that we are using Swift as the language of our Package manifest, which gives a ton of compile-time guarantees, but we having a runtime enforcement of an optional parameter if a parameter is provided elsewhere in the Package definition (any Target).
If, as I mentioned in the pitch thread, we always require the
defaultLocalization, every developer building their first project with resources won't encounter that error.
It also provides the added benefit of communicating to other developers what the primary development language of a package is.
This leads to a large question I have with how Package dependencies will work together through this feature. (Perhaps these are answered by well-defined practices in the Foundation Bundle APIs that I lack experience with)
How do package dependencies work together for resolving a localization request based on their independent
Package A: defaultLocalization = "de" // also supports 'en'
Package B: defaultLocalization = "fr" // also supports 'en'
Root Project C: defaultLocalization = "en"
B depends on A
C depends on B
// none support 'ru' localization
a. If the root project calls code from 'B' for
ru localization, will
fr be the fallback?
b. If, during the call of 'B' code for
ru, 'B' also calls 'A', which will be the fallback?
Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?
Yes, this is a large piece of support Package resources - especially in user-facing applications.
Does this proposal fit well with the feel and direction of Swift?
Given that SE-0271 has already been accepted as part of the Swift project, this feels like a natural evolution (aside from the point I made above).
If you have used other languages, libraries, or package managers with a similar feature, how do you feel that this proposal compares to those?
The proposed solution is an automated implementation of standard practices I've seen in other ecosystems.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I followed the proposal during the pitch phase, but have not used the provided implementation.