Symphony.

But your idea takes this further and is like an allow-multiple Select Box Link.

Yes, that's a good description. It would be a nice addition to SSM but I'm not sure I'll find the time for yet another project ...

It could just be another field bundled with Subsection Manager, e. g. field.subsectiontab.php. Hm ...

ARGH!

Could someone please stop me from working on concepts! I need to get my work done!

Stop. Now.

I'd actually like that for my website, please. :)

Sure, my sweet wife. Will start working on it now :)

I love your wife! No wait... That came out wrong ;)

*lol* I heard that ;)

Okay, this is still a work in progress, but for Johanna's and my own personal websites I've created a new subsection field called Subsection Tabs. It's main purpose is to manage multilingual content. This is how it works:

You have to setup to sections - one that holds all meta data and another one that contains the content. The Subsection Tab field links the second section to the first. Each translation will be stored in the the second section, one entry per translation.

If you like to have a look, checkout the tabs branch on Github: https://github.com/nilshoerrmann/subsectionmanager/tree/tabs

Be aware that this has only been roughly tested and is not considered stable yet.

Attachments:

sym_sst-publish.png and sym_sst-preferences.png

This looks great, I look forward to incorporating this into an upcoming project!

Looks wonderful Nils, looks like a great option to manage multilingual content!

I like the fact that this deals with a complete entry, not the fields (as the Multilingual Field), it just seems a bit more robust. Plus: when there's a translation I expect people to be able to translate the complete entry, not just a couple of fields.

However, the more options the better, as long as us n00bies can keep track of all the wonderful extensions ;)

Thanks, I'm keeping an eye on this one.

This is a really good take on multi language! I can also see a use for this when one could have a requirement of differently worded field sets for different user types, or ages for instance!

In the next days I think I could have some time to refine the MultilingualField, as vladG says with this extension and some others like Language Redirect and Page LHandles building a multilingual site it's easy and you don't need to change the way you use Symphony, you can create sections, datasources and display content like a single language site, no extra DS, sections or anything else.

The extension it's in progress, there are some little bugs but it's more stable every time someone use it and report the problems.

I have plans to make a multilingual tags extension... And after that if I have enough time I would try to publish the multilingual ensemble that I think it's the best way to see how easy is to do a multilingual site with symphony and the multilingual extension package ;-)

That sounds wonderful, Multilingual sites are often a bit of a hassle and I would for it to be simple in Symphony. it would be another big 'selling point'.

@Nils how does one query the appropriate subsection in your tabbed SSM? Can we filter the DS on the handle of the specific tab-name, or some other way? (I'm planning on using it with the REST API)

Subsection Tabs allow two filter methods: by tab name (which is the language name in my example) or by title (which is the first subsection field's value, tab independent - so you could search by whatever language you like). If you filter by tab name only those parent entries will be returned that contain a tab of this name. Empty static tabs will be ignored.

The field returns all selected tab fields in the data source automatically.
Parameter output for data source has not been implemented yet as I wasn't sure about the expected output.

I'm implementing multilanguage site (4 langs) at the time, using Multilingual Field, Lang Redirection & Static Section extesions. I must to say it was really easy, but my project is quite simple, though.

@ixi

You can have a look at Custom Preferences as well. It can be used as a way to edit the static content of a frontend page.

Just change this lines in extension.driver.php from

public function fetchNavigation() {
    return array(
        array(
            'location' => __('System'),
            'name' => __('Custom Preferences'),
            'link' => '/preferences/'
        )
    );
}

to for example

public function fetchNavigation() {
    return array(
        array(
            'location' => __('Pages'),
            'name' => __('Pages'),
            'link' => '/preferences/'
        )
    );
}

And create the usual Static Sections with navigation group set to Pages. This way the client has a way to edit the custom settings of a page.

vladG, thank you for the tip. published tabs is really useful thing for me, however for current project (my 1st in symphony) i'll stick with Sections / Static Sections as only thing that client need to edit. it works & it's fine for now.

what about localisation of back-end, for instance Section names or Field labels? by experimentation, i come to following practice:

• create sections and fields named in english to have nice names in xml output
• rename them to local language (russian) to provide readable names in back-end

is that correct, or not?

edit it is not correct.. actually it transliterates somehow russian labels to latin [???????? -> kartinka, and so on]. anything i can do about it?

perhaps i should ask more clearly : is there any way to provide translated Field's label in back-end?

Short answer: No.

Longer answer: You could write an extension that runs all labels through the translation function (either using JavaScript or PHP) and provide your translations via a Symphony language file.

@ixi

perhaps i should ask more clearly : is there any way to provide translated Field's label in back-end?

On one thread, can't find it right now, there were some recommendations regarding translating the extensions. It stated that for each field they provide in their extension, developers should make the field-name translatable.

So, theoretically, the name of the fields should be translatable in the extension_name/lang/lang.ru.php translation file, for example.

I'm using other developers' extensions. If I find an extension that doesn't provide translation for the field-name, I'm adding it and then send a pull request on github so the developer can integrate it.