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 [email protected] http://lists.plone.org/mailman/listinfo/product-developers
