=?iso-8859-1?Q?Re:_=5Bic=5D_=A3_or_£ _for_UK_currency_symbol_in_Loca?= le

[John1]

On Wednesday, July 06, 2005 5:20 PM, kevin at cursor.biz wrote:

> John1 [list_subscriber at yahoo.co.uk] wrote:
>> I am a little cautious about doing this as it would also impact the
>> plain text e-mail templates which use the [currency] tag.  i.e. They
>> would display £ instead of a pound sign, so I would have to
>> change any e-mail templates to hard code a pound sign.
>>
> For UK websites, I tend to set the currency_symbol to £ and
> then use a simple filter in the emails to convert £ to GBP:
>
>    [item-filter price2gbp][item-price][/item-filter]
>
> The filter looks like this:
>
>    CodeDef price2gbp Filter
>    CodeDef price2gbp Routine <<EOR
>    sub {
>        my $val = shift;
>
>        $val =~ s/&price;\s*/GBP /g;
>        return $val;
>    }
>    EOR
>
> Prices on pages look like "&pound;123.45" and prices in emails look
> like "GBP 123.45".  You could modify the filter to strip the currency
> altogether and add a note in the email along the lines of "all price
> values are British Pounds Sterling."  The filter could even look up
> the currency_symbol for itself and strip it automagically.
>
> Perhaps Interchange could be modified to define a currency_plaintext
> Locale key and use that, instead of currency_symbol, when a certain
> pragma is set on a page/email.  Something to think about/discuss.
>
Thanks for your detailed and very helpful reply Kevin.  I presume that it 
would be fine for me to use:

$val =~ s/&price;\s*/£/g;

in the plain text filter as the £ symbol is part of the standard ASCII 
character set and so should display correctly in any plain text e-mail 
reader.  Correct?

BTW, we have occasionally had customers complain that the first digit has 
also been truncated from prices (and I think, from memory, in this case # 
signs were displayed in place of £ signs).  e.g. £123.50 might display as 
#23.50

Is this also likely to be due to the fact we are using £ instead of &pound; 
in our html, or will there be a different client-side reason for this?