Also, and for whatever this may be worth, “this sort of thing” is not what I like to see in the source-code of a template.   Instead, I prefer to see it either as a Perl-supplied input variable (which could of course be a closure ...), or as a custom function (defined in the Perl) that performs the task.   (Which is, in this case, “display this date according to ‘the client language’.”   IMHO, the template should neither contain the exact format-string, nor the logic for deducing what ‘the client language’ is.   Think ahead ... The Marketing Department™ will want to change this!   Endlessly.   Of course, after you have cut ’n pasted it a zillion-and-one times.   You want to be able to change it in one place, then walk away with a smug grin on your face as the Dumbfounded Marketroids praise you as a genius.

Situations such as this one are where I would advocate that you should strive to “write what you mean,” then provide an implementation for that “meaning” in one, and only one place.   The code that you show in the OP is not “meaning,” but concrete implementation, ripe to be repeated.   This templating system makes all of this very easy to do.