Automattic / woocommerce-payments

Accept payments via credit card. Manage transactions within WordPress.
https://wordpress.org/plugins/woocommerce-payments/
Other
175 stars 69 forks source link

Incorrect total price formatting for RON (Romanian Lei) #7793

Closed oaratovskyi closed 8 months ago

oaratovskyi commented 11 months ago

Describe the bug

To Reproduce

  1. As a merchant, ensure Multi-Currency is enabled and RON (Romanian currency) is added.
  2. As a shopper, visit store, switch to RON currency, add something to the cart.
  3. Observe incorrect price formatting

Screenshots

image

Actual behavior

Price formatting is incorrect - 204,00 lei RON.

Expected behavior

It should be either only 204,00 lei, 204,00 RON, or the financial complete lei204,00 RON

Desktop (please complete the following information):

Additional context

Slack chat p1699468476011659-slack-C03KTTK2YMA

pierorocca commented 9 months ago

Revised:

Noting that 204,00 lei RON is like writing $204,000 USD aka Explicit Format.

There's a separate bug where cart totals are not showing the Explicit currency yet for RON it is showing.

Short format: 204,00 lei Explicit format: Shopify says they use https://cldr.unicode.org/index as their standard reference but I see differences in their explicit format on Shopify 204,00 lei RON vs. the format on Shop Pay RON 204,00 lei. Every top Romanian website I've been on is only using lei and after the number, never before.

pierorocca commented 9 months ago

And on a different Shopify Store on Shop Pay i'm seeing RON lei 204,00. Very confusing as we've covered every permutation.

pierorocca commented 9 months ago

Doing a bit more research and also asking AI, the ISO code RON in an explicit format I think it comes down to design choice if it's placed to the left or right of 204,00 lei.

USD $1,000 $1,000 USD

I quite like how Shopify has lower prominence on the ISO currency code while it helps distinguish between all the countries that use dollars $.

Image

So long way to say the 204,00 lei RON is not an incorrect representation. It's an ok option.

vladolaru commented 9 months ago

Thanks for doing all this research, @pierorocca !

I agree it is complicated and we should split it by two concerns: human-relatable price and accounting-proof price.

If I am a Romanian shopping in a Romanian shop, I will only see either 100,00 lei or 100,00 RON. In accounting, I will only see 100,00 RON.

There is no scenario that in real life I would see 100,00 lei RON. I agree that, technically, it is not incorrect, but if we are concerned with shoppers and how they perceive things, it will feel like a bug.

Just for context, many times we default to using the ISO code because there is also the Moldavian leu (MDL), and prior to 2005 we had a leu with 4 more zeros (ROL).

At the end of the day, I think merchants should have the controls to decide where to place themselves between "human-relatable price" and "accounting-proof price" depending on their target audience (B2C, B2B, etc). I don't think this is a decision we can make for them.

pierorocca commented 9 months ago

@vladolaru could you elaborate on what "accounting-proof price" is and how it relates to shoppers? Do you mean ledger based accounting?

For reference including Shopify's design guidelines for localized currency formatting which includes a link to the CLDR standard. https://polaris.shopify.com/foundations/formatting-localized-currency

vladolaru commented 9 months ago

Sure @pierorocca

By "accounting-proof price" I mean a price that doesn't leave room for ambiguity. For example, $5000 is ambiguous, $5000 USD is much less so, $5000.00 USD is an accounting-proof, unambiguous price. The same goes for lei: 5000 lei is ambiguous, 5000 RON much less so, 5000.00 RON is what is required from an accounting perspective (at least on invoices and such).

I don't think regular shoppers are concerned much with accounting. In a B2B scenario, they might be but mainly about what is shown on receipts and invoices (since those end up in the biz accounting).

What I advocate for is letting merchants, depending on their shop audience, decide how they wish to display prices (multi-currency or not). The core provides some controls around this:

twXoRM.png

But I don't think they are sufficient. How do I choose to display ISO (RON in this case) instead of human-readable (lei)? On the MCY side, I think merchants should have the same controls core offers for the default currency, on a per currency basis.

pierorocca commented 9 months ago

Gotcha. The use of the word "accounting" threw me off because accounting currency format is a specific format used for accounting contexts. Accounting currency format uses brackets to denote a negative value ($1,000.00) and there may be specific alignment of the currency symbol. There's no legal requirement for the ISO currency code on an invoice and is usually included when more than one currency is on the invoice or when selling internationally.

What you're referring to is what's called the Explicit Format and includes both the currency symbol and ISO currency code. Typically, the Explicit Format is used on Totals, especially when multi-currency is enabled to prevent shopper confusion but it's not needed at a line item level. The short format, only the currency symbol e.g. lei, is sufficient for line item prices.

I see per https://github.com/Automattic/woocommerce-payments/pull/4384 that the Explicit Format is removed when multi-currency is not enabled. It's easy for a Canadian shopper to shop on a US site and not know that it's a US site and in USD so I'm not sure enabling it only when multicurrency is enabled is the best practice. I see that Shopify does make this configurable, only if multicurrency is not enabled. I appreciate that as a Canadian.

I'm summarizing what I think are the main points, including a complaint about the existing core currency settings UI:

  1. 204,00 lei RON - this is per design when Multicurrency is enabled. Explicit Format on Totals is a best practice and in order to protect shoppers and merchants, we don't want this to be an optional setting (when multicurrency is enabled). e.g. a Moldovan shopping on a Romanian site seeing only lei would not know for certain what currency is presented.

  2. When multicurrency is not enabled, Explicit Format, isn't a configurable option. In specific cases like Canadians shopping on US sites (common), it'd be good to give merchants the option to enable it for extra clarity. As a best practice, I'd make this enabled by default, and as Shopify has done give a little less prominence and different color to the ISO currency code in the UI.

  3. There's an open enhancement request related to the core currency settings UI. It basically allows a merchant to make mistakes and usability is low. For example if a merchant selects Japan YEN from the currency dropdown, none of the other fields auto-update despite the YEN having a very specific, non-configurable format.

I like how Shopify has built in CLDR so that 1) they're using an international standard in terms of presentment 2) they have clear design guidelines about localization and currency presentment and 3) a merchant doesn't need to configure the settings thus making the platform much easier to setup and use.

I'm inclined to close this out as not a bug as the Explicit Format, despite what a Romanian or other national may be used to seeing shopping domestically, is a recognized standard presentment format for multicurrency scenarios.

vladolaru commented 9 months ago

Oh! Didn't know about that accounting format. Probably it is North American specific or something very accounting specific. I am neither 😅

Thanks for all the context. TIL

Yes. I agree that there isn't an easy way forward that is both safe to use and not overly complicated to implement.

oaratovskyi commented 8 months ago

Should I close this issue then?

pierorocca commented 8 months ago

Yes I think so. We'll later in the year have a fresh look at currency representation and see if our design team has the bandwidth to pull together a set of localization design guidelines similar to what I see Shopify has created. From that guideline we can decide to keep status quo with some tweaks or perhaps look to implement a standard like CLDR.