Idea: use . as a separator to allow nesting

[paulgessinger]

This is just an idea.

For organization, it would be nice to be able to write something like

Text(.localizable.settings.title)

I was wondering if this could not somehow be implemented by splitting the keys found in .xcstrings on the . character, and then generating nested static structs.

Thoughts?

[liamnichols]

Hi @paulgessinger! Thanks for the suggestion.. This is something that I thought about, but in the end I decided that it's not the best option when working with Strings Catalogs for a couple of reasons...

1. It's quite complicated (but not impossible) to have to figure out the hierarchy and then generate additional structs and properties to define the constants and I didn't want to have to write that code 😄

2. As I understood it, one of the recommendations from Apple is to use multiple Strings Catalogs to break out localizations into specific groups and if you were to follow this guidance it ends up working quite well with this tool because you can end up with something like this:

   Text(.settings.title) // ‘title‘ from ‘Settings.xcstrings‘

   Since the constants already manage mapping to the correct strings table for you, as you can see from above, it's very easy to work with strings from across multiple tables.

   Additionally, it's just a hunch, but I think splitting strings across multiple catalogs will eventually end up becoming more popular since a single .xcstrings file contains all of your localizations as well, which is going to mean that the file grows in size relatively quickly (I got some insight on this in Strings Catalogs migrated from .stringsdict don't work #26) and might end up being hard to work with if it's too large.

Do you think that multiple Strings Catalog files would work for you? It would be interesting to know if there are any blockers to that as we might be able to find solutions to them to make it a more convenient option 🙇

[paulgessinger]

Actually, I didn't consider the possibility of using multiple catalogs at all. That seems like a way to make this more manageable and also provide scoping.

[liamnichols]

Yeah, I think coming from .strings, where it was just one Localizable.strings to rule them all (at least it was for every project that I worked on before), it's not the first thing to come to your mind. Especially when you end up with one Localizable.strings for every language 😅

Using multiple catalogs isn't something that i've done myself yet, so i'd be keen to hear how it goes.. I hope there aren't any issues but let me know if there are 🤞