Symphony.

@jstar198: The problem with DS filtering it’s because the bug in Select Box / Select Box Link. If do you have sections without this filds you can filter DS.

I will add the value field in entry table with the value of the entry in default language.

@guillem_l I understand that DS filtering takes place the database level, hence as you say you must settle for filtering based on the default language. BUT, when multilingual field data comes “out” of the DS it is already localised —- ie in my XML I only ever get *one* version of multilingual content. Therefore would it not be possible to add an intermediate level of filtering, in between the database and the output from the DS itself?

(Hope that makes sense, my understanding of Symphony is still a bit limited).

Multilingual Field updated to version 1.1 - beta on 21st of July 2010

@jstar198: just published a new version of the extension. Try if now works as you expect.

Thanks for your feedback ;-)!

Wow, that was fast :) Ok so from what I can tell, DS filtering works on the DEFAULT language only. My question is, would it be possible for the filter to be applied on the CURRENT language? So in the database, the filter column would not be value but value-en or value-fr, depending on the current language? The reasoning is that since the output from the datasource is already localised to the current language, it would be nice if the filter behaved in the same way, so to speak.

@jstar198: I’ll take your proupuse in consideration, by now you can filter the DS passing the attribute “handle” that has always the value in default language in the output. If you want to filter the DS for search proupuse you can use my modified version of search_index extension.

http://github.com/6ui11em/search_index

now it works as I excpected. I found another little bug when using Field with WYSIWYG text formaters (TinyMCE, CKEditor, ect). Initial height of textareas is 0, so the editors are not visible or have different height. The solution is to remove display:none; in div.field-multilingual .tab-panel css rule. Javascript automatically hides tabs, but when Editor is applied they have initial heights larger than 0.

@icek: bug fixed! Thank you icek!

Seems to me there’s a bug in the checkPostFieldData method. I think it’s really just lucky that it works with any of the Markdown formatters or no formatter, since what is passed on to applyFormatting on line 627 is the $data array containing all language values.

I can’t understand how this works for other people with CKEditor, because it does not for me. As far as I understand, applyFormatting should only be called for each actual language value, and not the whole array with all values.

The Markdown formatters happens to end up converting the value array to the string “Array” and format this. But the CKEditor formatter just returns the input as is, since the actual formatting happens client side. This ends in the $data array being passed on through to General::validateXML, which crashes on a strpos check on the array.

Sorry if I should have submitted this directly as an issue, but since I’m just getting used to Symphony I’m not sure if I’ve understood the problem I’m experiencing correctly.

@froded: icek post an issue in the git repository about this bug with CKEditor. I will check as soon as possible. Thanks for the feedback!

Is it a bug or a feature that activating a tab in one Multilingual Field activates the same language tab in the other Multilingual Fields?

@klaftertief: To me that’s a definite feature. In my experience users will often have responsibilities of updating content in one language. It’s nice for them to just toggle the language once on a given page and then go through all content.

@guilllem_l: Sorry, didn’t check icek’s issue until now. But what he describes as fixing the problem was what I did as well. Seems the bug is a simple fix, hopefully you’ll come to the same conclusion :)

@klaftertief: It’s a feature, as froded described.

@froded: just come back from vacations, I will fix the bug in the repository version. Thanks!

Thanks for the confirmation. The behaviour makes sense, and looking at the code it didn’t seem to be a bug. :)

I have added a issue - [http://getsymphony.com/download/extensions/issues/view/46066/4/][1]

Added the field to a new simple section (2 fields), supported languages are shown but it blows up when saving.

Please help.

I just push the bug fixed by icek that will fix the error with CKEditor.

@muthahubbard: I think this modification will fix your problem too.

@guillem_l Thanks resolved my issue works great now. Can I ask about the handle attribute this always has English as a value? The node value is dynamically filtered though?

Thanks

@muthahubbar: handle attribute always has the value in the default language, this way you can use it to filter the DS. Look at comment #26 of this discussion.

@guillem_l I really appreciate this plugin, but the fact that filtering always takes place in the default language is problematic for me. I’m building a multi-lingual site where the URLs are also localised, e.g.:

/en/my-content/
/fr/mon-contenu/

So if I capture “mon-contenu” as a URL parameter, it would be super if I could just pass that directly as a datasource filter and end up with the page that I want.

However since the filtering only takes plase in the default language (English), trying to filter on “mon-contenu” would return nothing; thus I am forced to load all the pages in French from my datasource, and then filter the right one using XSLT - which is far from ideal.

Would it be possible to perhaps implement this as a plugin-wide option? (i.e. you can choose between localised or default language filtering)? Or do you at least know a better solution for achieving what I’m trying to do?

Thanks, John

@jstar198: To implement this feature I need to modify some parts of this extension, I have to find some time to implement this modification. I will try to do it as soon as possible.

Maybe other symphonians like icek and froded that has played with this extension has a good solution or suggestion to implement what jstar198 says?

For a localized url sites I use pages to build a localized site tree and use $root-page to filter depending of the language, but I never use this solution with Multilingual Field, I think this is not compatible with Language Redirect.