Additional information:
The packing slip shows ONLY in CZ as well.
All ordered products are shown in their respective CZ-versions.
The invoice that woocommerce shows uses the right language of the customer and shows the products in the right language of the customer.
We are using polylang premium version.
The pdf invoice plugin is the free version.
So one can see the invoice in the correct language and when then the PDF-Invoice button is pressed, the created pdf is ALWAYS in CZ, independent of any setting I could find.
Plugin Contributor
Ewout
(@pomegranate)
We do not provide support for multilingual setups with the free version (although we don’t actively disable anything). This hasn’t changed in our plugin, so it may be something that has changed in Polylang itself. If you need Polylang support in our plugin, the Professional extension offers you 2 options: either always print in the main site language, or print in the customer language.
I do not need customer-support! And I would not even need multi-language. I just need that your plugin creates the invoice in the language of the site OR the admin OR the customer and not in a language that was not chosen – and always ONLY in this language!
Where can I manually set (in the PHP code of your plugin) the language?
Again, it’s no customer support, it’s a BUG that was not present before.
Polylang may have changed something, but your plugin simply does not work anymore like it did before and chooses always the same WRONG language!
It used to display the invoices in the language of the customer.
It stopped working correctly after one of the last updates, I have not exactly monitored this.
Plugin Contributor
Ewout
(@pomegranate)
I’m not saying anything about customer support. It’s simply additional functions required for supporting Polylang, because this is (as you have found) not automatically the case. Don’t forget you’re using an entirely free plugin.
In regular WooCommerce installations (without Polylang), our plugin automatically follows WooCommerce, which means that when you print the invoice from the admin it will be in the admin language (i.e. language set in the user profile) and when it is sent as attachment, it is in the frontend/site language.
I’m not forgetting it is free, I’m telling you that something changed in the last update(s), because it worked before and now creates something I cannot use.
I will rather buy another plugin than to be forced to buy the premium version because of a BUG in the free one. I was close to buying the plugin, because we need serial invoice-storing, but then I saw that it does not work correctly anymore.
I have checked with other FREE pdf-invoice plugins and they work, they choose English for the invoices. So, in case you think this BUG is not your problem, I will accept this and use another, WORKING, free plugin.
So, if you tell me where in the PHP code I can set the language the “hard way”, I’m PHP programmer, it’s no problem for me. With your next update, this bug can be fixed and I will be convinced to buy your premium version.
In case your bug is my problem, I will take another plugin for pdf-invoices.
Plugin Contributor
Ewout
(@pomegranate)
I understand it is frustrating when this stopped working, but we never actively supported Polylang in the free version. Any existing compatibility there may have been in the past was therefor coincidental and provided by Polylang itself. Because multilingual setups are inherently complex, we only support this in the Professional extension, and this has always contained extra functions to make sure the language is correct for the PDF regardless of the context (admin/my account/email attachment, single export/bulk export).
We don’t consider this a bug, but a feature we don’t offer in the free plugin.
I’m sorry to hear this means that you will switch to another plugin, but it’s not something that we have broken on purpose (I strongly believe that providing actual value with the free plugin is good for all parties and would never wreck a feature on purpose) and it’s simply one of the feature we offer for paying customers.
For reference, if you want to override the plugin locale, you can do this via the plugin_locale filter:
https://github.com/wpovernight/woocommerce-pdf-invoices-packing-slips/blob/v2.3.4/woocommerce-pdf-invoices-packingslips.php#L69-L98
Thank you.
Just: it does not make any difference. Whatever locale I enter, I always get just the Czech version.
I have inserted an bug into the file and tried to get an pdf invoice created -a dn, as expected, the exception was thrown, so it simply does not make any difference, what local I enter!
Even if I delete the CZ-locale files from the language directory, it does not make any difference.
I know that the proce of the premium version already is surpassed many times by my time used to deal with this, but I dislike this kind of “user-fooling”.
Your plugin does not care what locale I enter, whether the locale-files are in the language dir – and you tell me it’s not a bug, but just a lost unknown feature?
To me that is a bug. It might be about a feature officially not supported, but your plugin has a locale-function that does not do anything, so that is called BUG.
You should pay me for helping you find a bug and you should care about bugs and not try to make them look as something different.
I’m telling this to you as programmer…
Maybe more direct so you can exactly understand what I write:
public function translations() {
$locale = exit (“en_US”);
When I click on the pdf-invoice-button, my browser shows only “en_US” – so the code is executed.
Then, I change it to $locale = “en_US”;
or whatever (but “cs_CZ”), and it does not change anything, the invoices are created always and only in Czech.
Thus, when you tell me to set the locale, but that does not change anything, maybe you understand this as BUG as well. And any bug might be in some completely different script, so you should be happy that I write about this to you – and do your best to find the problem.
Plugin Contributor
Ewout
(@pomegranate)
It is possible Polylang also uses this plugin_locale filter (which is not from our plugin but from WordPress core), so if you override it, make sure to give it a high priority. The PDF invoice plugin defaults to get_user_locale(). If your locale is different from the user locale, it means this is overriden at another level, and in your case this is most likely by Polylang.
It is also possible Polylang overrides this at another level (with a later filter/hook), for example redirecting the actual mofile loading (by using load_textdomain_mofile like we do for the legacy textdomain fallback). I suggest you contact Polylang support about this if you want this to default to English rather than the first language in the list (especially since you mentioned you paid for Polylang Pro). Like I said, we don’t do anything to override this in the free version, which means that all switching is done by Polylang.
If you want Polylang to use a specific language for each document, you have to do this explicitly instructing Polylang to do so – this is how we do that in the our pro version. Our plugin (and the plugin_locale filter) works fine in single language setups and Polylang and WPML are paid features so this is not something we will procide in the free version. Feel free to switch to another PDF invoice plugin if they provide better support for Polylang.
Plugin Contributor
Ewout
(@pomegranate)
One more thing you could try is to disable legacy mode in the Status tab in the plugin (do note that this will require that your templates are compatible with version 2.0 or later of the PDF invoice plugin), this will prevent the textdomain fallback from applying.
Stop fooling me!
It is the file: woocommerce-pdf-invoices-packingslips.php
YOUR file. Not Polylang.
WHATEVER locale I HARD CODE (like “en_US”) there, into YOUR file, it does not make any difference.
Your plugin does not react on any locale-setting. Do you read my messages?
“The PDF invoice plugin defaults to get_user_locale()”
It DOES NOT DEFAULT to anything, because when I hard code ANY “default” locale code into YOUR plugin’s function, it disregards that setting.
It’s a bug, but in case you prefer to insist that it’s not, it’s better to switch to developers that are interested in bug-free codes and not in reality-denial.
You really think that I’m an idiot, do you? I know, most users are…
“One more thing you could try is to disable legacy mode in the Status tab in the plugin (do note that this will require that your templates are compatible with version 2.0 or later of the PDF invoice plugin), this will prevent the textdomain fallback from applying.”
I’m NOT running in legacy-mode and I already explained how I made sure that the function where I hard coded the locale into, was really executed.
The files are “new version format”, the function “function translations()” is executed, but it does not work, it does not do anything, whatever locale I HARD CODE into there.
The textdomain-fallback is for old-format languages files – and those are not present.
It has nothing to do with a “user setting” or something, it is a pure and clear, easy BUG.
When there is just one language, this bug does not show up, but when there are more, your plugin’s “function translations()” does not do what it should.
Strange that you invest so much time in telling me that I do not know what I’m talking about and true that I should stop wasting my time with your plugin.
Actually, I liked it, before, when it worked in a correct way, and I wanted to try to talk with the developers to help you find and fix the bug.
I’ll stop with this and take some other plugin. Sorry that I wanted to help you!
Plugin Contributor
Ewout
(@pomegranate)
I don’t think you’re an idiot, I just tried to explain that beyond what this plugin provides as the locale & language files, there are multiple levels at which this can be overriden, I’m sorry if that wasn’t clear from my post(s).
The first level is within the WPO_WCPDF()->translations() method, using the plugin_locale filter. This is the locale that is then passed to load_textdomain() and load_plugin_textdomain(). These are WordPress functions, meaning that even after that point, any third party plugin can still override our supplied locale (or your hard coded locale): for example using the load_textdomain_mofile filter
I mentioned before (or another filter override_load_textdomain): https://github.com/WordPress/WordPress/blob/5.2.4/wp-includes/l10n.php#L612-L672.
Polylang indeed uses load_textdomain_mofile
