Categories
symfony

Multilingual Backend

Hi,

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:
[php]
PEAR/symfony/generator/sfPropelAdminGenerator.class.php
[/php]

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

[php]
class sfPropelAdminGenerator extends sfPropelCrudGenerator
[/php]

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:

[php]
list:
title: List of Available News
display: [id, =title, content, created_at]
edit:
display: [id, =title, content, created_at]
[/php]

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:

[php]
edit:
display: [id, =title, content, created_at]
fields:
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 }
[/php]

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!

8 replies on “Multilingual Backend”

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

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.

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]… ) ?

hey,

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?

Hi,

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.

Leave a Reply

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