Currency management in Plone

Hanno Schlichting plone at
Sun Aug 26 12:07:27 UTC 2007


moving this back to product-developers, as this is not about Plone itself ;)

Wichert Akkerman wrote:
> Hanno Schlichting wrote:
>> Wichert Akkerman wrote:
>>> I just released version 1.0b1 of a new product: simplon.plone.currency.
>>> This is a simple product for Plone 3 that allows you to manage different
>>> currencies in your site: you can add and remove currencies and manage
>>> their conversion rates. It includes a database with description and symbols
>>> for all currencies as well.
>>> By itself this product is not very useful. It is intended to be used
>>> as a component in products that need to use currencies in some way. If
>>> anyone is working on such a product I would love to hear some feedback.
>>> You can find more information and a downloadable package in the
>>> python package index:
>> I have looked at it briefly and wonder why you didn't reuse the currency
>> information available in zope.i18n.locales?
>> While in Zope2 the current locale is not directly available from
>> REQUEST.locale as in Zope3, with Plone3 it is available from the portal
>> globals view (
>>   >>> portal_state = queryMultiAdapter((context, request),
>>   ...     name=u'plone_portal_state')
>>   >>> locale = portal_state.locale()
> There is a problem here: I do not have access to the request at the 
> place where I would need it. The way the API works is that you have a 
> currency object which is stored in a (local) utility. The description is 
> a read-only property on that instance.
> Forcing users to pass the request in would make for a pretty bad API so 
> I do not want to do that. I see one possible option though: create a 
> message dynamically. At that point we have the id and we can get the 
> English text from zope.i18n.locales, so I can do something like this:
>      from zope.i18n.ocales import locales
>      english=locales.getLocale("en", "gb", None)
>      return _(self.code, default=english.numbers.currencies[self.code])
> that would push the point where the translation machinery is invoked to 
> a later point when the request is available. I have not tested this, but 
> I am hoping that if I use the Zope message factory this will still 
> pickup the correct translation.
> Does that sound a bit sane?

Sorry, but this won't work. The information in the locales has nothing
to do with the gettext-based translation machinery. There are no message
factories involved in this.

This means that you cannot mark the currency in the data-centric part of
your code as translatable but you need to take care of it in the
user-visible part which has access to the request. The example I shown
is a Zope3 formlib widget. Other widgets or views can use the same

The basic recipe is to use a distinct key for the info (like u'USD') and
to look up the displayName of this key in the current locale (which is
in the negotiated language).


More information about the Product-Developers mailing list