AndyIf you localize your app, I recommend checking out our talk!
I speak about getting started with localization, but then quickly advance into our two big features this year:
Generated comments, and Swift symbols for manually added strings.
Xcode 26 can help you write helpful comments for extracted strings. This will help translators with context.
Additionally, loading localized strings from a String Catalog is now as easy as calling a function in Swift: Button(.orderButtonTitle)
Auto completion suggests your table name and all manual strings contained in this table!
Additionally, loading localized strings from a String Catalog is now as easy as calling a function in Swift: Button(.orderButtonTitle)
Auto completion suggests your table name and all manual strings contained in this table!
Ryan Booker@Klarname love the strong catalog changes this year.
If you already have a catalog with keys generated from something like XCSTringsTool is there a good way to convert to the new in built system?
@ryanbooker Thank you!
Find & replace is probably the best option, sorry.
Maybe if you remove the accessors generated by XCStringsTool, and let the compiler warnings guide you to where you use a generated symbol by Xcode? Then you go through them and insert the new symbol names, which should be straight forward thanks to auto completion.
@Klarname thanks. That’s what I’m doing. Was hoping for something easier. 🤣
Will that also make the strings become auto managed?
@ryanbooker no, either strings are extracted in code and kept in sync (“automatically managed” incl. comment generation), or you add them in the String Catalog (“manually managed”) and you can change key, value, remove them, and use their generated symbols.
@Klarname ah ok so even if you start with a managed file, if you refactor and hit convert to symbols it becomes manual?
@ryanbooker wait I’m confused now.
Manual strings can be referenced via their key as string in code, or by using the new generated Swift symbol.
Automatic strings usually make their way into the string catalog via extraction from code. They can also be “referenced” via their key, as string in code (so technically a separate string, extracted, and then merged to the other extracted copy).
So when you start with a manually managed string and refactor to use symbols, it stays manually managed.
If you refactor an automatically managed string to be referenced via symbol, it becomes manually managed.
@Klarname great. Thanks. I think that makes sense. 😃
fruitcoder 🍒🍉@Klarname Is there any way to change the access modifier of the generated LocalizedStringResource symbol? I like to package my resources in a dedicated SPM target and would have hoped to be able to finally bury SwiftGen 🙂 (Strings are accessed from package consumers not in the package itself)
@fruitcoder That is currently not possible, no.
The ideal workflow is one where strings are defined and used in the same module, sharing them across bundles complicates everything.
Changing a key’s spelling, fixing a typo, or adding a format specifier in the String Catalog would break the API of your module if the symbols were public. We didn’t want to introduce that footgun.
Code has deprecation and availability annotations to help with breaking changes, but strings don’t have that.
If you want to keep that project setup consider wrapping your internal symbols in public API. This way it’s obvious that any changes cause clients to break.
It’s more manual work, but because these are obvious changes to public functions, it should make you think about clients.