There are commonly know features of Zend Framework, and some tiny ones that pass unnoticed until one wants something specific. One of such features are routes chains. Robert Basic wrote quick and simple tutorial about chaining routes through another one, to create multilanguage website URLs:
On a forum, there was a question today, about adding language “support” to the routes using Zend Framework. The guy wanted routes like /en/foo/bar or /de/baz. I wrote there an example for that using Zend_Router_Routes_Chain, so just posting that example here, too 
(..) Basically, we’re prepending the language route to the other routes. This way, we have defined the route for the languages in one place only, plus, the other routes don’t have to worry about the language, too.
Interested how Robert did it? Follow to his blog, see his 30-line code and think about all other possibilities.
There is new post on Thomas Weidner’s blog, where he talks about he’s recent contribution to Zend_Framework. Zend_Framework 1.10 should be shipped with his new Zend_Filter_Boolean, new version of Zend_Validate_Barcode and Zend_View_Helper_Currency. Thomas is also working on I18N webinar.
So I am preparing some I18n webinars… the first will cover Basics of I18n, usage and internals of translation. Its mainly for beginners and people who want to get knowledge on workflow and some internals. Of course it will also cover some examples. When I am receive good responses on this webinar I will also cover other I18n themes.
Zend_Acl is usually presented as a tool for restricting access to controllers and actions. It is one of most common use cases of the component, but the component itself can control access to any kind of resource. Adam Jensen wrote interesting post about implementing models as Zend_Acl resources to define access control rules on business logic level.
As a result of these concerns, I decided on a lower-level, model-centric approach for this blog: my models are my resources. Each model class implements Zend_Acl_Resource_Interface, and the ACL specifies “create,” “read,” “update” and “destroy” privileges for each class (more or less). This is a nice paradigm, because it allows for access control at a much lower level: instead of restricting access to the user interface (the controller layer), we restrict access to the business logic (the model layer). (It also makes dynamic assertions a lot more useful, for reasons I may explain some other time.)
In his quick tutorial he shows how to Doctrine_Record_Listener to add ACL to models and make it flexible.
