In HiveMind 1.0, you set the locale once, when you build the Registry and you're stuck with it. That's pretty limiting, especially for a web application. In a web application, such as a Tapestry application, each request (which is to say, each thread) may be using a different locale.
Using a fixed locale limits the usefulness of HiveMind. It means that the business layer can't generate localized error and status messages and pass them back up to the presentation layer. Instead, you fall into the same old trap of exceptions and return codes so that the presentation layer can generate those messages (in the proper locale). That's counter to whole philosophy of HiveMind: colocate everything, so that they can collaborate richly and limit the amount of ugly plumbing and klude code you have to write.
Well, I just checked in changes to HiveMind 1.1 that allow the locale to be changed at any time. The Registry's locale is simply the default locale. The key aspect of this is the Messages object injected into your services ... this was how services gained access to localized messages. The new implementation is smart enough to combine the request message key with the thread's current locale when obtaining a message.
For a web application, this means that, as soon as the client's locale is determined, the ThreadLocale service should be notified. Any messages generated by any services will then be in the proper locale. Tapestry 3.1 has a particular place for doing this ... in fact, the engine's getLocale() and setLocale() methods will be changed to simply invoke getLocale() and setLocale() on the ThreadLocale service.