Make integration name translation lazy, fixing #3#65
Make integration name translation lazy, fixing #3#65artulloss wants to merge 2 commits intogetdokan:developfrom
Conversation
WalkthroughThe abstract integration’s get_name now returns a lazily translated string. Individual integration constructors (Custom, Facebook, Google Ads, Twitter) set $this->name to plain literals instead of localized strings. No method signatures changed; overall control flow remains the same. Changes
Sequence Diagram(s)Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🧪 Early access (Sonnet 4.5): enabledWe are currently testing the Sonnet 4.5 model, which is expected to improve code review quality. However, this model may lead to increased noise levels in the review comments. Please disable the early access features if the noise level causes any inconvenience. Note:
Comment |
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