Hi @galapogos01,
Thanks for bringing this up.
At the moment, we don’t have any updates to share regarding a transition away from the current SkyVerge translation framework used within the Braintree for WooCommerce plugin.
Since generating PHP translation files via wp i18n make-php would be overwritten on plugin updates, this isn’t something we’d recommend as a long-term workaround.
That said, we appreciate you flagging this. If you have any performance impact metrics or specific issues you’ve observed as a result of this, feel free to share them here; it would help us better understand the scope and potential impact.
We’ll keep this in mind for future improvements to the plugin.
Thread Starter
Jason
(@galapogos01)
Every page load is impacted by this plugin not using php translations.
This change was introduced to Core in 6.5 (2 years ago). You can see the performance improvements at https://make.ww.wp.xz.cn/core/2024/02/27/i18n-improvements-6-5-performant-translations/
A plugin managed by Automattic not adhering to its own performance guidelines should be a pretty high priority.
Hi there!
I can understand your concern. To assist you further, Could you please share the report or profiling data showing how this plugin is causing the performance issue? This will help us better understand the impact and allow us to manually escalate your suggestion internally if needed.
Thank you for cooperation and understanding.
Thread Starter
Jason
(@galapogos01)
Hello,
I am not prepared to post a full profiling output on a public forum, but the summary is:
Braintree SkyVerge .mo Translation – Actual Source Line Numbers
File: wp-content/plugins/woocommerce-gateway-paypal-powered-by-braintree/vendor/skyverge/wc-plugin-framework/woocommerce/class-sv-wc-plugin.php The Functions and Line Numbers:
Lines 384-395 (approx): load_framework_textdomain()
php
protected function load_framework_textdomain() {
$this->load_textdomain( 'woocommerce-plugin-framework', dirname( plugin_basename( $this->get_framework_file() ) ) );
}
Lines 395-410 (approx): load_plugin_textdomain()
php
protected function load_plugin_textdomain() {
$this->load_textdomain( $this->text_domain, dirname( plugin_basename( $this->get_plugin_file() ) ) );
}
Lines 410-438 (approx): load_textdomain() – The hardcoded .mo line
php
protected function load_textdomain( $textdomain, $path ) {
// user's locale if in the admin for WP 4.7+, or the site locale otherwise
$locale = is_admin() && is_callable( 'get_user_locale' ) ? get_user_locale() : get_locale();
$locale = apply_filters( 'plugin_locale', $locale, $textdomain );
// THIS IS THE HARDCODED .mo LINE - approximately line 430-435
load_textdomain( $textdomain, WP_LANG_DIR . '/' . $textdomain . '/' . $textdomain . '-' . $locale . '.mo' );
}
Summary:
The hardcoded .mo extension is in the load_textdomain() method around line 430-435 of class-sv-wc-plugin.php.
To fix it (not recommended): You’d need to change that line to use WordPress’s modern function that auto-detects .l10n.php vs .mo:
php
// Instead of:
load_textdomain( $textdomain, WP_LANG_DIR . '/' . $textdomain . '/' . $textdomain . '-' . $locale . '.mo' );
// Use:
load_plugin_textdomain( $textdomain, false, $path );
Hi there!
Thank you for the update. I’ll share this with our development team, and if we receive any updates from them, we’ll be sure to let you know accordingly. Thank you.
Thread Starter
Jason
(@galapogos01)
Hi it’s been two weeks, any response from the development team?
Is there a better place to raise a tech issue?
Hi @galapogos01,
Thanks for the follow-up!
I checked and see that a bug issue was created and have pinged for an update. Once we get one, we’ll notify you.
Hang in there.
Hi there!
This is a follow-up message to inform you that, currently, there is no ETA for when the issue will be fixed. Our developers are actively working on a solution, and we hope it will be resolved as soon as possible.
Thank you for cooperation and understanding.
It seems we haven’t heard back from you for a while, so I’ll go ahead and mark this thread as resolved. Feel free to reach out whenever you’re ready to continue.
We’d love your feedback – please leave us a review: https://ww.wp.xz.cn/support/plugin/woocommerce-gateway-paypal-powered-by-braintree/reviews/
Thread Starter
Jason
(@galapogos01)
Why are you closing this? It’s not fixed!!
Please get a response from your dev team with an ETA.
This is ludicrous!
Cheers, Jason
Hi there,
I completely understand your frustration here, and I’m sorry for the inconvenience this issue is causing.
To clarify, the issue has not been dismissed the bug has already been reported internally, and our development team is aware of it and actively investigating. At the moment, however, we don’t have an estimated time of arrival (ETA) for when a fix will be released. As soon as progress is made or a fix becomes available, it will be included in a future WooCommerce update and noted in the changelog.
Regarding the forum thread being marked as resolved:
In the support forums, threads are often closed once the issue has been confirmed, documented, and escalated internally. This helps us keep the forums organized and allows our developers to track the problem through our internal system rather than the forum itself. Closing the thread does not mean the issue is fixed or ignored only that further updates will come via product updates rather than ongoing forum replies.
We truly appreciate you taking the time to report this and your patience while our developers work on it.
Thread Starter
Jason
(@galapogos01)
I kindly ask you to please leave this thread open until the plugin developers have committed a fix and it’s been tested.
There are many reasons the thread should remain unresolved; the principal one is that the problem is unresolved and my question raised here is also unresolved. There is no workaround and we are still dealing with the impact.
Thanks,
Jason
Hi @galapogos01,
We’ve reopened the thread and the issue is still under investigation.
