We have also modified the PDF template files in the child template to add some extra fields.
We have all the strings in the templates correctly specified using the _e() function with the text domain specified. All strings are translated.
Now the problem: when we generate a PDF for a language other than the default language, e.g. Polish, some strings are in Czech, so the languages are mixed up.
1. This affects all the strings we have in the child template for PDF. We have listed them in the source code in English, they get translated to PDF, but to the wrong language (Czech instead of Polish).
2. This affects also strings used in the PDF template customiser.
See screenshot (PDF ss.png), yellow untranslated strings from template, red untranslated strings from customizer.
Not marked strings are OK.
I reported this bug to the WP Overnight support and we found out, that those badly translated string are always in the language set in the user profile. So WP Overnight support asked me to contact you, because it looks more like a WPML bug.
E.g.
- If I set my profile to Czech and then generate PDF for Polish order, in the PDF are mixed Polish and Czech strings (are strings should be in Polish)
- If I set my profile to Slovak and then generate PDF for Polish order, in the PDF are mixed Polish and Slovak strings (are strings should be in Polish)
- If I set my profile to English and then generate PDF for Polish order, all string are correctly in Polish language
These erroneous PDF documents with mixed languages are also sent to our clients when they are generated based on a change of order status (final invoice when goods are shipped). In this case, it seems that it does not depend on the language that is set in the profile of the registered customer or the order, but on the language that is set by the administrator changing the order status.
Thank you for checking and have a great day.
Ludek
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Hello Ludek,
Indeed, user e-mails are supposed to use the language declared inside the user's profile.
An issue might be, that your user has "Site default language" set as profile language which leads to a mix of strings in the site's default language or even admin strings if an admin forces the email to be sent to the client.
This said, a user with Polish as profile language, should receive emails in Polish.
- Majority of our customers doesn't have even user profile, they are buying without registration.
- Email attachments (email body itself is OK) are send partly in correct language a partly translated to a wrong language. To the language set in administrator profile, not user.
- Non translated strings comes from child template or PDF customiser.
Please read my report carefully and letm me know if you need further assistance from my side.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
If a user is not registered and has no user language inside WordPress or a dedicated usermeta custom field with a language value assigned, then WordPress will always use the site's default language.
Recent feedback from our Compatibility Team regarding a similar issue:
Emails should be sent in the user language (the one set in Users > Your Profile) and not in the page language as most people expect.
1) Create a user
2) Go to Users > Your Profile.
3) Change the user's language.
4) Trigger the email. It will be sent in the specified language of the user's profile.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Hello,
I would like to offer to have a closer look at the problem and request temporary access (wp-admin and FTP) to the website to investigate this issue further.
You can find the required fields below the comment section when you log in to leave the next reply. The information you provide is private, which means only you and I can see and access it.
IMPORTANT
Please be sure to make a backup copy of the website and database before allowing us access.
If you can't see the wp-admin / FTP fields, your post and website credentials are set as PUBLIC. DO NOT publish the data unless you see the required wp-admin / FTP fields.
I may have to install a plugin called "All In One WP Migration" to make a copy of the website where I can investigate the issue further.
However, I would also be very grateful if you could provide a staging site or copy of the website from your server yourself for this purpose.
If you have any questions about creating such a staging site, you can consult your hosting provider. Just take note that WPML should be registered on this site again.
If you are unable to provide such a copy of the site for testing, please let me know on this ticket.
The private response form looks like this: hidden link
Next time you reply, click "I still need assistance."
Video: hidden link
Please note that we are obliged to request this information individually on each ticket. We may not access any access information not specifically submitted on this ticket in the private response form.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Your site's default language is Czech which is why it would be expected and recommended to use Czech as the site's default language for your templates.
I do understand, right that this is a working solution in this case.
If so, then I would kindly like to ask you to use the site's default language for your templates.
Using the default site language in templates is a workable solution, but it only addresses half of the problem. Some strings in the PDFs remain untranslated. Please refer to my previous message for a detailed description.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Please do not use any default values at WooCommerce > PDF Invoices Customizer, as they might come programmatically in English.
Make sure all fields have a value.
Then go to WPML > String Translation > Translate texts in admin strings and search for each string. Add each string to String Translation and translate them.
If you change the order of the fields inside the customizer or change their values you might need to delete the registered admin_text strings and register them again.
If this will not solve the issue, please let me know.
thanks, I partly solved the issue, however strings marked in the attachement remains untranslated.
Yellow ones: no way how to add custom labels for this fields
Purple one: Untranslated in the PDF, but added and translated in the String Translation as you advised, strange...
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Hello Ludek,
I sadly do have a really difficult time to test on a local copyof your site, as the migration process took very long and failed a couple times. Now, that I got a local copy running I do get many 500 error for which I do not really the the reason, as it is not generating any debug.log.
Would it be possible for you to install PDF Invoices & Packing Slips incl. all Add-ons on a test site which I would like to provide, so that we can try to recreate the issue there?
sorry for the delay, I was on vacation to recharge my batteries.
I'm sorry you're having so much trouble with testing. When the debug.log is not generated the Query Monitor plugin works well for me, it prints the debug log to the screen.
For us, in the meantime, we decided to migrate the invoicing completely out of Woo and invoice directly in the accounting system. So I suggest not to worry about this problem any further.
But if you want to get to the bottom of it, I can try to do the staging on our server, which will make it much easier to migrate the data. What do you say?
