|
Note - this document is still a work in progress. Please do not make inline
comments in the proposal - use the SkinnableAndLocalizableObjectsDiscussion to
make comments.
Contact
Martijn Pieters (mj@digicool.com)
Problem
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.
Scope
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.
Deliverables
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.
|
