Although I'm not an expert I'll try to answer this. The fast answer: It is up to developers to implement their own logic. "Dynamic" multilingual sites can vary a lot. Starting with the question: What is the source of the data? For example I've started a multilingual blog module which can be found at https://github.com/JPG-Consulting/zf2-blog/tree/planning. Right now I'm using Doctrine to connect to the database and have "per row" localization. One of my goals is to keep the url path translated and my English blog may or may not contain the same entries as my Spanish blog. I could add an extra field to keep translated articles nested if I wanted to, but that could be something I may or may not want. Therefore there are many approaches as how to face the features of a given site. Talking about blogs, although it is not multilingual, you can also look at https://github.com/phly/PhlyBlog. The approach here is through a file repository instead of a database. So, if you wanted to make it multilingual the approach is different and you may face it through a folder structure instead of database rows. IMHO, the article faces a really generic scenario such as creating a full-blown CMS that would serve all instead of tweaking things up. I really don't like the one size fits all philosophy and like it better if I'm able to use modules that fit my needs. The reason I'm saying this is the article focuses exclusively in database translations and that may imply reinventing the wheel from time to time. Let’s take a deeper view taking as an example the navigation menu. The navigation component already performs translations for you so you could simply store the default language entries in your database and create the po files for your menu on the fly through PHP. This keeps the translation separated from the database while more dynamic data may be stored per-row. This is a similar approach as how ZF-1 took care on some translations such as country names. The PO approach can be useful for short dynamic data or data that doesn’t change often. For example, I don’t see why I would want to change the contact page that often so I usually keep the contact page translation in PO files. This can also apply to other common pages as the “about us” page. Imagine we have a “Products” page where the landing page is mostly static except for the products we show in it. I would probably use PO files to translate the static text of the page while I would leave the product blocks database-driven. There are so many approaches to localizing a site it would be almost impossible creating a one size fits all module. Even if possible there would be so many possibilities that it would create a huge bottleneck for the application. If you look into CMS systems you will only find the one size fits all solutions. Recently I’ve seen lots of companies developing sites using Wordpress which is kind of a one size fit all solution. Why reinvent the wheel if that’s what we are looking for. I guess if you’re developing with Zend Framework you are looking for a nicer approach that really sticks up to your site needs. That doesn’t mean you cannot have a CMS, but I would keep dynamic pages in a CMS module instead of making your whole project a CMS. Even the decision on how to treat locales may vary. I’m currently writing a module for this located in https://github.com/JPG-Consulting/JpgLocale. If you take a look at it you’ll see I’m planning on different adapters depending on how the site is setup, and use different handlers for different approaches. For example, if the page is static there is really no need for a database driven approach and using a simple configuration file will suffice. However, if the developer takes a database approach then the problem is different as he would probably want to be able to enable or disable languages on the fly. As for the handlers, sometimes people just want the locale/language to be set on the sub-domain, sometimes people want to use the cTLD, sometimes just a path style, etc. Even with all this in mind there are some special cases. For example, the JpgLocale module should end up being a requirement of my Blog module but it should affect the frontend to display the articles in the appropriate language, however the backend should have a way to fetch the articles in different languages without changing the user interface language. So there would be two ways of fetching the articles. So a generic solution may not be enough to fulfill all your needs.
