Oct 07

Multilingual Backend


just a small but might be VERY helpfull tip for you.
I bet you are using backend admin generator with Symfony. That’s amazing tool which saves so much of your time. But have you ever develop multi-language application with so called I18N tables support? Yeah, Symfony (actually Propel) has built-in support of I18N tables and that’s big help but this would be suprise for you – backend admin generator don’t know anything about that. So that if you want to provide the way for content manager to add news or pages via backend on different languages you need to read my advise.

I’ve read over the forum and all I found that was a couple of request to implement I18N support into backend and official responses that this will be done in the next Symfony releases. But that’s what I need right now and I decided to take a look inside Symfony Backend Generator:

So when you’ll take a look into that file you see that:

class sfPropelAdminGenerator extends sfPropelCrudGenerator

And in fact sfPropelAdminGenerator does not have much more functionality that Crud has.
So if you want to add I18N fields support to your backend admin first of all – you should add that fields to be displayed, e.g. if you have news table it should be something like this:

title: List of Available News
display: [id, =title, content, created_at]
display: [id, =title, content, created_at]

This way fields will appear in your list but when you press edit button – only disabled fields will appear for you with blocked content to edit. Why it happens – I found out that admin generator simply can’t determine those I18N fields type automatically and therefore they are simply not available for modification. But that is to fix, lets just add the following block instead of previous one “edit” block:

display: [id, =title, content, created_at]
title: { params: size=100×2, help: Short message which describe news, params: disabled=false, type: textarea_tag }
content: { params: size=100×15, help: Full message which describe news, params: disabled=false, type: textarea_tag }

I could not believe it works. That’s easy and did not require to change anything in framework itself.

I hope it was helpfull. And that’s a lot for your attention my friend 😉
Good night!

Author: symfonian


November 21, 2006

Are you kidding ?! This absolutely doesn’t help managing i18n fields for differents cultures !!!!

November 22, 2006

Hi Guss, thanks a lot for your comment. It works just fine for me. I used it in a couple of projects and I can guarantee that it helps managing i18n fields for differents cultures. Feel free to communicate with me if you’ll be interested in details.

January 6, 2007

Hi Narkov,
in which file do you make these changes ?

January 6, 2007

I found it, this needs to be added in generator.yml

Thanks for the tip – I havent got it wrking et, but I’m on my way 😉

May 2, 2007

Big, big thx for the tip. Have you developed some solution where all i18n data can be displayed in one form ( something like that: title[en]…, title[de]…, title[fr]… ) ?

Hassen Ben Tanfous
May 22, 2007
August 1, 2008


after trying it out, i always get an error telling me that the admin generator is *NOT* able to see the fields from the i18n table (which seems logic to me).

i have of course used a i18n schema with all i18n-specific fields set.

is there a further hint?

October 24, 2008


Great, amazingly it works. I’ve passed 2 weeks to search for a prompt solution to manage i18n fields. But it was just under my eyes :)Of course, class sfPropelAdminGenerator extends sfPropelCrudGenerator. and crud generator handles i18n fields ….
So, this is the simplest solution for i18n management …
But also, don’t forget to add a function with the __construct() that gets first the user’s culture.

Comments RSS TrackBack Identifier URI

Leave a comment