Weblog

published Nov 03, 2021 , last modified Nov 04, 2021

Translations of portal status messages in KSS

published Sep 10, 2008

What do you do when KSS does not translate your portal status messages? And what if Dutch translations are shown when you expect English?

You have a package that has some translations. One of those translations is used in a portal status message that gets shown by a KSS action. Something like this, taken from the xm.tracker package:

from kss.core import kssaction
from plone.app.kss.plonekssview import PloneKSSView
from zope.i18nmessageid import MessageFactory

_ = MessageFactory('tracker')


class KSSStart(PloneKSSView):
    """kss view for starting the timer"""

    @kssaction
    def start_timer(self):
        message = _(u'msg_started_timer',
                    default=u'Started the timer')
        plone = self.getCommandSet("plone")
        plone.issuePortalMessage(message)

But -- tragedy of tragedies! -- it gets shown in English even though you have a fine Dutch translation and your Plone Site has Dutch as default language. What can possibly be wrong? Two things really.

plone.app.kss

For translations of portal messages you need plone.app.kss 1.4.3 or later. Check your Plone version. If it is Plone 3.1.5 or later you are fine. If you have 3.1.4 or earlier you need to upgrade Plone or update the plone.app.kss package.

Products/*/i18n

Are translations still not showing up? Then your package is probably in the Products name space and your translations are in an i18n folder. That directory is the domain of the PlacelessTranslationService from Plone. Those translations are not found by the zope.i18n translation machinery, which is in effect in plone.app.kss. You may encounter the same problem when you are using pure Zope 3 page templates.

To fix it, you need to add a few lines to your product. For example, I just added this in Products/eXtremeManagement/__init__.py:

from Products.PlacelessTranslationService.utility import PTSTranslationDomain
xmdomain = PTSTranslationDomain('eXtremeManagement')

Then register that as a utility in your configure.zcml:

In the next major Plone release (4.0) this will not be needed anymore, but that is still quite a way off. You will probably be using locales then anyway.

I want English!

While I am writing about translations, here is something else I bumped into. Take a Plone Site with Dutch as default language and English as an allowed language. Take a package with a registered locales directory. It has Dutch translations in the locales/nl/LC_MESSAGES directory. Now visit that site with English as the preferred (or only) language of your browser. With the proper settings in the portal_languages tool of your Plone Site, this should present the user interface mostly in English. But: the translations for your package will be shown in Dutch! What is wrong here?

The problem is that the translation machinery does not know that the default strings (message ids) of your package are in English. It might as well be in Chinese and it refuses to guess. So what you do is: create a locales/en/LC_MESSAGES directory, copy your mydomain.pot file there and change its name to mydomain.po. You probably want to change some of the headers of that file slightly. Restart Zope and you should be able to enjoy the beautiful English language again. Tally ho!

Refreshing content with KSS

published Aug 03, 2008

Give your content a refreshing KiSS!

I just uploaded a how-to on kssproject.org about refreshing content with KSS. Read that if you are interested in the goal of that how-to:

You are looking at a page on your Plone Site. You change the review state of the current object. Without a complete page reload you want some bits of the page to change automatically. Plone itself is doing that already. You want to have that kind of fun too!

Omelette: now even tastier!

published May 29, 2008

collective.recipe.omelette is a must.

David Glick has just released collective.recipe.omelette version 0.5. You have got to try it. As you may know, it makes a parts/omelette/ directory with links to all the various eggs that you have in your buildout. With version 0.5 it can do the same for Products. And you can point it to some more packages. In a standard Plone buildout you would have this part:

[omelette]
recipe = collective.recipe.omelette
eggs = ${instance:eggs}
products = ${instance:products}
packages = ${zope2:location}/lib/python ./

Don't forget the ./ at the end. Note: the README.txt of the recipe mentions modules instead of packages but that is a typo. Fixed in subversion.

I especially like it that with this configuration you can look in parts/omelette/Products and have links to the exact same Products that your zope instance will be using, whether a Product is in an egg, in the productsdistros/checkouts directory, in parts/plone or in the Zope 2 Products dir. That is sweet.

Thanks a lot David!

Grok sprint wrapup Sunday

published May 04, 2008

I will just briefly list what has been done.

  • Jasper and Reinout finished work on traversable stuff.
  • We have ordered containers.
  • Peter and Christian Klinger worked on caching response headers.
  • The grok.url method got cleaned up.
  • In grok.require you can point to a Permission class.
  • A lot got done for Relational Database integration with SQLAlchemy, without actually needing a lot of code.
  • We have a sample implementation for a BREAD/CRUD application; will be checked into the grokapps subversion section.
  • We worked on KSS integration.
  • We talked about resource directories and the static directory.
  • Peter made a sample application and tutorial about skins and layers.
  • Philipp released grokcore.component and merged the needed changes to core grok.
  • Wim made a mockup for the Grok homepage.
  • A lot of documentation was written. Automation is done using grokdocs.
  • z3c.testsetup/grok.testing was added by Uli.
  • "Zope 2 stuff" was worked on by Godefroid and Eric. So five.grok.
  • JW and Philipp worked on martian directives. Three merges need to happen, which we will work on now. Makes it easier to write new directives and easier to get information from directives. All existing third party grokkers will then not more work anymore; we feel it is still early enough to do this, but the merge should happen sooner rather than later.
  • Christian Theuni worked on the testrunner and the zodb.

A Grok Tour and Todo

published Apr 30, 2008

Welcome to the Grokkerdam sprint!

The Grokkerdam sprint has just started in Rotterdam. Martijn gave a big introduction to Grok, throwing in things that can be done in the Sprint, and with comments by the audience.

Some core Grok concepts

  • DRY: Don't repeat yourself. By not needing to add code to lots of files, you save time and errors.
  • Convention over configuration: sensible defaults. You can more easily look at other people's code and still understand where everything is.
  • We have "grokkers" that deduce declarations from python code. So hardly any zope 3 configuration (zcml) is necessary.

Grokking

Grokking is triggered from zcml, with the grok directive. This should be the only zcml that is needed. It scans modules in your code for classes that subclass grok's base classes. Grok then registers these components with the Zope Component Architecture (ZCA).

If you follow standard patterns, you can leave out grok directives (grok.name, grok.require, etc) from your code, but if you need more control, you can use them.

Storage

grok.Model is usually your base class. Very light weight. It should be contained in a class with grok.Container as base class. There is no ordered container class yet; we will add it to the todo list of the sprint.

Traversal

Traversal in Grok is very easy. There is of course the default traversal that just works. But if you need more control, you add a traverse method to your model. This can instantiate virtual objects on the fly.

You can also use grok.Traverser to implement custom behaviour for someone else's context.

Sites

Sites is Zope 3 is a place to store local utilities and tools. Grok has grok.Site for this. As todo we may want to add locally defined views and adapters. And having non-persistent local utilities would be useful as well. And we want to be able to install local utilities in an existing site, instead of only in a new site, without hairy upgrade code.

grok.Application is a special kind of grok.Site.

Todo: look at GenericSetup to make upgrades easier.

grok.Indexes makes working with the catalog easier. Todo: upgrading indexes in an existing site should be possible.

Components

grokcore.component has several components you can use, also in plain Zope 3:

  • grok.Adapter
  • grok.GlobalUtility for looking up e.g. the global email sending utility.
  • grok.MultiAdapter if you need to adapt more than just one context (for which you would use grok.Context. Not used a lot currently.
  • @grok.subscribe is a decorator for subscribing to zope 3 events

Todo: set up caching for views.

Miscellaneous other utilities

Using persistance:

  • grok.LocalUtility
  • grok.Annotation: you don't need to mess around with own generated keys anymore.

Views

  • grok.View: the most magic of the grok base classes, as we wanted to make this really simple. There is the url method which you can give some parameters (optional context and optional string for an alternative view). Todo: explore keyword arguments for these parameters. And explore improving flash messages (compare with Plone portal status message), which does not always show in combination with redirection.
  • grok.Skin: this is just a name and a single layer (grok.Layer) that is associated with it. grok.Layer is just an interface; you can use inheritance to combine layers. Todo: more skin based control of what views exist. From a security perspective it is not nice that anyone can just add e.g. @@contents and see the ZMI. We need to make that easy (grokking it).
  • grok.GrokTemplate: ugly name, needs more implementation. Some integration to use e.g. Genshi instead of Zope page templates. Todo: write Jinja (from Django) integration and other template languages.
  • grok.ViewletManager, grok.Viewlet: You register viewlets (html snippets) for a viewlet manager. In zope 3 you need to do quite a bit of stuff to set up viewlets and viewlet managers. Grok of course makes that easier. Having viewlets available at a specific url is good for caching; the Lovely guys have done something for this. Todo: look at z3c.traverser for maybe making that easier and default. KSS (or any Ajax) likes viewlets. Todo: viewlet documentation.

Alternative views

  • grok.XMLRPC
  • grok.REST
  • grok.RESTProtocol
  • grok.JSON

Security

Security is all view related.

  • grok.Permission is used to define permissions. The grok.require directive is used to require a permission. Todo: see if we can refer to classes instead of strings in grok.require.
  • Todo: default authentication UI. With Zope 2 you have the acl_users. With Grok we currently ask people to roll their own code. There is a good base in Zope 3 to use.
  • Todo: authorization APIs.
  • Todo: model-level security instead of only on views. You can give local permissions. But security checks are currently only be done on views. We threw the object checks out as it is a pain to work with, but we can look into making this easier. The zope security is very powerful.

Formlib

zope.formlib based forms.

  • Use grok.Form as base.
  • grok.EditForm uses the schema of your class. The standard template is pretty ugly though and does not integrate nicely with your UI. Todo: better templates for forms. Viewlets might be handy here.
  • grok.DisplayForm just displays stuff.
  • Todo: z3c.form support. Perfect candidate for making easier by grokking it.

That concludes the component tour.

What else?

Grok is more than just the API. It is a sort of language with base classes, decorators, methods. It is an attitude to be friendly to beginners.

We want smooth installation for Grok.

  • Goal: smooth installation for Grok and Grok applications.
  • We maintain a list of versions of libraries we use: pinned versions. That works for core Grok. But it did not work for megrok.form recently. Todo: update to the Zope 3 KGS list of versions (from Stephan Richter). All tests in the KGS pass; with the Grok version list the Grok tests pass, but the other tests did not all pass. That is not good.
  • Todo: downloads sometimes fail. Sourceforge sometimes moves stuff around, the cheeseshop can be down, zope.org can be down. Todo: look at zc.sourcerelease to make one tarball of Grok.
  • Todo: version pinning for extensions. buildout.cfg may or may not be better than setup.py for this.

Relation database integration

  • This should be a first-class citizen in the zope world.
  • Todo: figure out default story for RDB integration. This can be a big discussion/fight about what we choose.
  • Todo: auto generation of Zope 3 schemas from database table schemas. Often you will find you are repeating yourself here.
  • Todo: Model and Container base classes for RDB. So these would not have persistence as they are not stored in the ZODB.
  • Todo: patterns for security integration. You need a bit too much methods currently.
  • Todo: obviously add documentation.

WSGI

Web Services Gateway Integration. We have code for this, but we need to make this easier; possibly put it in grokproject by default.

  • Todo: check the differences between grokproject and zopeproject; there should not be much differences.
  • Todo: make grokproject really available as a paster template. It can be done already, but we need to document this.
  • Todo: put in a few useful WSGI components for development. Look at repoze too.
  • Todo: development and deployment profile.

AJAX

  • Todo: finalize KSS integration.

Resources

  • Todo: consider what is the right way for Grok to do this.
  • Todo: think about making it possible to overwrite static resources in extensions.

Introspector

  • Uli has done work here and will be working on it for Google Summer of Code.
  • Todo: improve the object browser UI. Show which defaults are used for directives that are not explicitly in the code. In Firebug you can see the calculated style; something like that would be useful.
  • Todo: new directive implementation in Martian. grok.name has different defaults depending on where it is called. We can make that more explicit, guard against unforeseen uses.

Miscellaneous

  • Back to the future: through the web (TTW) development. This made Zope 2 popular. We can look at five.customerize for overriding views. Defining a schema TTW would be cool, if we can avoid the problems from ZClasses.
  • Make CRUD UIs TTW.

Documentation

  • We have the beginner's tutorial. It gets you started, but it can be longer. This is maintained in subversion. For other documentation: just add it to the website and publish it.
  • We have developer's notes in subversion.
  • Todo: The Reference.
  • Todo: website improvements. I could not update the link and text in the sidebar. This was hardcoded. Kevin Teague has done a lot of work here, but we need more people here.

Rule: a sprint project is not finished without documentation!