Currency format

  • I cannot set the currency format. I want comma as decimal separator.

  • I added the Danish language and now it works.

    Only thing is I prefer to prefix the ISO code. I.e. “DKK 123,45” instead of “123,45 DKK”.

  • Hum, I’m facing this same issue after migrating from prestashop to thirtybees.

    I recognize that it may be helpful to automatically set the currency format based on the customer’s location as in your example of the euro zones but, sometimes this will not be the case.

    Wouldn’t it be better to let the user decide if this will be set automatically or manually, just as the other language/zone related parameters?

  • I agree with moy2010 on this one. I really miss the manual format and spacing options!
    Maybe you could add the option to format currencies in the country settings? This would make it possible to keep different formatting of e.g. the euro depending on user locale while still having maximum control as webshop owner/administrator.

  • It does seem like having an easy way for customers site owners to determine the currency format for each country would be a nice touch. Even though a given country may have an “official standard” for currency format it’s quite possible that multiple standards are used in practice and/or depending on the region of the country.

    Edit: As noted. No idea what I was thinking.

  • @mdekker said in Currency format:

    The format depends on the locale (so both country + language). We thought that CLDR would be perfect for this since it has all the combos. Perhaps using that as a basis, but allowing for an override per language/country combo might be a better idea?

    This sounds perfect to me.

  • Indeed. The simpler, the better.

    Most users will value the simplicity of the settings but, leaving open the option to customize it for the rest of us :).

  • @mdekker
    I have a new shop that I can’t go live unless I can display the price without decimal ‘1050’ instead of '1500.00’
    I’ve tried modifying displayPrice & commerceguys/intl but with no luck.
    Can you try point me to a solution? I don’t mind having it as an ugly patch because this shop is only for Israel with only one country/currency/language

  • So the setting in Preferences/General Number of dicimals will not help?

  • Just tested in my shop and it only work in BO. Strange

  • @yaniv14, can you make a screenshot or two? “without decimal ‘1050’ instead of '1500.00’” sounds, uhm, odd.

    Another thing to look at is Smarty/HTML code producing these numbers. I’ve seen rounding code in some templates. Like {$price|round} or similar.

  • @Traumflug I think it is just a typo. 1050 instead of 1050.00
    It is strange because there is two places where you can set decimals. In Preferences/General where you can set the number of decimals and in the currency itself where you can set using decimals yes or no. I can imagine there is quite a lot of currencies where decimals is not used

  • It is strange because there is two places where you can set decimals. In Preferences/General where you can set the number of decimals and in the currency itself where you can set using decimals yes or no.

    … and inside templates.

  • But I use the default one and change in any of those two places dont change prices in the FO. Setting decimals to 0 set the price including tax in the BO without decimals, no other change.

  • Pity I have no PS shop up anymore so I cant compare

  • Proper decimal place control is required for Japan, China, and Korea. Not the current main focus of 30bz perhaps but all are huge eCommerce markets.

  • @mdekker said in Currency format:

    Hi BeeSide,

    The currency format is now automatically adapted to the visitors locale (language + country). This, because e.g. the euro can be displayed in several ways in the euro countries.

    Is there a reason why you want to change the decimal separator in your locale?

    Despite the fact that this does not work properly yet, I’m afraid this is the same logical error like in PS 1.7. If the currency format does no longer depend on the currency but on language and country, every currency will be displayed the same way for the customer, as soon as he chooses a language. This causes problems. Some examples:

    Language: German, Currency: Euro
    Currency display:

    1. Austria: € 399,10
    2. Germany: 399,10 €
    3. Switzerland: 399.10 €

    Language: German, Currency: CHF/FR
    Switzerland: CHF 399.10 or 399.10 FR

    Language: French, Currency: FR
    Switzerland: FR 399.10 or 399.10 FR

    Language: German, Currency: USD
    thirty bees: 399,10 $
    PS 1.5 - 1.6: $ 399.10 (with or without blank after curreny sign depending on chosen option)

    Next you should consider the thousands seperator:
    Switzerland: inverted comma
    USA, GB, Canada (English), Israel etc: comma
    Germany, Belgium, Denmark, Italy, Sweden etc.: dot or blank
    Canada (French): blank
    … and so on.

    And btw there is no special language for Switzerland, Austria or GB. (Try to import for example German(CH) and the customer will meet a 95% English shop language.)
    So it actually makes sense to restore the former behavior with options currency format and blank. A real improvement would be to replace the format options by a free input field stored in a new db table for every currency format you want to define.

  • In my case the format is just fine (the thousand separator, symbol location and symbol space is perfect).
    The only thing that I need is to get rid of the decimal points.
    The shop owner want to show only round numbers not floats (399 and not 399.00).

  • If you’re going to work on this, don’t forget very small amounts, which are currently almost impossible. For example, electronic resistors can cost less than half a cent, 0.0042 Euros. This results in a displayed price of 0.00, unless one raises the number of digits for all prices, even the 100-Euro ones.

    A great solution would format prices as you suggested, but add a digit for each zero right of the decimal for prices < 1.

  • @mdekker Sounds good, but I really doubt how to manage this by just using the configuration table. This may be ok for a predefined currency pattern, but you would need a db field to store the different patterns. In general I’d agree not to touch the db schema, but in this case it would be helpful to redefine the format field in tb_currency from tinyint(1) to varchar(12).


Looks like your connection to thirty bees forum was lost, please wait while we try to reconnect.