Comment 4 for bug 1363212

On 2 September 2014 15:42, Rodney Dawes <email address hidden> wrote:

> Right. I'm trying to fix bug #1362716 at the moment, in a reasonably
> generic way, so we can appropriately display USD vs $ vs EUR v s €, etc…
> depending on what the server gives us and the locale of the user. Having
> the matching field of currency in the search results would help with
> that greatly for now.
>

Part of the problem here is that the currency isn't exposed in the
devportal feed that Click Package Index consumes. Now, ​I've had a dig into
the devportal code, and for Click packages there is a dictionary of prices,
which is exposed in the prices field, and the price field is just a
convenient accessor to the USD entry in that dictionary. Currently,
however, there is no UI that I can find to actually set a price. On that
basis, I think a conversation still needs to happen around managing
multiple prices for Click packages, and it needs to involve Click Package
Index, Software Center Agent and client teams. I'm reluctant to just add a
placeholder currency field to the Package resource in the short term
without understanding the long term plan.

Also, is this a duplicate of bug #1258542 ?

Perhaps we can re-visit providing the "prices" field later, but I do not
> like it, as it means the client needs to somehow determine which
> currency to use.
>
>
​Right - we already talked briefly about this in Malta. As I said there, I
don't think we have all the information we'd need to properly format a
display price on a per-request basis. In the Index, we don't even know who
the user is, so we currently have no way ​

​server-side to figure out what payment methods they've set up and what
currencies those payment methods support. We kind of have the user's locale
via the Accept-Language header. We could pass through the list of
currencies supported by the client, but in doing so we'll render a lot of
the front-end caching useless (because now any given request can vary based
on architecture, supported frameworks, geographic locality, ​accepted
languages, accepted content types and accepted currencies).

I don't know what information the Click Scope has about payment methods and
currencies, but maybe QLocale::toCurrencyString() is enough to format a
price appropriately for a given locale if we can find an intersection
between the currencies offered for a package and the currencies offered by
a payment method?

--
James Tait, BSc. | https://launchpad.net/~jamestait/
Software Engineer, Canonical Online Services
Ubuntu - Linux for human beings | www.ubuntu.com