[Updated] Email notification after online payment isn't translating

[Cameleon]

Hi,

I'm making a new topic about this issue since i found from where the problem is coming.

Here an overview of how our website work :

Currently we have 5 languages on our website, and 3 payment methods :
- Paypal (paypal plugin)
- Bank (alatak_cybermut plugin)
- Quote (standard plugin)

When a shopper place an order, it work like following :
- If this is a quote, the order is set as "Quote" and the shopper receive a notification email with a Virtuemart invoice.
- If this is an online payment, the shopper is sent to Paypal or on our bank website. If his payment is successful, we receive an api call and the order is then set as "Payment accepted", and the shopper receive a notification email with a Virtuemart invoice.

When an order is sent, we set the order as "Order Shipped". Then the shopper receive an email saying that his order has been shipped.

For these emails, we use the parameter 'order_language' to know if the email have to be in French (Default) or English (Other languages).

Now the problem :

The email sent after a Quote is correctly translated.
The email sent after we update the order status in the admin is correctly translated (whatever the status).
The email sent after a successful payment is always in french.

And we don't know why.
The problem occur on both Paypal and Alatak plugin.

I find this strange since the "loadOrderLanguages" method is only used in the "Order" class and in the "sendVmMail" function.

[Cameleon]

I kept working on this issue, but all my tests are returning the right language tag at every steps, while my emails are still in the wrong language.

It seems that all the Order's status change made in the function "plgVmOnPaymentNotification" doesn't care about the order's language.

Even if it's always the same function used to send mails ("sendVmMail").

Does anyone have a clue about this issue ?

[Milbo]

I worked really hard on this feature the last days,

Please use this version http://dev.virtuemart.net/attachments/download/1037/com_virtuemart.3.0.18.6_extract_first.zip

We have now own JLanguage instances PER language. Furthermore I restructured and removed the quirk in the email functions. There is now also a setting, if the invoice should be always in user language or shop language.

Additionally there is a new hidden config (I create gui for it later), for debugging emails, that means they are sent directly on screen and not per mailer. Makes it easier to layout them.

[Milbo]

For some history, you can look here http://forum.virtuemart.net/index.php?topic=135863.msg474733#msg474733

[mwaeckerlin]

I have had exactly the same problem, but twice. The first part, the language of the order confirmation mail, is now resolved. (Thank's to the ZIP above.)

One problem is still open:

We wrote an own plugin for plgVmOnPaymentNotification. When this plugin is triggered, I first log the language: JFactory::getLanguage()->getTag().

The user filled out the order in de-DE, but the language here is en-GB (the shop's default).

Could you fix that too, please?


BTW, to the forum-admins: reCAPCHA is bullshit! It does not work on FF+NoScript+CookieManager, even when I allow everything!

[jjk]

BTW, to the forum-admins: reCAPCHA is bullshit! It does not work on FF+NoScript+CookieManager, even when I allow everything!

Did you also answer the verification question correctly which is displayed next to the recaptcha?
If you log into the forum first, you don't need to answer the recaptcha and verification question.
Without this kind of protection, the forum would be flooded by spambots in no time.

[Milbo]

We have now own JLanguage instances PER language. Furthermore I restructured and removed the quirk in the email functions. There is now also a setting, if the invoice should be always in user language or shop language.

We wrote an own plugin for plgVmOnPaymentNotification. When this plugin is triggered, I first log the language: JFactory::getLanguage()->getTag().

The user filled out the order in de-DE, but the language here is en-GB (the shop's default).

Could you fix that too, please?

It wont work with JFactory::getLanguage, because we have now our own instances. When you want the currently used language tag you need now (with vm3.0.18.9) vmLanguage::$currLangTag, but when you want the language of the user, then you should use the language set in the order.

[mwaeckerlin]

After adding the following code, now it works, thank you:

Code Select Expand


    $postfinance_data = $_POST;
    $virtuemart_order_id = VirtueMartModelOrders::getOrderIdByOrderNumber($postfinance_data['orderID']);
    $order = VirtueMartModelOrders::getOrder($virtuemart_order_id);
    JFactory::getLanguage()->setLanguage($order['details']['BT']->order_language);


[Milbo]

Ehrm, it wont work with this http://dev.virtuemart.net/attachments/download/1040/com_virtuemart.3.0.18.9_extract_first.zip

JFactory::getLanguage()->setLanguage($order['details']['BT']->order_language);

This command does not what you think, believe me. I may tell you in german per phone, too lazy to write that.

JFactory::getLanguage gets always the same JLanguage object. The overrides are ALWAYS done in the constructor, so you cannot change that. The command is also deprecated.

I also do not understand for what you need that this way

"$order = VirtueMartModelOrders::getOrder($virtuemart_order_id);
    JFactory::getLanguage()->setLanguage($order['details']['BT']->order_language);"

Cant work anyway, because the function "getOrder" translate already, you need to set it before. But I think you should first take a look on the new options and hidden configs

[mwaeckerlin]

Im using 3.0.18.9 → this fixes the problem of wrong language in the order confirmation mail.

But then, we wrote an own plugin for plgVmOnPaymentNotification, where we create the products that have been bought. In this plugin callback, I still get the wrong language. Later we send a mail with the product activation links.

Without my patch, this mail is english, with the patch, it is in the correct language. So, at least this hack works for me.

Questions:

• What would be the correct way to fix the language in plgVmOnPaymentNotification?
• Will there be a patch in VirtueMart to call plgVmOnPaymentNotification with the correct language?

[Milbo]

Your explanations shows clearly that there is a lot information missing to understand the whole problem.

In general, emails can be sent from the frontend, this happens when the customer used the checkout or when a payment does an order update.
But the emails can also be generated from the Backend, when the shopowner changes the order status there.

Then emails can be in shopper language, or in shop default language (joomla Frontend default language). The same counts for the administrator email, which language should be taken? Administrators in the BE want the language which they just use, but in general it uses the default language of the shopowner (vendorid =1).

Then it makes additionally a difference if you use english as shop default or not, because english is anyway loaded as fallback. That was important in the old system, when used always the same language object. Now it is not a problem anylonger (3.0.18.9), because we use for any language an own JLanguage object.

So we use always our own JLanguage objects, so when you manipulate the JLanguage object given by JFactory::getLanguage, it is imho luck when it works. It could work with some php versions, lets say it that way, because I do not a clone of the object setting it to our own variable.

The next problem is that the code loads here and there language files. So when you create the order, the userfields and in special the country list already loads the language and so you get a wrong language, when you load the order and set the language then. You will get a partly translated email. The problem is worse with pdf, btw (header and footer, vendor information!).

There is no bug and there is nothing to fix. You just need to check how I rewrote the order loading and do the same (model orders, function notifyCustomer around line 1688)