Hi,
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:
>>>
http://cheeseshop.python.org/pypi/simplon.plone.currency/1.0b1>> 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 (plone.app.layout.globals.portal):
>>
>> >>> 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
information.
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).
Hanno
_______________________________________________
Product-Developers mailing list
Product-Developers@...
http://lists.plone.org/mailman/listinfo/product-developers
