Stop translating goal, event and funnel names - #329
Conversation
The names identify the goals and funnels in Plausible, but were wrapped in __(). When the French translations of these strings were updated on translate.wordpress.org (17 Sep 2026), fr_FR sites started sending e.g. "Achat WooCommerce finalisé" instead of "Woo Complete Purchase": each goal's data was split in two and revenue silently stopped being recorded, as the translated purchase goal isn't a Revenue goal. It was already inconsistent before that: the goals for cloaked links, search queries and query parameters were created with the translated names, while the JS sends their events under the English names, so on a translated site those goals never converted. And goals are provisioned in the admin's (user) locale, while events are sent in the site's locale. Use the English names as plain strings for the WooCommerce and EDD events, the custom event goals, the form completions event and the funnel names. French sites then send their events to the original (English) goals again, which still exist, including the Revenue goal. Fixes #326
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (10)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughEvent-goal and funnel names now use fixed English strings instead of WordPress translations. Integration tests check that translation filters do not change selected event-goal names. The changelog describes the French-site case. ChangesStable goal and funnel names
Priority: ➖ Normal Change: Bug fix · Severity of issue fixed: Medium Merge Risk: ⚪ Minimal · up to The changed identifiers remain consistent between provisioning and event tracking. No material merge-blocking risk is evident. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to Fixed names should keep events aligned with their analytics goals across languages. On sites with previously translated goals, disabling an integration may leave those older goals behind. No new access path or privilege was identified. Retained concerns
Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
Resilience and Maintainability Implications
Hardening Proposals
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Sites whose goals were created under translated names (French 2.6.1 sites that connected after 17 Sep 2026 only have French goals) send their events under the English names as of 2.6.2, but the plugin only created those goals on the next settings save, leaving e.g. purchases without a Revenue goal until then. upgrade_to_262() now (re)creates the custom event goals for every install, and the funnels for every ecommerce install, not only multilingual ones. Both are get-or-create, so existing goals and funnels are left unchanged. Also read the base currency for a new Revenue goal from WooCommerce's setting instead of get_woocommerce_currency(): multicurrency plugins filter the latter to the currency of the current request (WCML returns the visitor's currency in AJAX requests, e.g. the Action Scheduler requests that can run the upgrade), so the goal's currency depended on whichever request happened to provision it.
Fixes #326.
Goal, event and funnel names identify the goals and funnels in Plausible, but were wrapped in
__(). When the French translations of these strings were updated on translate.wordpress.org (17 Sep 2026), fr_FR sites started sending e.g.Achat WooCommerce finaliséinstead ofWoo Complete Purchase. Each goal's data was split in two, and revenue silently stopped being recorded, because the translated purchase goal isn't a Revenue goal.Also broken before that
'Cloaked Link: Click','WP Search Queries','WP Query Parameters'). On a translated site those goals never converted.Changes
Provisioning), the form completions event and the funnel names are now plain English strings, with a comment explaining why they mustn't be translated. Labels in the settings screen stay translatable.develop).Impact on existing sites
Only French translates these strings (checked fr, de, nl, es, it, pt-BR, ja, pl, sv, da, nb, ru, tr and zh-CN). On French sites, events are sent to the original English goals again, which still exist, including the Revenue goal. So the history before 17 September reconnects and revenue is recorded again; only the period since then stays split. Goals and funnels created with the French names (on a settings save after 17 September) are left alone: they're harmless, and the changelog tells site owners they can remove them.
Testing
developAjout au panier WooCommerceDébut de la commande WooCommerceWoo Add to CartWoo Start CheckoutWoo Complete Purchasewith revenueSummary by CodeRabbit
Upgrade routine
French 2.6.1 sites that connected after 17 September only have goals with French names. As of 2.6.2 they send their events under the English names, but those goals would only be created on the next settings save, leaving purchases without a Revenue goal until then.
upgrade_to_262()now (re)creates the custom event goals for every install and the funnels for every ecommerce install (previously only multilingual ones). Both are get-or-create, so existing goals and funnels are left unchanged.Base currency of a new Revenue goal
Helpers::get_currency_for_language()fell back toget_woocommerce_currency(), which multicurrency plugins filter to the currency of the current request: on the test site WCML returned USD from wp-cli and EUR in AJAX requests (e.g. Action Scheduler's, which can run the upgrade), while the store's base currency is EUR. It now reads WooCommerce'swoocommerce_currencysetting, so a new Revenue goal's currency no longer depends on which request provisions it. Existing purchase goals keep their currency, as before.Testing (upgrade)
admin-ajax.phprequest, and when run from wp-cli, where WCML reports USD: the Revenue goal is created in the store's base currency (EUR).develop(it returns the filtered currency).