I was doing some whitelabelling for a client of mine and it’s nice that I was able to hook into gettext hook BUT the translation functions were called numerous times if not 5,000-10,000 times.
I am wondering if you thought about deactiving this functionality in ClassicPress by default to get some speed?
e.g. maybe enable it if a specific php const exists?
Here’s an article from 2014 about WP performance.
https://www.engineyard.com/blog/profiling-with-xhprof-xhgui-part-3
3 Likes
Hi @lordspace – welcome! @Mte90 is our internationalization lead so he may be able to offer some immediate feedback, but you are very welcome to add your petition to our growing list of requested features here.
2 Likes
That’s an interesting read, thanks for sharing.
While I internationalize all my plugins, I’ve never been entirely sure how this functionality is used on the other end. Like, when do translations come into play? Are they used based on a WP/CP or site or theme setting? Or, are they used based on a http header specifying a language preference? I’ve always treated it like, “Ok, I’ve added support for translation, do with it whatever you will.” and I never think about it again.
If I’m writing internal-use code, I never run text through translation functions – partly for better performance, partly for more succinct code, partly because it’s only going to be read by someone who uses English as a first language. It would be great to disable the translation on the frontend on a site-by-site basis it it’s not truly needed…
1 Like
Many different factors to consider… In no particular order:
- I’d like to see what the performance numbers look like with PHP 7.3. I suspect that with opcode caching the performance gain won’t be significant.
- It would have to be enabled by default. Translation files aren’t just used for translation - if you’re dealing with enterprise-level bureaucracy it’s can be easier to say
__('CTA_PAGE_FOO')and have the prose in the.pofile. - A lot of functions in WP/CP have side-effects, and things rely on those side-effects to work properly. If we disabled it we’d need to be sure we’re not introducing some subtle vulnerability, and off the top of my head I’m not sure how we’d do that with any reasonable degree of confidence.
Generally I like the idea of being able to slim things down - if we can show it’s worth the effort wrt performance and that we’re sure it won’t cause unexpected problems I’d be in favour of doing it.
3 Likes
Yes WordPress does a lot of call to these methods because they are used everywhere.
The real problem is that the parsing of mo files (binary) is made at every request if you are using a different locale to en_US.
In wordpress 5.0 for performance reasons they implemented a little system to not load the mo files if that plugin language file is not requested and this saved a lot of time.
On the other hand there is a huge patch on WordPress where I contributed rewriting it https://core.trac.wordpress.org/ticket/17268 that will use the php module available from php 5.3+ that support natively mo files. In this way no parsing from php code because will do PHP interpreter that is more fast.
Also there is a library GitHub - aucor/dynamic-mo-loader: Better text domain loading with object cache support for WordPress that implement caching of these files after reading them (with the php native module if available) so the execution of the page is very very fast. There is also GitHub - inpsyde/translation-cache: Improves site performance by caching translation files using WordPress object cache. that cache only the output and not use the native php module.
Basically is possible to implement it in WordPress but there are no developers or interest on improving except me. I hope that when in ClassicPress we will start to work on 2.0 branch to implement this patch and fixing once for all this issue.
I am very open to more tests and benchmark with those in WordPress so we can move on upstream this change and benefit also in ClassicPress quite easily.
4 Likes
I am thinking that if we skip the translation loading altogether this should add some performance gains and also possibly reduce memory footprint.
Despite English is only third language I speak (excuse for grammar and other mistakes in my posts), I prefer only English in all computer-related stuff. It’s too dangerous to lose something in the translation. Medicine have Latin like universal language, software should use English.
Based on that, I prefer to separate other languages and disable them by default. If you really need, if you know what you are doing - you can enable, but by default they should be disabled and locale set to the en_US. Especially, if it gains some performance.
Please, create a petition, link here and I will wote for it.
1 Like