-
Notifications
You must be signed in to change notification settings - Fork 120
Configure localization automation for Widgets extension #7691
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
Conversation
This is not required but is still recommended to avoid translation context clashes.
It enforces them only in app extensions targets which currently means only StoreWidgets.
d156101 to
aa1416d
Compare
| ], | ||
| exclude: [ | ||
| '*Vendor*', | ||
| '**/AppLocalizedString.swift', |
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.
We don't want to localize the localization routine as that would create issues.
This makes me wonder if we should update the format for the routines to:
routines: [
{ name: 'AppLocalizedString', path: 'path/to/file.swift' }
],And then handle excluding that path within the toolkit.
Gold plating...
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.
I think that's a laudable idea but might not be flexible enough to all our codebases that are not as clean as WP or WC and might e.g. still want to adopt the linter and also have a custom routine already in place, but just not in a dedicated .swift file containing only that. etc.
So in the end it might end up coupling the routine name and its assumption of it being isolated into a single file a bit too much. Besides, in some codebases or in the future, the file where the routine is declared might end up being already excluded because provided by a SPM plugin or a Pod that would already be excluded from parsing 🤷
Ultimately I'm not sure it's worth doing a breaking change (due to parameter type change) on the release-toolkit just for this 😅
| let colNo = line.distance(from: line.startIndex, to: range.lowerBound) | ||
| let message = """ | ||
| Use `AppLocalizedString` instead of `NSLocalizedString` in source files that are used in the `\(targetName)` extension target. See paNNhX-nP-p2 for more info. | ||
| """ |
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.
I wrote in the description that I basically copied 1-1 the WordPress setup. This is an instance in which I didn't.
In WordPress, this is a string defined with "...". I used this format here because SwiftLint (which runs as a build phase in Woo) picked this up as a line that was too long.
I originally had this as a proper multiline string
let message = """
Use `AppLocalizedString` instead...
See paNNhx...
"""But Xcode only printed the first line of the string in its error bubble...
AliSoftware
left a comment
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.
👌 Looking good from the GitHub diff.
Tbh I didn't take the time to test it myself but I trust that the tests you made and described in your PR description, highlighting that this still detected new strings and also that the linter caught issues, are enough to consider this to be working as expected 👍
![]()
|
Ah, CI is failing… because the linter found an issue! So I ended up checking out the branch and testing locally after all, and confirmed that I have the same error found by the linter locally: (Probably because #7682 got recently merged while you opened this PR prior this change in |
|
PS: Unrelated to this PR, but just wanted to note that while testing this PR I saw Xcode warnings about a @mokagio you might want to take a look at this one next in separate PR. |
|
Thanks! I did not know that we had to use |
Well this is exactly the new thing that this PR will introduce, so no wonder you haven't seen it yet in the main WooCommerce target 😄 Basically this will now be necessary now that WooCommerce has an app extension target (the new Widget), to avoid duplicating strings in multiple products (
|
How cool is that! 😄 I'm not sure how I missed it while working on this locally, though. I obviously tested it locally before opening the PR, as can be seen by the screenshot in the description 🤔
That might be it and I didn't run the tests locally before force pushing my rebase on a Oh well, that's why we have CI... |
Generated by 🚫 dangerJS |
c1bbf82 to
4874e1e
Compare
You can test the changes from this Pull Request by:
|



Description
The widgets extension needed only a few finishing touches to complete the localization automation. Namely:
AppLocalizedStringroutine to ensure the runtime can read the localization from the correct bundleAppLocalizedStringis usedI basically copied the WordPress iOS setup 1-to-1.
Testing instructions
Localization automation
I run
bundle exec fastlane generate_strings_file_for_glotpresson top of this branch and verifieden.lproj/Localizable.stringswas updated accordingly.Xcode build phase
Changed one
AppLocalizedStringusage toNSLocalizedStringand verified Xcode failed the build with an informative error:RELEASE-NOTES.txtif necessary.