controlling/forcing session language

[torvista]

I am working on an auto emailer script called by a cron job which runs through past orders and sends an invitation to comment on the purchase.
I have a dual language shop and so the emails have to be in the correct language.
I have an extra field for the order record which records the order language so it’s not a problem to retrieve the orders per language.
The problem is forcing zen_mail to use the correct language defines for the email template.

ie. the cron job would call something like emailer.php?lang=en or emailer.php?lang=es,

the script will pull out the english or spanish orders and use zen_mail to send them.

I can use specific (en or es) defines to put the correct language text in the body of the emails but once it goes through zen_mail it uses whatever language it feels like (it seems) to add in the template block email footer text/copyright/anti-spam etc.

In the script I have set the session variables to the relevant language values to try get zen_mail to cooperate but it doesn’t work.
$_SESSION['language'] = $language;
$_SESSION['languages_id'] = $lang_id;
$_SESSION['languages_code'] = $lang_code;

If I use this locally, the footer-text language used in the email is whatever I have chosen in the shop front but since this is being run from a cron
lynx --dump blah/blah/emailer.php?lang=en
I am guessing it is making its language decision on the browser language?

In any case I seem to regularly come across this issue of trying to force a session language so I would appreciate some insight into this issue or some general guidance on how to control it within Zen Cart as I evidently don’t understand it clearly enough,

Thanks
Steve

ps preview/editing of post not working for me in Chrome or FFox, text field always empty on preview.

[DrByte]

The language constants are loaded when application_top is run. And, since constants are, well, constant, they can't be altered during the same execution cycle.

Definitely that will pose problems for batched scripts like you're doing, where the language is not based on the visitor, but rather is constantly changing due to differences in your input data.

Unfortunately, changing that is a big architectural alteration.

Perhaps consider rewriting your cron job to accept a language parameter, and use that both to set the language id in the session and filter the db queries to just those orders which used that language? Then have additional cron jobs for the other languages you have on your site?

[torvista]

Perhaps consider rewriting your cron job to accept a language parameter, and use that both to set the language id in the session and filter the db queries to just those orders which used that language? Then have additional cron jobs for the other languages you have on your site?

That is exactly what I do have.

Two cron jobs, one with ...?lang=en and the other with ....?lang=es which work fine to select the orders and get language-dependent custom text ( require('autoemailer_'.$lang_code.'.php'); ) constants used prior to the zen_mail function call.

If I set the SESSION variable set with the three language variables (belt and braces) before it calls application_top, it gets changed:
$_GET['lang']=en
english is set
Pre application top:
$_SESSION['language=']=english
$_SESSION['language_id=']=1
$_SESSION['languages_code=']=en

Post application top:
$_SESSION['language=']=spanish
$_SESSION['language_id=']=2
$_SESSION['languages_code=']=es


Testing locally this change is driven by whatever language is chosen in another tab of the browser. I can understand that, but when there is no other tab open/with the cron job how does it make the decision and how can I override it?

[torvista]

So, I find that the pre-existing $_SESSION values are wiped and replaced in sessions.php at this point:

$temp = session_start();

if I set a extra $_SESSION variable in my external script and make the above call conditional, I can maintain the language as previously defined:

if ($_SESSION['lang_override'] != 'true') $temp = session_start();

Seems to work fine.

I did look at setting the sesson_name etc. but didn't make any progress with that.

[DrByte]

You can't set $_SESSION variables before the session starts, else they'll be wiped out.

I suppose you could customize the init_languages.php code to read your command-line parameters instead of only responding to $_GET parameters, when setting language during application_top.

[torvista]

Well, it seems just adding a full parameter of

&language=es or en
sets the session language without changing any code.

I'm sure I tried that before and it didn't work but looking at init_languages indicates that it should work if the GET is set.

Another one I'll put down to experience.