Make integration name translation lazy, fixing #3 #65
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This change updates the way integration names are translated to comply with WordPress 6.7’s stricter translation-loading rules.
Previously the class constructors used
__()directly on thenameproperty. That triggered_load_textdomain_just_in_timenotices because it forced translations beforeinit. WordPress 6.7+ logs these as warnings.What Changed
get_name()method that translates the stored source string lazily.'Twitter') instead of a translated one.$integration->get_name()so translations are loaded at the right time.Why
These notices have been spamming my debug logs, and my marketer unfortunately uses this plugin. This solution keeps the strings translatable without triggering warnings in WordPress 6.7+.
Impact
get_name()rather than reading the protected$nameproperty directly.Summary by CodeRabbit
Bug Fixes
Refactor
Chores