If you have even worked on an international site using Symfony, you’ll be familiar with the ease you can switch between languages on a model level. I’m loving this, because you don’t have to worry about it in the controller or the view, meaning you can easily add i18n dimensions to pretty much any application in one central place ( the propel builder classes ).

That being said, I found the default behavior insufficient for sites that don’t have the resources to translate absolutely everything. In many cases, our clients focus their translation efforts on the most important product lines, press releases, or event postings, and are happy to default back to English for everything else.
In some cases this means translating only selected fields, and this is where it gets tricky, because Symfony will only retrieve i18n content for the current culture, so leaving fields blank in a translation won’t prompt it to retrieve the default language instead (so far), so what we need here is a way to make every i18n accessor method smart enough to grab default content if the translation returns nothing.

Enter the propel model builder classes. Thanks to the pattern-al™ foresight of the Symfony creators we have a central access point to all auto generated accessor methods via the sfObjectBuilder class in your Symfony/lib/addon/propel/builder directory, which we can extend and overwrite to meet our requirements.

As a result every i18n accessor method now tests whether there is a string to return, and, if not, the object switches its culture to default and queries again, switching back afterwards.

Now, I have to qualify that what I did here might not be the prettiest solution, and I’m not quite comfortable with the amount of parent code that I had to copy into the child class to make the overridden functions work, but it works, and if anybody feels like cleaning it up, be my guest and send me a copy.

A word about performance

The overall approach I took is clearly geared towards development speed, not neccessarily runtime efficiency, so if you output a long list of i18n objects, odds are that you’ll fire off a query for each individual one. Functionality-wise that works, and speed is actually surprisingly fast, but that’s considering a rather small database and your particular server might puke. Haven’t tested on large system, but I would believe caching would alleviate this.
Also, I would imagine that propel 1.3 could alleviate this via object cache, where we could run one query to retrieve all applicable i18n objects before we output the list, and all future references to i18n content would come from cache. Haven’t tried this yet.

How to use this:

Download and unzip this SFi18nFallbackObjectBuilder class into the Symfony/lib/addon/propel/builder directory and edit the config/propel.ini file to use this file for propel.builder.object.class (instead of sfObjectBuilder).

Then all you should have to do is rebuild the model and activate it in the configuration by adding

use_fallback: true

to your i18n.yml configuration (for all or just some environments). I added this configuration switch, so that you can turn this off for admin areas, where you would otherwise not have empty fields for translations.

That’s it, have fun, and let me know how I could improved this somehow.