Thank you for this extensive reply! You are right, that a natural english sentence is probably easier to read, but it also doesn‘t give away that it has been localized. What Xcode 13 does, which is powerful, is essentially creating the Localizable strings for you based on your code, which saves a lot of time. However, what I was looking for and what I‘m currently using (hence the snake case keys) is the other way around: At build time, generate Swift Code based on the Localizable.strings and then use Swift code (basically a bunch of nested enums) to access and map the key in Swift. This still doesn‘t help me cover missed translations in other languages but English, but I think that is a powerful way of dealing with Localizations. I‘ll definitely check out the missing localization-api build settings. Thanks! Over the next few days I‘ll also draft out a suggestion and submit feedback for it. Will post the feedback id here then.

Sorry for my late reply. I did not get a notification. I am trying to map all my localizations in code. This means that I access code for accessing localization strings (which internally uses NSLocalizedString). This could be something like: Text(Localization.Bookshelf.Book.text) or Localization.SomeCategory.SomeSection.SomeKey.text. This way it is very descriptive: It tells you the path to the localization, you can query it easily using code completion and internally it translates to: NSLocalizedString("bookshelf_book") or NSLocalizedString(someCategory_someSection_someKey). It also prevents me from using a Localization that no longer exists or has changed, because it would result in a compile time error. Additionally it offers support for other NSLocalizedString parameters: Text(Localization.Bookshelf.Book(comment: "", tableName: "").text. Using the english text does not really work for me for multiple reasons as specified by others below, and you don't get compile time checks for something that is available at compile time.

Hi, thanks for you reply! That‘s great to hear, then I‘m looking for future betas!

Thank you very much for updating me here! I‘ll check it out. Great work :)

Hello, Thank you for your answer! I actually considered using a state variable or a published property in an observable object with a single .musicSubscriptionOffer ViewModifier, however I was worried that I am unnecessarily updating the view by updating the subscription offer options before changing the isShowingSubscriptionOffer and updating the view again. I suppose SwiftUI is smart enough to only rebuild the parts that changed, but this is why I was hesitant to using this approach. I will definitely implement it this way for now, thanks again.

Thanks! That is very cool. However with this approach I am missing two functions. First, I am using the catalog relationship using the "include" parameter to get the catalog identifier of the library artists. Is this possible with this approach, given that the Artists in the MusicItemCollection have the library identifier? I am using the catalog identifier to make a custom request to get the latest "X" amount of albums (sorted by releaseDate) directly from the API Endpoint. If I can load a collection of latest albums (instead of the lastestAlbums property), then I might not need the catalog identifier in the first place.