🎤 Speaking at CocoaHeads Stockholm tomorrow (Monday)!
In this talk, I'll show how to use Xcode string catalogs to localize Swift packages and how to build a shared translations package for your entire organization.
See you there! 👇
https://www.meetup.com/cocoaheads-stockholm/events/312313193/?eventOrigin=home_next_event_you_are_attending
@danielsaidi great talk today! Well presented, and a very interesting topic! I've always been a bit unsure how Swift packages, bundles, and localization work together, and you explained it very well.
One thing I'm wondering about is the unfortunate limitation that the generated symbols are internal to their package. Do you know which tool exactly is responsible for this and if Apple is planning to address this issue?
@andrii_ch @danielsaidi I don’t know if this answers your question, but this goes into some detail about the design decisions:
@kristoffer@kristofferjohansson.com that is true. Depending on your project structure you might not get the full benefit. If the symbols were public, fixing a typo in a key or adding a format specifier would break the module’s API and all clients using that symbol though. In code we have tools like deprecation and availability annotations, which we don’t have for strings. If you want to keep your current architecture, you could wrap the internal symbols in a public API. This way you stay in full control over what it exposes as API. Yes, that is more manual work, but makes any breaking change really obvious.
Daniel Saidi
Andrii Chernenko
Kristoffer Johansson