Product.priceString could be formatted

[rocboronat]

Right now, priceString returns things like €3.99. With EUR, for example, it should appear as 3.99 €. And it could also take into account the Locale of the device, using the comma instead of the dot sometimes, giving 3,99 €.

This is the invoice Google sends:

[ghost]

Hello! It doesn't seem like we have quite enough information to send this to a human yet to help out. We would love if you could provide more details about your issue by following the template without modifying any of the pre-filled text. If you're looking for support, head over to our Community.

[aboedo]

Hi @rocboronat!! Thanks for opening.

We do actually format the price, although the locale can be a bit confusing:

For Google Play items, we're bridging over to the native getPrice, which already returns a formatted string.
https://developer.android.com/reference/com/android/billingclient/api/SkuDetails#getPrice()

For Apple items, we format using the priceLocale from the underlying SKProduct.

In either case, things can get a bit confusing, though, because there are two locales:

• the device's locale, which can have its own setting for currency format
• the store account's locale, which will also have its own thing.

For example, you could have a device set to US-en for the UI and currency, but your Google / Apple account is set to Spain, and then that would render using the store account's locale, i.e.: Spain.

Hope that makes sense!

[rocboronat]

Hummm! I trust you but then the store is doing something incorrectly...? Because I think the format depends on the currency and not the any device or store locale. I mean, in the US you write 10€ and $10.

[aboedo]

I believe in "en-US" you'd write that as €10. Locales are weird and the exact rules are a whole field of study, but this is what I've seen.

At least that's what Apple's formatter does, I just tried it out in a Playground (see output on the right):

Here's the code if you'd like to try it out in Xcode https://gist.github.com/aboedo/cc1fff7275e2eaee476c6728e1a31674

[aboedo]

btw changing the line where we define the spainLocale to use "en-ES" renders the same output

[aboedo]

Hope that helps make sense of it!

[rocboronat]

Then it proves you can't rely on it. The good way to render it is 10€ and $10. If you rely on that, you're giving bad outputs.

If I don't do the trick and just print your formatted price, my users will see badly formatted prices.

Being a solution to work with products, purchases and transactions, it would be great you gave well formatted prices. In case you're interested, this OS project has a great list of currencies with all the data you needed to format the prices:
https://pub.dev/packages/currency_picker/versions/2.0.3

[aboedo]

Then it proves you can't rely on it.

Could you clarify this? What makes you not want to rely on this?

I'd actually recommend that you do rely on the values provided directly by Google / Apple, which are the ones we're surfacing, since those are using the exact same formatters that Google / Apple's paywalls will display to the end user.

I.e.: if for a given user, you get €10, this should match the price as how Android / iOS will display it when the OS asks for confirmation.

It might differ from the device's locale, but it will not differ from the Store's locale, and will be consistent with how the user's account is set up, so it should appear normal to the user.

I am surprised to see that Google's invoice has a slightly different format, did the paywall display the same format?

I'd strongly advise against trying to figure out currency formatting yourself, since it's far from trivial and will differ significantly in similar-looking locales.

For example, if for that same example you used Uruguay Spanish (my native tongue), that'd be EUR 10.00, as opposed to 10.00 € in Spain Spanish or €10.00 in US Spanish.

Apple and Google have created very comprehensive formatters to handle all of these cases, and those are the ones in use by our SDK.

Note that in none of the cases, though, you'd have a badly-formatted price, since this is handled by the OS itself exclusively.

Let me know if this helps clear things up or if you have more questions about it!

[rocboronat]

For example, if for that same example you used Uruguay Spanish (my native tongue), that'd be EUR 10.00, as opposed to 10.00 € in Spain Spanish or €10.00 in US Spanish.

Honestly, I guess I'm moving out of my knowledge zone. It's very difficult for me to read €10.00, but if you are so sure about it, I'll sleep better knowing I was wrong.

Thank you so much for your support @aboedo! Muchísimas gracias 😃