Symphony.

A new extension, “Page LHandles” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

This extension offers the possibility to translate the Pages’ URL Handle in the languages provided by Language Redirect.

It supports languages formed from Country e.g. “en” or Country-Region e.g. “en-us”. Sadly, the Multilingual Field doesn’t support this so I recommend to use only “en” instead of “en-us”, if you are using that field.

See the Readme for more details.

Many thanks to @other developers who made a great job with their extensions and provided much needed examples and how-to.

Nice! Thank you Vlad :)

Somebody should really consider writing a detailed tutorial about frontend localisation for Symphony-orchestrated websites.

Thanks for another “helper” to get the frontend localized.

+1 for a tut.

Great multilingual field enhancement will test it as soon as possible. Thanxxx

No, Guillem … Thank you! :)

This is a bit off-topic. We now have three extensions:

• Language Redirect
• Multilingual Field
• Page LHandles

Do we really need all these things a separate features or is it possible to merge all three into one multilingual / babel fish extension?

Well, there is the Multilanguage Support from kanduvisla which tries to accomplish this…

I don’t really know which approach is better. Honestly, I only had to deal with localised text boxes so I choosed Language Redirect and Multilingual Field. After that I created Page LHandles to solve the page handle. These extensions are each with their life.

Geil’s approach is interesting though, because he’s trying to accomplish the localisation as a unified task. Maybe he has the answer to a “Whole” thing instead of pieces. Too bad his work is still beta and don’t know about 2.2 support.

Somebody should really consider writing a detailed tutorial about frontend localisation for Symphony-orchestrated websites.

It’s on the (very long) list of planned articles. But I agree with Nils that it’d be good to eliminate duplication and sort out best practices first.

Using Symphony I learned that it’s better to have small extensions that does specific things that one that does all. I think it’s same philosofy that makes other extensions like Publish Filtering, Static Section or Entry Order are not part of the core of Symphony.

A tutorial, an ensamble and a category for multilingual extensions could help to find the best solution for each situation.

Using Symphony I learned that it’s better to have small extensions that does specific things that one that does all.

Well, there’s a limit to everything. When extensions concur to achieve the same task it makes sense to me to merge them.

It’s on the (very long) list of planned articles

Oh, good to know!

Oh, good to know!

Who wants to write it? ;)

Who wants to write it? ;)

Usually the one who asks the question :)

The most ideal situation offcourse is, if Symphony would be multilingual from the core. To acheive this, the whole storing of data should be seperated from how it’s done now.

Indeed, I try to achieve this with my Multilanguage Support extension by adding a multilangual-checkbox to each field type, and create a ‘shadow-table’ which stores the values.

In my opinion, the only way to create ‘true multilanguage support’ is by implementing it in the core of the system. In the real world this could mean that each sym_entries_data_XXX-table should have an extra column called id_language. But also all fields types (and a lot of extensions) should probably be modified as well…

Page LHandles updated to version 1.1 on 8th of March 2011

• entire extension rewrite.
• added the missing support for page parents.
• offers support for localised pages to Datasources with Source set to 'navigation'

@kanduvisla What your saying here sounds logical. For someone looking to extend his use of Symphony i.e me, who use multilingual approaches everyday and am yet to fully embrace Symphony cos of the constant need by clients to have integrated localised front end sites. usually 2 or more languages at a time. There are some great approaches to multilingual emerging and I'd love to see not so much a core integration but as you've developed - a bolt on Multilingual solution for those that need it, thus keeping this beautiful project nice and light. I've seen your approach of additional tables in the DB before and it actually works very well. It's just whether the core devs think it's too clumsy to integrate and mess with the core install purely for language fields.. I do like your approach though. :)

Vlad, thank you for this extension, it's very useful! Before, I had to keep a "dictionary" section with my page names, but now with this language management is so simple!

I get a MySQL error when my page doesn't have a language code:

MySQL Error (1054): Unknown column 'page_lhandles_h_' in 'where clause' in query "SELECT SQL_CACHE `id`, `handle`, `page_lhandles_h_nl`, `page_lhandles_t_nl`, `page_lhandles_h_en`, `page_lhandles_t_en` FROM `bic_pages` WHERE `page_lhandles_h_` = 'organisation'"

Any thoughts on why this is happening? I have a language redirect event on the page.

@ellie
You're welcome.

@kanduvisla
I'm updating the extension. Will check your error too.

Wow! This extensions is extremely useful!
Thank you