It depends on the organization. Some organizations will be happy with minimal translations that grow naturally over time, others will need everything perfect before something gets published. If the latter is the case, then you have to freeze your content development (at least in the base language) before it gets translated. Each time you update the english, you're forced to translate everything over again and I don't think there's much that can be done.

If this is a serious concern, I would approach a company, like SDL, that does enterprise translation to see what their workflow is. I would then try seeing if it would work with the size of my organization.

If you were doing full on translation of a site in more than 2 languages, you'd probably use on of the other file formats that Zend_Translate reads that are XML based and designed to handle multilingual content (.tmx, .xliff). These formats are also supported by translation software, so your translators and your developers can easily import something written by the translation department.

Yeah, it could work this way, but if it's the development team, the marketers, the SEO optimizers and the HTML integrators who are bringing the texts in there, there's no way you can send it to the translation department without gathering everything before. That's the opposite problem in fact. I wonder if the problem comes from our way of working with texts or if it's more of a framework issue.

We thought about the site audit solution, but basically it creates a few problems too. First,  manual audits are just not conceivable, we're a small company and checking the whole codebase looking for terms each time we release a project would waste way too much time.

Then there's automatic audits, but there will always be some cases where you can't find all the keys. There might be keys only needed in very particular occasions, when a very particular client logs on and do a very particular action. Even if we logged everything during the development, there's still a risk that the developer will never try a piece of  code (whatever the reason) and then the translation system will never log or warn the missing key.

The solution could be to declare each needed term even if they're not used in this particular context, for example, declaring the need of a particular key before an if statement where its used. We could then log the missing key but it would require to include translation terms that are not currently needed. On the other hand, that might generate more stable cache files. I'm not really sure where I'm headed.

I think you're bringing up an excellent question. As someone who's worked on a website in ASP.NET that had 4 different languages, I can tell you it was a grueling process, however what made it grueling wasn't the coding, but the back and forth with the translators.

First of all, there's different degrees of multilingualism when building a site / web application. This comes up a lot in Quebec, where officially, people have bilingual websites, but the reality is that only things like navigation, breadcrumbs and headings are bilingual. Zend_Translate would be fine in this instance.

If you were doing full on translation of a site in more than 2 languages, you'd probably use on of the other file formats that Zend_Translate reads that are XML based and designed to handle multilingual content (.tmx, .xliff). These formats are also supported by translation software, so your translators and your developers can easily import something written by the translation department.

Another big plus with Zend_Translate is that it degrades nicely. You could easily do a site audit and find every key you want in another language, dump it into a spreadsheet and get a translator to start working on it. It's not ideal, but certainly doable.

What I'm saying is, if you have more than one developer working on the project, and you have marketers, SEO optimizers, HTML integrators and such... all these people are gonna add translation terms everywhere. How are you supposed to gather all of these therms once the website is finished and you want to send the whole terms list to the translation team? It's a bit utopian to think everyone will add a key in the language file each time he adds a single word on a page (mostly because it's not their job).

The probleme here is that there's dozens of ways to include Zend_Translate in your website. Some components are using it silently (Zend_Form) some others require to call a translate() on a translate object, some are just using the view helper, etc. There's no way we can retrieve all these terms automatically... so what's the point of the whole system? If you have a website using more than a thousand terms, it's a total nonsense. Or am I missing something?

You can use more, how use translate texts in Zend_Form, Zend_Controller. How use gettext. Will be useful for more ZF developers.

Maybe it's good topic to some advanced Zend_Translate.

One of the big things that the Zend Framework has over other frameworks is the built-in locale and language tools provided by Zend_Translate and Zend_Locale. All this comes with plugins into Zend's templating system via Zend View Helpers. This video covers setting up some language-friendly routes, writing a custom language switcher Zend Controller Plugin and then running some a CSV-formatted language file.

Grab a copy of the project or browse the repository.