Translate date in the email templates

[Razva]

Hello,

Our WHMCS setup is set to English by default. Unfortunately our international customers are complaining that the messages we're sending are "mixed-bilingual".

Here's an example:

Quote

Dorim sa te informam ca in Thursday, November 1st, 2018 a fost emisa factura proforma #27 in valoare de 333.03RON. Termenul de plata este Thursday, November 1st, 2018 .

The above message was sent to a user that had Romanian set as Language, so basically the message is in "romglish". This is/looks very unprofessional.

WHMCS's staff reply was this:

Quote

You can replace the date variables in the email templates such as {$invoice_date_due} with your own variables using the EmailPreSend hook: https://developers.whmcs.com/hooks-reference/everything-else/#emailpresend

You may also be able to use some of the Smarty date formatting options as well: https://www.smarty.net/docs/en/language.modifier.date.format.tpl

Unfortunately I'm not so good at coding so ... can somebody please point me to the right direction?

Thank you

Edited November 1, 2018 by Razva

[brian!]

32 minutes ago, Razva said:

Unfortunately our international customers are complaining that the messages we're sending are "mixed-bilingual".

there is a long-known problem with long dates in WHMCS.

34 minutes ago, Razva said:

The above message was sent to a user that had Romanian set as Language, so basically the message is in "romglish". This is/looks very unprofessional.

the usual workaround (cheat!) would be to change your Client Date Format to "use Global Date Format" and thus avoid using any day/month names in the output.

40 minutes ago, Razva said:

You can replace the date variables in the email templates such as {$invoice_date_due} with your own variables using the EmailPreSend hook: https://developers.whmcs.com/hooks-reference/everything-else/#emailpresend

why WHMCS expect their users to a) be programmers capable of writing a hook (and yet never provide a working example of how to do it), and more importantly b) need to write a hook to fix something that should be corrected in the core program is simply astonishing.

1 hour ago, Razva said:

You may also be able to use some of the Smarty date formatting options as well: https://www.smarty.net/docs/en/language.modifier.date.format.tpl

i'm not even sure that's correct because in order to have PHP translate the date string, you would need to be able to set the locale and you can't easily do that in Smarty... and would require the different locales to already be installed anyway.

if you really had to do this, you could do it in the email templates using Smarty - e.g., check if the user language is Romanian, if so, optionally tweak the date format and translate days/months with multiple Smarty replaces... otherwise just show the variable as normal.

{if $client_language eq "romanian"}{$invoice_date_created|date_format:"%A, %d %B %Y"|replace:'Monday':'luni'|replace:'Tuesday':'marţi'|replace:'Wednesday':'miercuri'|replace:'Thursday':'joi'|replace:'Friday':'vineri'|replace:'Saturday':'sîmbătă'|replace:'Sunday':'duminică'|replace:'January':'ianuarie'|replace:'februarie':'marţi'|replace:'March':'miercuri'|replace:'April':'aprilie'|replace:'May':'mai'|replace:'June':'iunie'|replace:'July':'iulie'|replace:'August':'august'|replace:'September':'septembrie'|replace:'October':'octombrie'|replace:'November':'noiembrie'|replace:'December':'decembrie'}{else}{$invoice_date_created}{/if}

now whether you would want to do that for *every* date variable and language in the email template, either in the main template or in any translated templates (though you shouldn't need the if statement in a translated template), I don't know - but it would work.... though I daresay you can now understand why it would be easier to just use DD/MM/YYYY date formats! 🙂

[Razva]

25 minutes ago, brian! said:

the usual workaround (cheat!) would be to change your Client Date Format to "use Global Date Format" and thus avoid using any day/month names in the output. 

After spending a couple of hours with my programming colleagues, the general conclusion was "fsck it, let's just use Global Date Format". I'm coming from HostBill and I'm amazed of the limitations imposed by WHMCS! You cannot specify quantities for products on invoices, you cannot create products with quantities (my workaround was to create a product + configurable options, which is horrible), you have hugely limited multi-language support (even if WHMCS advertises itself as "fully multi-lingual"). Sometimes I'm so tempted to just go back to HostBill... 😐

[brian!]

3 minutes ago, Razva said:

After spending a couple of hours with my programming colleagues, the general conclusion was "fsck it, let's just use Global Date Format".

lol.

4 minutes ago, Razva said:

I'm coming from HostBill and I'm amazed of the limitations imposed by WHMCS!

even after 5+ years, i'm still amazed at how slow WHMCS development is and their bizarre preference for working on trivial (though commercial) non-core issues, whilst important things like this go unresolved (though would be relatively easy to do with access to the core code).

7 minutes ago, Razva said:

You cannot specify quantities for products on invoices

you can - you just need a developer to create a custom invoice template for you. 🙂

14 minutes ago, Razva said:

you cannot create products with quantities (my workaround was to create a product + configurable options, which is horrible)

depends what you mean by products with quantities... products can be setup to allow the user to enter a qty at the viewcart stage...

37 minutes ago, Razva said:

you have hugely limited multi-language support (even if WHMCS advertises itself as "fully multi-lingual").

makes me wince whenever they say that about WHMCS... some parts are partially multilingual... whilst huge chunks requires extensive coding to do it.

[Kian]

It's more than 4 years that I translate WHMCS in Italian (backend and legacy modules) on every new release. Multi-lang is even worse than you think 😟 

We already know that some parts can't be translated (eg. modals and lot of js libraries even though they support multi-lang) but there's much more. It doesn't matter how hard I try to deliver the best translation. All strings in language files are Anglocentric. Singular and plural in Italian and in many other languages work differently. I can't translate things like "Domain(s)" and I need two versions of the same string depending on singular or plural.

In my experience they've been very lazy with multi-language on multiple levels.

[Remitur]

On 11/2/2018 at 12:17 AM, Kian said:

I can't translate things like "Domain(s)"

You can translate it into 

dominio/i

It's horrible, but no mo more horrible than "Domain(s)" ... 😄

[brian!]

On 01/11/2018 at 23:17, Kian said:

Multi-lang is even worse than you think

i'm sure it is - i'm lucky to come at WHMCS speaking English so a lot of the things that you see naturally, I probably won't even notice unless pointed out or I have reason to investigate. 🙈

5 hours ago, Remitur said:

it's horrible, but no more horrible than "Domain(s)"

ha that annoyed me when I first started using WHMCS 5+ years ago - whenever you see (s) in the output, you know the developers are being lazy because it's not rocket science to count the item in question and code the output correctly. 🙄

[HancoEuropa]

Yeah, I have my invoices all nicely formatted -- of course with the glaring exception of the dates, which indeed, looks unprofessional or a careless oversight at the least on our part. 

It does not instil confidence in the client about our capabilities to do work for them accurately.  No. 

English, clearly just fine of course:

I mean, how in the world can WHMCS just ignore this now for 5+ years on?   It really makes the product sub-optimal.

Should we start a petition?  I have some friends in India who could deliver it I think...

On 1/11/2018 at 6:23 PM, brian! said:

f you really had to do this, you could do it in the email templates using Smarty - e.g., check if the user language is Romanian, if so, optionally tweak the date format and translate days/months with multiple Smarty replaces... otherwise just show the variable as normal.

{if $client_language eq "romanian"}{$invoice_date_created|date_format:"%A, %d %B %Y"|replace:'Monday':'luni'|replace:'Tuesday':'marţi'|replace:'Wednesday':'miercuri'|replace:'Thursday':'joi'|replace:'Friday':'vineri'|replace:'Saturday':'sîmbătă'|replace:'Sunday':'duminică'|replace:'January':'ianuarie'|replace:'februarie':'marţi'|replace:'March':'miercuri'|replace:'April':'aprilie'|replace:'May':'mai'|replace:'June':'iunie'|replace:'July':'iulie'|replace:'August':'august'|replace:'September':'septembrie'|replace:'October':'octombrie'|replace:'November':'noiembrie'|replace:'December':'decembrie'}{else}{$invoice_date_created}{/if}

now whether you would want to do that for *every* date variable and language in the email template, either in the main template or in any translated templates (though you shouldn't need the if statement in a translated template), I don't know

Brian I think your smarty method is the best we can do so far ...

So in each and every template 🙄  where a date is needed, I have to pick out the month from the global date and use the language files to translate.

Not fun, but at least it works:

<!-- using global $date like "24-10-2020" //-->
<h5>{$date|substr:0:2} {$monthnum = $date|substr:3:2}{lang key="month-$monthnum"} {$date|substr:6:4}</h5>

Then in each language file, just:
 

$_LANG['month-10'] = "Octombrie";

  or

$_LANG['month-10'] = "October";

Works well enough for now ... until WHMCS get a similar solution:

Eh one day ... another 5 or 10 years maybe, they might fix it. 😜

We shall see...

 

Edited October 24, 2020 by HancoEuropa
to remove incorrect images

[pRieStaKos]

On 11/6/2018 at 9:46 AM, Remitur said:

You can translate it into 

dominio/i

It's horrible, but no mo more horrible than "Domain(s)" ... 😄

You should see the Greek translation on the word “domain”. It’s “τομέας” that is the properly translation of the word “sector”. So for domains we are not translating the word “domain” or we use the words “όνομα χώρου”, which really is “name space”. So I follow the line of not translating specific web service global words to local language, because it’s no use loosing the real meaning. 

Edited October 25, 2020 by pRieStaKos

[brian!]

21 hours ago, HancoEuropa said:

I mean, how in the world can WHMCS just ignore this now for 5+ years on?   It really makes the product sub-optimal.

I am convinced that WHMCS design primarily for English..... and then only as an afterthought, do how things look in other languages get considered.

there is no doubt that the v8 Blend menu was designed for English... and when a user complained about it's layout for non-English languages (I think during the beta), the official WHMCS response was to suggest using Language Overrides  to make the titles shorter in that language...

I can't tell you how much I dislike the v8 menu - to use some Romanian - coșmar nenorocit.

21 hours ago, HancoEuropa said:

Should we start a petition? 

is that Romanian for a feature request ? don't bother... takes years, waste of time etc.

21 hours ago, HancoEuropa said:

Brian I think your smarty method is the best we can do so far ...

you could do it as a hook, but from outside of the internal code, you'd still be manipulating every date variable separately in the hook.

21 hours ago, HancoEuropa said:

Then in each language file, just:

it's worth mentioning that the default language files already contain translations for day/month names - both long and short.

$_LANG['dateTime']['january'] = "Ianuarie";
$_LANG['dateTime']['february'] = "Februarie";
$_LANG['dateTime']['march'] = "Martie";
$_LANG['dateTime']['april'] = "Aprilie";
$_LANG['dateTime']['may'] = "MaI";
$_LANG['dateTime']['june'] = "Iunie";
$_LANG['dateTime']['july'] = "Iulie";
$_LANG['dateTime']['august'] = "August";
$_LANG['dateTime']['september'] = "Septembrie";
$_LANG['dateTime']['october'] = "Octombrie";
$_LANG['dateTime']['november'] = "Noiembrie";
$_LANG['dateTime']['december'] = "Decembrie";

that would simplify any Smarty coding (outside of the email templates) if you had to do this is multiple languages as you could reference the language string rather than a direct translation per language in the if statement (either in Smarty or as a hook).

occasionally, these translation strings do get used with dates... e.g the announcements page uses them.... and i've written hooks that use Carbon to translate dates in Sidebars (Carbon has translation strings there just waiting to be used).... so WHMCS CAN do it, they just choose not to bother.

[HancoEuropa]

 

Yes, you're right

27 minutes ago, brian! said:

That would simplify any Smarty coding (outside of the email templates) if you had to do this is multiple languages as you could reference the language string rather than a direct translation per language in the if statement (either in Smarty or as a hook).

I was using the "10" in the global date format because I can find it easily ( substr:3:2 ) -- whereas long date name would mean finding the position of the space ... then using that to truncate .... and I don't know if i'm smart enough to do a smarty for the full date name ... {lang key="dateTime.$lowermonthname"} I guess.  Doable as well in the templates.

But yes, a good old hook would be a bit more robust ... it's just that sometimes I think I'd need the dates done where certain hooks would not return the $vars all the time.  Is that right?   I get depressed when I find a good hook point but ... nothing returned. 

27 minutes ago, brian! said:

I can't tell you how much I dislike the v8 menu - to use some Romanian - coșmar nenorocit.

Yes.  I just can't quite imagine how so many people in their meetings could allow themselves to be convinced that something which is clearly less convenient, less informational and requires more clicks to choose a menu item ... could possibly be either useful or appropriate.   I can't imagine who they think they are impressing ... certainly not people who use WHMCS 🤣   Loathe it. 

Was there user demand for a completely reworked menu paradigm?   Was there some similar avalanche of requests logged for a new menu, as were logged (over many years) with the faulty international dates?   Do you think MORE or LESS requests were made for a new menu over showing the correct month name in a date?

Whatever the case, I agree the new v8 menu is cumbersome at best.

I'm sure we'll make it through mate!

Enjoy!

P.S.  On another $_LANG issue, since you are hook-savvy, could you possibly have a look at

 When you have a moment?   I still can't quite figure that out. 

Cheers!

Edited October 25, 2020 by HancoEuropa
added postscript

[brian!]

19 hours ago, HancoEuropa said:

I was using the "10" in the global date format because I can find it easily ( substr:3:2 ) -- whereas long date name would mean finding the position of the space ... then using that to truncate .... and I don't know if i'm smart enough to do a smarty for the full date name ... {lang key="dateTime.$lowermonthname"} I guess.  Doable as well in the templates.

you wouldn't need to find position, assuming Romanian long dates follow the English format (I genuinely don't know if they do) - if so, you would just replace the parts sequentially, e.g replace days of week, replace ordinal dates (that's the st/nd/rd/th after the date) and then replace the months.

either way, it's a pain to do... i'm sure if WHMCS wanted to, they could fix this within days... a week tops with proper testing...

21 hours ago, HancoEuropa said:

But yes, a good old hook would be a bit more robust ... it's just that sometimes I think I'd need the dates done where certain hooks would not return the $vars all the time.  Is that right?   I get depressed when I find a good hook point but ... nothing returned. 

generally speaking in the client area, if you could access the variables in the template, and it's not a subtemplate (e.g order summary), you should be able to access, manipulate and return the variables in a hook.

21 hours ago, HancoEuropa said:

Was there user demand for a completely reworked menu paradigm?   Was there some similar avalanche of requests logged for a new menu, as were logged (over many years) with the faulty international dates?   Do you think MORE or LESS requests were made for a new menu over showing the correct month name in a date?

they say there was demand to make the Blend theme more mobile friendly, but i've never seen any post requesting the removal of the homepage stats or the setup menu... and the idea of using the sidebar as a secondary menu is just insane.

they can locate a feature request to justify any decision they make when they need to.... even if it only gets one vote.

21 hours ago, HancoEuropa said:

I'm sure we'll make it through mate!

i'm slowly writing a hook solution to fix the menu...

all the tabs are optional (useful while i'm coding it), and so you can disable the logo/shortcuts menu if required... and i'm bringing the setup menu back (fed up of multiple clicks to find what I want)... once everything is back, then it's a case of working out if some links can be moved logically... e.g Order Statuses can be moved to Orders; the support dept links could be moved to Support; Clients Custom Fields could be moved to Clients etc... I only get change to work on it p/t, but it's coming along. 🙂

[HancoEuropa]

On 26/10/2020 at 5:33 PM, brian! said:

you wouldn't need to find position, assuming Romanian long dates follow the English format (I genuinely don't know if they do) - if so, you would just replace the parts sequentially, e.g replace days of week, replace ordinal dates (that's the st/nd/rd/th after the date) and then replace the months.

either way, it's a pain to do... i'm sure if WHMCS wanted to, they could fix this within days... a week tops with proper testing...

generally speaking in the client area, if you could access the variables in the template, and it's not a subtemplate (e.g order summary), you should be able to access, manipulate and return the variables in a hook.

they say there was demand to make the Blend theme more mobile friendly, but i've never seen any post requesting the removal of the homepage stats or the setup menu... and the idea of using the sidebar as a secondary menu is just insane.

they can locate a feature request to justify any decision they make when they need to.... even if it only gets one vote.

i'm slowly writing a hook solution to fix the menu...

all the tabs are optional (useful while i'm coding it), and so you can disable the logo/shortcuts menu if required... and i'm bringing the setup menu back (fed up of multiple clicks to find what I want)... once everything is back, then it's a case of working out if some links can be moved logically... e.g Order Statuses can be moved to Orders; the support dept links could be moved to Support; Clients Custom Fields could be moved to Clients etc... I only get change to work on it p/t, but it's coming along. 🙂

Oh that's brilliant.   Do think about a marketplace item for that Brian, you'd have alot of takers.

Nice, nice work!

Cheers,

 

[HancoEuropa]

As our Brian had noted, the language files do indeed have month and day names in them, such as "$_LANG['dateTime']['january']".

This could be used to do a "lookup" using the written month name in English within a template by using a lowercase month name value with the {lang key=$monthname} somehow. But that means that the system date formatting needs to have the full month name, which is not always useful elsewhere throughout WHMCS.

We found it's easier to just add a little list in the language files of numbered month (and day) names, like this:

$_LANG['month-01'] = "January";
$_LANG['month-02'] = "February";
$_LANG['month-03'] = "March";
etc

And in General Settings, the global system date is set to the standard DD/MM/YYYY and formatting also set to that Global setting

That way, formatting a date within the template to the right language is slightly simpler:

{$date|substr:0:2} {$monthnum = $date|substr:3:2}{lang key="month-$monthnum"} {$date|substr:6:4}

Not too long, not perfect, but works fine. 

Cheers

[ajalex]

Hello! I don't know if there is already or someone has solved the problem, I have searched and found nothing by ninugn laho so I tried to make a hook with which to re-splice the date.

Actually I use the standard date in the DD/MM/YYYYYY commands, but at the end of the mails I had in the global template {$date} and I didn't realize that it arrived in English even though I have it in Spanish.

I made a small hook that could be adapted, for this I made a new varibale {$date_locale} that will be the output and the one that will remain in the template.

Then I read the client language that is given by default by the variables in the hook $vars['mergefields']]['client_language']

I tried Lang::trans but it didn't work so since we already get the client's language, I made an include to attach the client's language.
 

include ROOTDIR . "/lang/".$vars['mergefields']['client_language'].".php";

Now I read the date given by the varialbes and in this case I need "date" so I pass it to strtotime and then using arrays I replace it with $_LANG['dateTime'] and change the output format to my liking.

add_hook('EmailPreSend', 1, function($vars) {

    $merge_fields = [];


    if (!array_key_exists('date_locale', $vars['mergefields'])) {

       include ROOTDIR . "/lang/".$vars['mergefields']['client_language'].".php";

        $date = strtotime($vars['mergefields']['date']);

        $NumberDay      = date('j', $date);
        $Day            = date('l', $date);
        $Month          = date('F', $date);
        $Year           = date('Y', $date);
        $Days_Translate = array(
            $_LANG['dateTime']['monday'], 
            $_LANG['dateTime']['tuesday'], 
            $_LANG['dateTime']['wednesday'], 
            $_LANG['dateTime']['thursday'], 
            $_LANG['dateTime']['friday'], 
            $_LANG['dateTime']['saturday'], 
            $_LANG['dateTime']['sunday']
        );
        $Days_En         = array("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday");
        $NameDay         = str_replace($Days_En, $Days_Translate, $Day);

        $Month_Translate = array(
            $_LANG['dateTime']['january'], 
            $_LANG['dateTime']['february'], 
            $_LANG['dateTime']['march'], 
            $_LANG['dateTime']['april'], 
            $_LANG['dateTime']['may'], 
            $_LANG['dateTime']['june'], 
            $_LANG['dateTime']['july'], 
            $_LANG['dateTime']['august'], 
            $_LANG['dateTime']['september'], 
            $_LANG['dateTime']['october'], 
            $_LANG['dateTime']['november'], 
            $_LANG['dateTime']['december']
        );
        $Months_EN       = array("January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December");
        $NameMonth       = str_replace($Months_EN, $Month_Translate, $Month);


        $merge_fields['date_locale'] = $NameDay.", ".$NumberDay." de ".$NameMonth." de ".$Year;

    }


    return $merge_fields;

});

As in my case I wanted the date when the mail was sent I used $vars['mergefields']['date'] but if you need another date you can use the ones allowed by the template for example from invoices: invoice_date_created and invoice_date_due etc.. and replace it with $vars['mergefields']['date'] ex : $vars['mergefields']]['invoice_date_created']

You can change the directory to include instead of the main language the one included in the overrides directory in case you want to make different settings or different texts and not lose it in the updates.

I hope it helps, I also have a hook to replace the image of 2co, Paypal and Stripe if you are interested. 

Regards!

Edited October 9, 2022 by ajalex

[pRieStaKos]

Use Carbon’s Localization