Z Object Publishing Environment

Search | Download | Documentation | Resources | Members




Join Zope.org
Log in

Developer Home
Get Involved!
The Fishbowl

 Zope Exits

Zope Newbies

page served by app1

Proposals Table of Contents Last edited on Jan 20, 2001 11:29 pm


Note - this document is still a work in progress. Please do not make inline comments in the proposal - use the SkinnableAndLocalizableObjectsDiscussion to make comments.


Martijn Pieters (mj@digicool.com)


Current Management screens and other DTML is bound to the class, and cannot be easily changed and experimented with. Also, any text within these views is hardwired, which makes localizing the Zope management interface neigh impossible, and likely to break.

Moreover, the current interface is aimed at low common denominator of browser functionality, that doesn't always exploit the possibilities new browsers offer. Also, browsers with a yet more limited featureset have problems displaying the current interface correctly.

Proposed Solution

This proposal aims to provide a mechanism for Zope to discover and use different skins and locales for disk based DTML files and images, and provide Zope Products with localized dictionaries of strings.

  • It should be easy for 3rd party skin developers and translators to develop and distribute new skins and translations.

  • An authenticated user should be able to indicate what skin and what locale it wishes to use. This preference should be stored persistently.

  • There should be an easily configurable way to assign a skin or locale to a set of conditions matched by a request, if no explicit choice has been made by the user. This way, a skin can be assigned to the User Agent header, and locales to the accept language header, for example. Or, users on an internal network get presented a more powerful interface.

  • There should be a clear API for accessing localized string dictionaries, called string bundles.

  • New proxy objects that take the place of regular Image and DTML objects that will pass on all calls to the underlying DTML or Image object that is associated with the current skin.

  • The proxy objects will automatically pass in the correct string bundle for the current locale. DTML should not use literals anymore, but refer to the entries in the string bundle.

  • All Product can, but don't have to, support this API. If the Product supports this API, but not the requested skin or locale, a default skin and locale will have to be present.

Risk Factors

  • The proxy objects will inhibit a small performance hit, en cost extra memory for every extra skin and locale. We should look for optimisations.

  • It is unclear where the user preference should be stored.

  • It is unclear what to do for Anonymous if the Anonymous user is given the View Management screen permission. Do we fall back to the default, do we let Anonymous (which will most likely be multiple people) switch skins and locale, or do we use a cookie in this case.


This is a simple project that should be implemented within 3 days. It may be that the Help system will hook into this at some point in the future, but this is outside the scope of this project.

The proxy objects are for file based DTML and Images only. Through-The-Web Products are outside the scope of this project, but is a furute possibility.

This project does not provide methods for localized time, date and currency display.


  • A UI for users to choose a locale and skin.

  • A registry of available locales and skins.

  • A string bundle API and mechanism for storing and loading the strings.

  • DTML Document and Image proxy objects.

  • Documentation for Product developers.

View source SkinnableAndLocalizableObjects
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search:
Privacy policy       Printable Page       Feedback about Zope.org