Some Hate Over Cake’s i18n

I’m really fond of CakePHP’s principles, but I’m too tired of its i18n features. For some reason internationalization, although one of the really major requirements for every framework or CMS, is implemented poorly in most of the systems I’ve worked with. Django had few disadvantages (but few strong points as well) with its django-multilingual, and here it comes Cake with its toolkit for multilingual applications.

Comparing with few Java frameworks + CodeIgniter, I’m pretty aware of using locale-based apps with few languages for dynamic content. It’s ugly as hell most of the times.

The beauty of Cake is mostly its ‘convention over configuration’ and dynamic admin panel generation. Admin panel is pretty neat, although there is no CMS-alike functionality and one should translate/adapt the admin for a project every single time. This is a problem that savant is taking care of, creating a multi-functional and reusable administrative panel. However, nobody has ever thought about creating something advanced like in Django’s admin – data filters, field hiding, form populating module etc. Everything is hardcoded (actually spitted from the code generator, which is fine, automagic should be based on something and code must be there at some point) but not flexible at all except if you don’t rewrite your admin generator.

The other thing is the multilingual content.

Designing i18n stuff in CakePHP is done by Translate behavior. You define your languages in the core file (or bootstrap in older versions) and you use it for localization. Also, your models actAs Translate behavior and you need to define the fields to be translated.

What is missing here is that because of the database normalization, these fields in question are not in the model table, but in the translation one. For that matter you cannot create a multilingual views for add/edit/view/index, because you miss some of the important fields (usually such as name/content that need to be translated in other languages as well). Also, relations in the previous abstraction level with translate tables are done transparently and using find() with translated fields is pretty hardcore.

Croogo is a pretty neat CMS based on Cake. Translation there is modified by Fahad and he had done few changes in the main mechanism. Also, in order to add some translation, you do the following:

  • enter the base material and submit
  • view the material
  • click on a ‘translate’ button
  • select a language to translate in
  • fill data for the language in question

This one ain’t bad, but it requires 5 steps for adding one translation. What if we have 5 languages?

Django’s multilingual module is better in my opinion. It iterates over the languages and it outputs all translatable fields for every language in one page. When you add content, you could insert the whole data in one window or skip the unnecessary details at first. That’s a better one. However, Django has a different approach (the one that jose is taking into consideration – actually creating database over the models and not MVC over a database). This way connection between fields for translation could be predefined in a smarter way.

Why should all of that be so hard? Cake needs to be rapid and DRY and KISS, but admin needs to be changed every time, translation is tough to configure, administration is not straight-forward with its acl (and tens of auth modules). Croogo does a good job with putting all of that in one package, but it’s too heavy sometimes (Cake is not the fastest framework after all). I really need there is a place left for a good i18n module, some killing-auth lib and a better convention definition for even more rapid dev.

Leave a Reply

Your email address will not be published. Required fields are marked *