-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose StringCatalog target as a library #48
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the contribution @tricky-vrc!
I did consider exposing the library, but I was a bit hesitant because I wasn't quite sure if I matched the .xcstrings spec properly as it is an undocumented format.
That said, I don't mind doing so if it helps you. Once it matures a bit, I want to consider moving it to its own repository so that it can be versioned correctly, but we can leave that for another day.
Please just look at my small suggestions then I will merge this 🙏
I'm not sure why the tests failed, but perhaps the generated scheme names have changed now that there are multiple products... Please can you double check the scheme name and update .github/workflows/ci.yml? iirc, I think we need to change |
Thanks again @tricky-vrc! I'll merge this now 🙇 |
In some cases you might want to use the xcstrings-tool project to parse string catalogs or create new ones in other command line apps. Swift requires explicitly defining initializers in order to make them public. The test checks that the necessary StringCatalog symbols (for basic StringCatalog operations) are accessible without importing the rest of xcstrings-tool.