Author Topic: Order staus update emails translation issue  (Read 20654 times)

alexanderfrese

  • Beginner
  • *
  • Posts: 10
    • Quarum
Order staus update emails translation issue
« on: March 19, 2009, 08:23:40 am »
Hi everybody

I was stuck with the problem, that the order status update email translation is determined by the value of $mosConfig_lang that is set in the backend. So if a shop owner uses a different language than the customer, the VM text strings tranlation in that email only depends on the backend setting.

With the help of someone that really is into PHP, I managed to build some pacthes to make the language of these emails depending on a new user field that the user can set while registration. So this is the first thing we have to set up.

Setting up a new user field
Go to VM admin -> Manage User fields.
Create a New User field
Field type: Make it a Drop Down (Single Select)
Field name: Use whatever you like. Note, that vm_will be added as a prefix. In my case (and in the further patches) I use vm_usercontactlanguage as field name.
Field title: Here you can use whatever you like, but I used a Name following the capital letter nomenclature. This comes handy, when you add the string for that field name into your necessary language files, so the title will be translated automatically. In my case I used PHPSHOP_SHOPPER_FORM_USERLANGUAGE as the field title.
Description: Whatever you might need, if so.
Required?: Yes
Show in registration form?: Yes
Show in account maintenance?: Yes
Show in shipping form?: No
Read-Only?: No
Published: Yes
Field Size: 1

Then you have to make up the selectable values. Add as many as you likeThe String under "Title" is displayed within the selct list. The string under "Value" is the actual value of the field stored in the database.
In my case I use Deutsch - german and English - english as the two pairs. Whatever you choose as Title, the string under value must match the correct spelling for the language variables. If unsure, look up /administrator/components/com_virtuemart/languages/common The filesnames there (if you have installed any secondary languages) show the correct spelling (Note: Leave out the .php-annex!).

Please note there is an error in the core here! If you choose to reopen the field editing procedure or applying changes several times, the Title/Value pairs are duoplicated each time. I have not yet found any way to delete them but deleting them in the matching table with phpMyAdmin!

If you have saved the field, you must set the ordering in the "Manage User Fields" list. I put it prominently into the first section, just before the first delimiter (billto).

Where is the text for the order status emails generated?
Unfortenately, the email is not built within a template but in a core file. You have to open /administrator/components/com_virtuemart/classes/ps_order.php. Look for the line (around 295 in VM 1.1.2): function notify_customer( &$d ){
A few lines later look for this line:

Code: [Select]
$db = new ps_DB;

Enter the following line right after it to prepare another database lookup:

Code: [Select]
$dbl = new ps_DB;

Right above the comment line: //MAIl BODY we add te following code:

Code: [Select]
$q = "SELECT #__{vm}_user_info.vm_usercontactlanguage FROM #__{vm}_user_info,#__{vm}_order_user_info,#__{vm}_orders,#__{vm}_order_status ";
$q .= "WHERE #__{vm}_orders.order_id = '".$db->getEscaped($d["order_id"])."' ";
$q .= "AND #__{vm}_orders.user_id = #__{vm}_user_info.user_id ";
$dbl->query($q);
$dbl->next_record();

This query calls the vm_contactlanguage from the table vm_user_info.

Right after //MAIL BODY) the mail itself is built. There are lots of $VM_LANG->('XYZ',false). What we did was to add the string ,$dbl->f("vm_usercontactlanguage") right after all the ,false in those elements, we wanted to be translated. It is obviously unnecessary to do so for the name (first, middle and last) of the customer the email is sent to.
One example:
Before:

Code: [Select]
$VM_LANG->_('HI',false)

After:

Code: [Select]
$VM_LANG->_('HI',false,$dbl->f("vm_usercontactlanguage"))

This makes sure, that the value of the field vm_usercontactlanguage is passed on to the function "_", which is the main routine for translating VM strings (do not mix up with any JF-translations!). We did this for all strings down to and including those in the if/else routine right before the funtion for the download IDs starts. Watch out! If you have inserted some of those extra code, it is easy to mix up the $db and the $dbl calls. Be careful to look out for that.
I do not need any other emails (i.E. the donwload-ID email also built in this file. If you should need this, according changes there might help your needs. Just make sure you implement the correct additional SELECT fields and maybe even FROM tables there.

The final file to patch
The last one was a bit tricky. You have to patch the basic translation file and routine there, so be careful. Open /administrator/components/com_virtuemart/classes/language.class.php. Look for the line function _( $var, $htmlentities=false) {. This function is the basic function for the translation of the VM_LANG things we have patched in the ps_order.php.
Change

Code: [Select]
function _( $var, $htmlentities=false)
to

Code: [Select]
function _( $var, $htmlentities=false, $p_strAltLang = '' )
right after the line

Code: [Select]
global $modulename;
insert the follwong line:

Code: [Select]
global $mosConfig_lang;
right after the line

Code: [Select]
$key = strtoupper( $var );
insert the follwong code:

Code: [Select]
// Define second global variable if $p_strAltLang is set (Needed down in function load($module)…)

if ($p_strAltLang != '')
{
global $p_strAltLang2;
$p_strAltLang2 ='Y';
}


// patch for alternate language (switches  $mosConfig_lang to the value of the user field (sent from ps_order.php), only if it's set
if( ( $p_strAltLang != '' ) && ( $mosConfig_lang != '' ) )
{
    // store old language for further use
    $strOldLanguage = $mosConfig_lang;
    $mosConfig_lang = $p_strAltLang;
   
    $this->load('common');
    $this->load('order');
}

Scroll down to the line if ($module!==false) {. Within the if-part of that condition lies the first return for the function "_". Right before the line return $text; insert the following code:

Code: [Select]
// Reset $mosConfig_lang to the old value for the first return point
if( $p_strAltLang != '' )
{
    $mosConfig_lang = $strOldLanguage;
    $this->load('common');
    $this->load('order');
}

Within the else-part of that condition lies the second return: return stripslashes( $text );. Right above this line, you can insert the same if-condition as above, or use this one commented correctly:

Code: [Select]
// Reset $mosConfig_lang to the old value for the second return point
if( $p_strAltLang != '' )
{
    $mosConfig_lang = $strOldLanguage;
    $this->load('common');
    $this->load('order');
}

There is still the final return for the function, a simple return ''; right before the funtion "merge" is set up. Before this returen add one more time:

Code: [Select]
// Reset $mosConfig_lang to the old value for the third return point
if( $p_strAltLang != '' )
{
    $mosConfig_lang = $strOldLanguage;
    $this->load('common');
    $this->load('order');
}

From this point on, the email should correctly be sent with the strings translated according to the setting of the user field value. But note: If you test this with exisiting orders without having given a contact language to the matching customer, there will be no outcome since his value for that field would still be NULL.

We were stuck for quite a while at that point of patching, since when clicking the "Update Status" button in VM’s Order List, not only the email was sent in the language set by the new field, the whole VM part of the screen switched to that language until we clicked somewhere else. It took us some time to realize, that the function "load($module)", which is responsible for loading the language files of a given module loads them by require_once, which makes the language file cached for all other queries, let them be called with or without the additional language value.

So we have to patch that, too. We still have to work on /administrator/components/com_virtuemart/classes/language.class.php. Scroll way down almost to the end to find the line:

Code: [Select]
function load($module) {

Within this function, look for the line:

Code: [Select]
if (file_exists( ADMINPATH. 'languages/'.$module.'/'.strtolower($mosConfig_lang).'.php' )) {

Right after that, insert:

Code: [Select]
// patch for alternate language: if require_once then the whole VM changes language!
if( $p_strAltLang2 == 'Y' )   {
require ( ADMINPATH. 'languages/'.$module.'/'.strtolower($mosConfig_lang).'.php' );
}
else {
require_once ( ADMINPATH. 'languages/'.$module.'/'.strtolower($mosConfig_lang).'.php' );
}
// end patch


This should make sure, that the module is only loaded by require in that special circumstance, where we deal with the contact language. All other situations load by require_once.

That's about it.

Please make sure that you back up everything before throwing it around! Don't mess up a working site. Be careful!


The only thing unadressed here is the order status name. It cannot be translated by VM’s routines. It is addressed by JF in fact, buzt suffers from the same  problem. It takes the destination language from the backend setting, not from the user.
Within the next days, I will try if a simple backup/change/restore of $mosConfig_Lang in ps_order.php around the email message generation would make  that poking around with language.class.php unnecessary.

Alex
Alexander Frese
www.quarum.de

patrex

  • Beginner
  • *
  • Posts: 15
Re: Order staus update emails translation issue
« Reply #1 on: March 23, 2009, 15:45:15 pm »
Thanks for a very deep description of this problem.

How ever i wonder, is their not a easier way around this?

Regards

Patric

alexanderfrese

  • Beginner
  • *
  • Posts: 10
    • Quarum
Re: Order staus update emails translation issue
« Reply #2 on: March 23, 2009, 15:59:30 pm »
I fear it won't get much easier. VM (and Joomla, Joomfish) make the translation depending on the $mosConfig_Lang in the moment and circumstances it is triggered in. (If allowed, a registered Joomla user can choose his language in his Joomla account settings, but this is another story, since VM users don't come to that point. If it would help for the VM mails? Who knows?)
This principle covers all the mails a foreign speaking user might trigger himself, but not the emails sent to him from the mother tongue speaking shop owner in his backend.
Since this option is not even intended to be managed by the system, the patch is rather big to setup the variables and to make sure, the patch is only used within that special circumstance.

In fact, it looks much to read, but I wanted to post a cook book that people with low understanding of the whole PHP would be able to use. It does not take you too long to do. Hope I did not make any crucial typos, though…


Alex
Alexander Frese
www.quarum.de

pjm

  • Beginner
  • *
  • Posts: 8
Re: Order staus update emails translation issue
« Reply #3 on: April 11, 2009, 19:11:41 pm »
Hi,

Thanks for this great hack.

My only problem is that the admin panel is still changing the language when I do the Update Status thing. It looks that the require and require_once are not doing what they should do. And I'm pretty sure that I copied/pasted correctly. Alex, by any chance haven't you forget something in the code? Also, should the original require_once in the code be commented out (probably it doesn't matter)? Thanks.

alexanderfrese

  • Beginner
  • *
  • Posts: 10
    • Quarum
Re: Order staus update emails translation issue
« Reply #4 on: April 11, 2009, 19:25:14 pm »
Hmm,

I already feared the possibility of faulty reproduction of the hack we built.
It is in fact complicated so the chances of missing some details (either me setting up the guide or you trying to apply it) are high.
Time is short on my side at the moment, but I will try to compare my guide to the files in the site I implemented it within.

Alex
Alexander Frese
www.quarum.de

pjm

  • Beginner
  • *
  • Posts: 8
Re: Order staus update emails translation issue
« Reply #5 on: April 14, 2009, 19:30:07 pm »
Hi Alex,

Sorry to bother you but please don't forget to do the comparison when you can, ok? It will be much appreciated.

jagular

  • Beginner
  • *
  • Posts: 15
  • never ending BFU
Re: Order staus update emails translation issue
« Reply #6 on: April 26, 2009, 17:55:32 pm »
Hi all
Alex: very useful modification :)
I was trying get the order status name translated by JF, but still dont know how.
But its can be done by another way - add new variables to language files:

/administrator/components/com_virtuemart/languages/common/english.php
/administrator/components/com_virtuemart/languages/common/another_languages.php

for example:
Code: [Select]
'PHPSHOP_ORDER_STATUS_NAME_P' => 'PENDING',
'PHPSHOP_ORDER_STATUS_DESCRIPTION_P' => 'Descritption ...',
'PHPSHOP_ORDER_STATUS_NAME_C' => 'CONFIRMED',
'PHPSHOP_ORDER_STATUS_DESCRIPTION_C' => 'Descritption ...',
'PHPSHOP_ORDER_STATUS_NAME_E' => 'SENDED',
'PHPSHOP_ORDER_STATUS_DESCRIPTION_E' => 'Descritption ...',
'PHPSHOP_ORDER_STATUS_NAME_X' => 'CANCELED',
'PHPSHOP_ORDER_STATUS_DESCRIPTION_X' => 'Descritption ...',
'PHPSHOP_ORDER_STATUS_NAME_D' => 'RETURNED',
'PHPSHOP_ORDER_STATUS_DESCRIPTION_D' => 'Descritption ...',
'PHPSHOP_ORDER_STATUS_NAME_R' => 'CLAIM',
'PHPSHOP_ORDER_STATUS_DESCRIPTION_R' => 'Descritption ...',
'PHPSHOP_ORDER_STATUS_NAME_X' => 'CANCELED',
'PHPSHOP_ORDER_STATUS_DESCRIPTION_X' => 'Descritption ...',
where the letter on the fin of PHPSHOP_ORDER_STATUS_NAME_X and PHPSHOP_ORDER_STATUS_DESCRIPTION_X must be the same like order_status_code from table #__{vm}_order_status

dont forget uptade the values in language files when you change the status in db

And how to get it in the email? Small modification in:
/administrator/components/com_virtuemart/classes/ps_order.php

original about lines 308-312
Code: [Select]
$q = "SELECT first_name,last_name,user_email,order_status_name FROM #__{vm}_order_user_info,#__{vm}_orders,#__{vm}_order_status ";
$q .= "WHERE #__{vm}_orders.order_id = '".$db->getEscaped($d["order_id"])."' ";
$q .= "AND #__{vm}_orders.user_id = #__{vm}_order_user_info.user_id ";
$q .= "AND #__{vm}_orders.order_id = #__{vm}_order_user_info.order_id ";
$q .= "AND order_status = order_status_code ";

change to:
Code: [Select]
$q = "SELECT first_name,last_name,user_email,order_status,order_status_name ";
$q .= "FROM #__{vm}_order_user_info,#__{vm}_orders,#__{vm}_order_status ";
$q .= "WHERE #__{vm}_orders.order_id = '".$db->getEscaped($d["order_id"])."' ";
$q .= "AND #__{vm}_orders.user_id = #__{vm}_order_user_info.user_id ";
$q .= "AND #__{vm}_orders.order_id = #__{vm}_order_user_info.order_id ";
$q .= "AND order_status = order_status_code ";
just add "order_status" in SELECT

and in the part where is generated the mail body
original before hacks about line 328:
Code: [Select]
$message .= $db->f("order_status_name");

change to:
Code: [Select]
$message .= $VM_LANG->_('PHPSHOP_ORDER_STATUS_NAME_'.$db->f("order_status"),false,$dbl->f("extra_field_5"))."\n\n";
$message .= $VM_LANG->_('PHPSHOP_ORDER_STATUS_DESCRIPTION_'.$db->f("order_status"),false,$dbl->f("extra_field_5"))."\n\n";


where
$VM_LANG->_('PHPSHOP_ORDER_STATUS_NAME_'.$db->f("order_status"),false,$dbl->f("extra_field_5"))

"extra_field_5" can be "vm_usercontactlanguage" or what do you use

hope this help till be found better solution
...

ZS

  • Beginner
  • *
  • Posts: 4
Re: Order staus update emails translation issue
« Reply #7 on: February 08, 2010, 18:50:31 pm »
AWESOME hack Alex! Is there a way to make this field appear in the database, so that the value of the previously registered members can be changed?

inkewbus

  • Beginner
  • *
  • Posts: 4
Re: Order staus update emails translation issue
« Reply #8 on: March 13, 2010, 14:16:53 pm »
In the next few days I will be working with a buddy of mine to get it done a little differently. This will not require the customer to choose the language in the order status.

We will be pulling the variable they're using for $mosConfig_lang during checkout and will create another column in the order table so that it includes the language they were using during checkout. We will then take this variable from the database when the email is created from the admin section. This will allow us to send the email to the customer in the language they chose during checkout without having to be bothered with the dropdown box.

I will let you know how it goes and will hopefully have a working copy of it in the next few days. If it works the way we want, I'll post the changes for everyone.

inkewbus

  • Beginner
  • *
  • Posts: 4
Re: Order staus update emails translation issue
« Reply #9 on: March 14, 2010, 11:37:35 am »
I got it to set everything correctly and to send out the email in the language that was chosen for the customer when they were on the site with Joom!Fish. After the status is updated, it will send the order to the customer in the language they ordered in. I am still testing a few things out before I post the changes to the code.

I've also gotten it so that when I select multiple orders from another mod and send them out, it sends each in it's own language as well.

ningpa

  • Beginner
  • *
  • Posts: 5
Re: Order staus update emails translation issue
« Reply #10 on: May 12, 2010, 22:47:47 pm »
did you test it successfully?

i'm really interested in this and would be very grateful if you're willing to share your solution :)

blans

  • Jr. Member
  • **
  • Posts: 80
Re: Order staus update emails translation issue
« Reply #11 on: October 13, 2010, 14:13:36 pm »
This post shouldn't be marked as solved.

I have the same problem: Order Confirmation is sent out in the correct language - Order Status change is sent out in the back-end language.

I would call this a bug.

Any updates yet...?

Multilingual VM Webshop
Joomla 1.5.26
VM 1.1.9
Joomfish 2.1.7
Artio JoomSEF 3.8.2
CSVi VM 3.8.1

VM2 has the power of Magento and the usability of Opencart. I just can't get it to do what I managed to do with VM1 for so long...

finngu

  • Beginner
  • *
  • Posts: 17
Re: Order staus update emails translation issue
« Reply #12 on: May 24, 2011, 20:29:50 pm »
Did anybody ever get at final solotion to this where everything is working??

If so I would love to know exactly how??


Thanks
Finn

stavroch

  • Beginner
  • *
  • Posts: 31
Re: Order staus update emails translation issue
« Reply #13 on: September 20, 2011, 11:16:39 am »
I have the same question.

I am looking for
"Your order has been successfully placed!" and "Your order is being processed, please wait."

 in the administrator/components/com_virtuemart/languages/common/english.php but I can't find it.

hisslink

  • Beginner
  • *
  • Posts: 13
Re: Order staus update emails translation issue
« Reply #14 on: October 03, 2011, 11:04:41 am »
Hello, is there a solutions for the Order Status change yet?
Also, the field label isn't translated. What am I doing wrong?