Symphony.

@designermonkey: I agree to your arguments. Maintainability is a really touchy subject. What's your thoughs about providing a full-proof extention, that support ml fields and native fields ?

I think it's something that's been in discussion for a long time now "How to provide accurate and simple multi-lingual abilities in Symphony" and while I personally have no experience in multilingual approaches, the community as a whole has been trying out every approach possible with many different extensions and methods to do it.

My thoughts are to wait until the new site is live, which will mean Craig and Allen will have a slightly free-er schedule, and then we should chair a real look into all the different approaches and solutions to consolidate them into a really solid approach.

This is kind of what happened with the approach to Members, there were many ideas which finally got built into the great new official extension. And it's my personal belief that for the future of Symphony, this is what should happen for multi-languages.

All this being said, I reckon it will be left off table for Symphony 2.x and thought about from the ground up in Symphony 3. The core is being completely rewritten, and will give us scope to apply this kind of ability. Everything is an extension in Sym 3, so the work of all the developers who helped build the multilingual approaches so far will be looked at.

The current ways of doing things seem to suffice for many developers, just picking the parts they want for how they want it done.

My advice for developers who really want proper multi-lingual support in Symphony 2? Get together and build it. Look at all the approaches and merge them. I can't advise on how to do it, as like I said, I've not done it yet.

My concerns are to get the extensions list down to really good solid extensions for Sym 2.2 and upwards, whether they be really lean and simple or large with different options.

@designermonkey: Thanks for such a detailed answer! I will install symphony 3 a soon as I can. I would also offer my help as for the engineering brainstorming about the multi-language support. I live in a community where my clients want bilingual site 95% of the time so this is one of the first requierements I had for a CMS.

For now, I must say everything works really well with simple patches to good extensions that lack support for multi languages. It much simplier to fork and patch than to re invent the wheel...

So I'll follow you and wait for Sym 3. Thanks again.

I have a follower! (grins with evil intent)

Symphony 3 is quite a way off, which is why we need to do the work getting the already great extensions that are available now into a smaller, more flexible/powerful set for the foreseeable future.

Anyone with good experience in multilingual sites, whether it be from Symphony builds or other CMSes will be welcomed to help. God knows I have none!

EDIT: I don't mean to say we're going to retire extensions for the sake of it. Just have a serious look at what can and can't be merged, use cases that sort of thing. We still want to encourage development, just focus it to avoid repetition. The work is already under way too!

Hahaha good !

@Nitriques did the hack/fix proposed by VladG work out in the end? I've just come accross this stumbling block with a site I'm building this weekend and it's a shame I can't use SBL out of the box with multlingual.. boo :(

@designermonkey: That's what I have been doing but I think it is counter intuitive to have forks or duplicates only for multilingual purpose. This feature should be in the core, so we could build upon that.

My 2 cents in "back to the original problem":

Multilingual field generates also the default handle (without lang suffix), which filters well with SBL. Only issue was, that this handle become empty when non-default language is active. I worked around this by duplicating and renaming "lang.code.php" files in "/symphony/lib/lang" to represent all language codes used in a website. Those files holds the symbol translation tables for handle building purposes.

It's too late already, I guess, but maybe someone finds this useful.

k.

So are there any alterations to the lang.code.php files or just straight up translations for all the ones you need?

@Komb: No, that does not work as I want to filter per language, i.e filter=news and filter=nouvelles should return the same set of results

@Komb, @moonoo2: Please check my fork of the extension to have an updated version without those bugs. The OP replied that he will merge the pull request.

So my question is, can I specify DE as the language for this data source filter?

@into: The field filters by the value of the current language, if {$product} comes from url param you can use the localized handle to construct the url and filter with the value of the correct language.

Right, except I want the same URLs, but with different language codes

Right, except I want the same URLs, but with different language codes

What's the use case?

@into: Maybe you can use a text field or reflection field to set a "URL alias" and use it to construct your urls and filter the DS by this field. This way the url will be the same for all languages except the language code.

Back to the original problem, yesterday I stumbled upon the very same “limitation” when combining Select Box Link Field and Field: Multilingual Text Box. I’m aware the latter is not Multilingual Field but—since the limitation which arises is the very same one—I thought it would have been good to share it in the forum anyway, so here I am.

Similarly to Nitriques I had two sections, Products and Categories:

• Categories had just one field, that was a Field: Multilingual Text Box named “Name”;
• Products had several fields among which there was a Select Box Link Field named “Category” related to the field “Name” of the section Categories.

In a page I needed to filter all the products in respect to the category selected by the viewer, so I created a new URL parameter name “catg” and I used it to filter the entries fetched from the section “Products” via a data source of the same name. As it happened to Nitriques everything was working fine when “catg” was a word in the primary language (for example “shoes”, EN), on the other hand when “catg” was not a word in the primary language (for example “calzature”, IT) the data source was not returning any output due to the “issue” above mentioned.

As a first solution I though to pass not the word stored in “Name” but the id of the entry as a page parameter to filter the products: such a solution was working properly but I was not so happy to have a number in place of a word in the URL.

As a second solution—that was the one I adopted in the end—I decided to use “catg” (as a word) to filter a single entry fetched from the section “Categories” by means of a middle data source named “Category”. Then I specified as an output parameter of such a middle data source the id of the single entry and I used it to filter the data source “Products”, resorting to data source chaining.

In this way I was able to keep “catg” as a localized word in the URL and filter the products properly in all different languages. A bit of a wordy procedure, but it worked.