Site language problem with emails, PHP

Having a problem with site emails being sent out using the wrong language. Our site uses French and English, but always sends our emails to English customers using French. In the site configuration, the languages are listed as fr;en; and uses French as default. If I switch it to en;fr; English becomes the default. The problem is when a customer chooses a site language, the emails are sent in the opposite language. The emails are generated using HTML2PDF if it matters. I can’t seem to find where the language problem is. The language should stay the same throughout the users visit, even when sending email receipts and tickets.
Not sure what I should post for code since it eludes me…
Trying to follow the code up to when it sends emails out, but getting lost.
Aside from uploading the complete program, not sure what to do.
Suggestions?

I’d think that the code involved in actually sending the email would be a good starting point to post. That code will need to look in your configuration file, or in the customer file to find the language to use. So it must be doing something wrong in that area.

Has it ever worked correctly? If so, what has changed between when it worked, and now that it does not?

I don’t think it ever worked in the email respect.
The site is based on Fusion Ticket, now out of business, which was based on PHPMyTicket, which is also gone.
How nuch code can we post here? I’m thinking I may have to post a few files because It’s hard to follow it. (for me anyway)

As much as you like. :slight_smile:

To ensure it displays correctly, either highlight the code and use the </> button in the editor to format it, or place three backticks ``` on a line above your code, and three on a line below your code. I find the latter method easier, especially with large code blocks, but the backtick key is missing from some European keyboards. (It’s at the top left of UK/US keyboards.)

OK, I’ll put together a kind of flow with the files I think are used for this. After supper of course… :slight_smile:

I was thinking…
if the HTML2PDF program is converting the template, which is stored
in the database, why can’t I tell HTML2PDF which language to use
based on the $_SITE=>lang or $_SESSION=>lang ?
The template has language variables in it which are substituted for
the proper text when generated. Like {!englishtext!} and {!frenchtext!}.
These variables come from 2 language files, which are included when
the user chooses a site language.
Is there code I can place in the template to specify the correct language?
I think Smarty is used also, along with HTML2PDF.
The files I was going to post are huge, and this forum won’t let a new
user upload any files.

I’m not so sure it’s a broken code thing instead of a configuration that’s off or a dictionary not set up correctly.

What do your Smarty global.lng files look like?

I don’t see any smarty global.lng files.
The language files are stored in a includes/lang directory
as site_en.inc and site_fr.inc
Sample:
define(“act_code”,“Activation code:”);
define(“act_done”,“Account Activated”); //checkout_preview
define(“act_email_sent”,“Activation email sent.”);
and
define(“act_code”,“Code d’activation :”);
define(“act_done”,“Compte activé”);
define(“act_email_sent”,“Courriel d’activation envoyé.”);

That looks like OK syntax.

Does the locale section of your Smarty config.php file look OK?

Maybe it is broken code after all. Can you find the email template files and see if they are using the matching translation files?

1.) Recreate the problem locally
2.) Use an IDE compatible with xdebug and go line by line through the code as it executes.

My wild guess would be that the process sending out the emails isn’t aware of the language. If this process is initiated via cron or in the background this is high possibility.

No smarty config file anywhere Mittineague…
The templates have placeholders like I mentioned above in my ‘thinking’ post.

So… I just tried using one of the users fields in the database to specify a
language code as ‘en’, and revised the template with if/else to use the code
and it sent the correct template section under ‘en’. But the placeholders were
still translated to French. I could try not using placeholders and just translate
the template in place to get around this, using both languages in one template.
It would be a quick ‘fix’ until It’s figured out, I guess…

No cron…
The emails get sent out as soon as payment is registered as ‘completed’

I would use xdebug with PHPStorm to step line by line through the code to figure out what is happening.

Not familiar with how to do that, but I can certainly try it.
Is this software free?

It can be a little tricky to set-up but once you have it working you will wonder how you ever worked without it. There is this article:

Although that looks to be a little dated.

The installation steps are going to change based your local environment. In a nutshell though. You install this.

https://xdebug.org/

That is a php extension which you will need to add to your php installation.

Once that is installed and configured you will need to use an IDE compatible with xdebug. I use PHPStorm but that isn’t free. There is a trial version available for 30 days. I think most editors have a plugin that integrates with xdebug. You will need to search around the web based on the editor/IDE you use.

I also work on VMs that I create via puphpet.com.

https://puphpet.com/

Using a vm with puphpet instead of XAMP is more flexible and makes it easier to install additional extensions and software like xdebug and mail hog. I use mail hog to catch all the emails sent locally instead of actually sending them out when I’m developing.

Thanks ZooKeeper…
I will definitely look into it…

I would highly recommend it.

The other option is poor mans debugging adding endless var_dumps until you can pin point the issue. That method really sucks…

Do you have separate email templates for each language or one template with inline functions that translate the text?
Does this system use a open source CMS or is it all proprietary?

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.