Symfony - Returning content in default language, no matter what.

March 10, 2008 – 10:28 am

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.

Filed under: Symfony — Tags: , , — by Richtermeister

Symfony with php 5.0.1 bug - no “interface_exists()” function

March 2, 2008 – 2:00 pm

I came accross a bug in Symfony today when I installed a copy on our php 5.0.1 development server.

Turns out, php 5.0.1. doesn’t yet have the function “interface_exists()”, which was added in 5.0.2. Minor issue, but it IS being called as part of the Symfony bootstrapping procedure, so it crashes.

Luckily, in 5.0.1 the “class_exists()” method returns the same result, so putting the following lines into the app config.php file (or even into the symfony constants.php) should fix it:

if( !function_exists( 'interface_exists' ) ) {
function interface_exists( $name ) {
return class_exists( $name );
}
}

I say “should,” because in actuality this didn’t fix my problem (but it SHOULD, shouldn’t it? ;) ). So I tried simply returning false, and, well.. it works..

Let me know if you know why that is. For now I’m happy it works, and come next php version, I won’t have to worry about it..

Hope that helps someone out there who has the same problem.

Filed under: Symfony — by Richtermeister

Another Symphony on PHP 5.0.1 bug

– 1:17 pm

Found another interesting bug today when I deployed a symphony app on the “older” php version 5.0.1.

The bug itself has solely to do with php, and it’s already documented here and fixed in the current version, but basically what happened, is that I assigned a couple of methods to objects via the sfMixer class, and in one environment it worked, and in the other it didn’t (”call to undefined method xyz…” error ). Weird!

Turns out, the ReflectionClass::getMethod() method that Symfony uses as part of the sfMixer class, turns every string you pass into into lowercase.. BY REFERENCE!! So assigning a mixer method “getChildren” would actually be saved under “getchildren”, and wouldn’t be found in subsequent calls. What’s more, assigning the string to a “backup” variable to conserve it’s capitalization doesn’t help either, because then somehow both variables are affected. ( I didn’t know that string variable are passed by reference as well???)

Thanks to my smart boss we found a workaround, which is appending something to the copy of the string, and removing it later when you reassign it to the original variable.. I suggest the appendix “save_this_f%$#@#$_variable”. Worked for me! ;)

Filed under: Symfony — by Richtermeister

Powered by WordPress