Title: Wrong language in invoice
Last modified: October 23, 2019

---

# Wrong language in invoice

 *  Resolved [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/)
 * My site has 5 languages so far, English being the default language for the backend.
   
   Unfortunately, the pdf-invoices and package slips are ALWAYS in czech language!
   It’s the first on the list of languages but almost unused. Whatever language 
   the user chooses or the site is set in, this plugin ALWAYS creates ONLY pdf in
   Czech language! This was NOT always the case, until the last upgrade, the language
   was the language of the customer. I guess that there is some bug in the new version.
 * I would not mind if the invoices would be only in ONE language, English or Dutch,
   but having them in Czech only and not being able to change that is very annoying.
   
   Please help!

Viewing 14 replies - 1 through 14 (of 14 total)

 *  Thread Starter [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12057007)
 * 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](https://wordpress.org/support/users/pomegranate/)
 * (@pomegranate)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12057350)
 * 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](https://wpovernight.com/downloads/woocommerce-pdf-invoices-packing-slips-professional/)
   offers you 2 options: either always print in the main site language, or print
   in the customer language.
 *  Thread Starter [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12057455)
 * 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](https://wordpress.org/support/users/pomegranate/)
 * (@pomegranate)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12057535)
 * 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.
 *  Thread Starter [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12057770)
 * 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](https://wordpress.org/support/users/pomegranate/)
 * (@pomegranate)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12057826)
 * 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](https://github.com/wpovernight/woocommerce-pdf-invoices-packing-slips/blob/v2.3.4/woocommerce-pdf-invoices-packingslips.php#L69-L98)
 *  Thread Starter [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12057957)
 * 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…
 *  Thread Starter [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12058019)
 * 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](https://wordpress.org/support/users/pomegranate/)
 * (@pomegranate)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12058094)
 * 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](https://github.com/wpovernight/woocommerce-pdf-invoices-packing-slips/blob/v2.3.4/woocommerce-pdf-invoices-packingslips.php#L52)).
   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](https://wordpress.org/support/users/pomegranate/)
 * (@pomegranate)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12058137)
 * 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.
 *  Thread Starter [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12058151)
 * 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.
 *  Thread Starter [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12058167)
 * 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.
 *  Thread Starter [provithor](https://wordpress.org/support/users/provithor/)
 * (@provithor)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12058218)
 * 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](https://wordpress.org/support/users/pomegranate/)
 * (@pomegranate)
 * [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12058227)
 * 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](https://github.com/WordPress/WordPress/blob/5.2.4/wp-includes/l10n.php#L612-L672).
 * Polylang indeed uses [load_textdomain_mofile](https://github.com/polylang/polylang/blob/2.6.5/frontend/frontend-filters.php#L58)

Viewing 14 replies - 1 through 14 (of 14 total)

The topic ‘Wrong language in invoice’ is closed to new replies.

 * ![](https://ps.w.org/woocommerce-pdf-invoices-packing-slips/assets/icon-256x256.
   png?rev=2189942)
 * [PDF Invoices & Packing Slips for WooCommerce](https://wordpress.org/plugins/woocommerce-pdf-invoices-packing-slips/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/woocommerce-pdf-invoices-packing-slips/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/woocommerce-pdf-invoices-packing-slips/)
 * [Active Topics](https://wordpress.org/support/plugin/woocommerce-pdf-invoices-packing-slips/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/woocommerce-pdf-invoices-packing-slips/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/woocommerce-pdf-invoices-packing-slips/reviews/)

 * 14 replies
 * 2 participants
 * Last reply from: [Ewout](https://wordpress.org/support/users/pomegranate/)
 * Last activity: [6 years, 9 months ago](https://wordpress.org/support/topic/wrong-language-in-invoice/#post-12058227)
 * Status: resolved