Symphony.

I am aware of the many threads concerning multi-language issues. It's quite a complex problem. Mods: if this post should be in a different thread I trust you'll make it so ;)

I am trying to think of the simplest solution for multilingual content for a particular project. The project concerns multiple local Symphony 'satellite' sites (all very similar) that retrieve parts of their content from a 'main, International' site (through the awesome REST API).

Because of the above I do not need much language 'logic' (think redirection etc.): I mainly need a way to attach multiple localized blocks of content to an Entry.

Obviously, I could use the Multilanguage Support and/or Multilingual Field extensions. However: these plugins seem either a little fragile (I ran into bugs with the latter) or complex for my needs.

Another solution would be to simply have a 'main' Section (e.g. 'Article') that contains global, un-localized, fields (such as 'Date', 'Status', 'Author') and relates to various entries in a 'Article Content' section. I then could create an 'Article Content' entry for each necessary translation.

The above would require some hassle in the form of linking the two Sections and some 'conventions' in querying the appropriate 'Article Content' entry based on the site's language. Maybe introducing a Reflection Field that could be used to query?

A bigger issue would be the problem of editing content across two Sections: to create an Article one would have to first create the 'unlocalized' ('meta') Article entry and next create an 'Article Content' entry. After that the both would have to be linked.

Unless there is some extension that allows for 'inline' editing of multiple sections (something like SSM) this seems too much hassle.

Interface-wise I would definitely prefer something like Multilingual Field (multiple language tabs) but it is throwing bugs and I found it a challenge to filter the appropriate field-language through the REST API.

Anyway, what would you advise?

• Use the available (field-modding) multi-language extensions
• Use and link multiple Sections (as the above)
• Do something else altogether

Thanks for thinking along.

I don't know how many languages you have to handle, but we are using the Publish Tabs extension for managing multilingual content, adding one tab per language.

We considered using two sections linked with Subsection Manager as well:

• one to store the title and meta data of an entry and
• anotherone to store the content in different languages (storing the language in a tag list).

But utilizing Subsection Manager for this seemed a bit too much.

[...] we are using the Publish Tabs extension for managing multilingual content, adding one tab per language.

Me too, as implemented by a Symphony developer that's helping me with a two-language site. It's not finished yet, but the admin's nice and quick to use.

Nils, the Publish Tabs approach would indeed be very simple with a limited nr. of languages: one would have to duplicate the content fields for each language (body_en, body_de etc).

Editing would be very easy but it would require sending all fields (all 'languages') when only 1 is required no?

My project has potentially quite a few languages (I'm guessing 4 - 5 minimal) which makes this solution not flexible enough I think. Adding a new language would require updating the Section (adding new body_LANG fields etc.). I'd rather have the flexibility of adding a new entry for a new lang.

The other option (e.g. using SSM to link multiple Sections) is similar to my idea. What do you mean with 'a bit too much'? Also: editing (big) content fields through the SSM sounds less than ideal.

@david

I'm successfully using Language Redirect, Multilingual Text field , Page LHandles and some custom XML stuff in my multilang projects. Right now I had to make a site in 5 languages and it's a breeze.

Interface-wise I would definitely prefer something like Multilingual Field (multiple language tabs) but it is throwing bugs and I found it a challenge to filter the appropriate field-language through the REST API.

What are the bugs you are experiencing? And with a quick test I was able to get the correct language with the Multilingual Field with setting the language parameter in the URL like

http://sym22/symphony/api/entries/dictionary/?format=xml&language=de

Editing would be very easy but it would require sending all fields (all 'languages') when only 1 is required no?

Yes, but you could customize your data source to handle this by creating the included field on the fly (e. g.: 'body_' . $this->_env['env']['url']['language']).

The other option (e.g. using SSM to link multiple Sections) is similar to my idea. What do you mean with 'a bit too much'?

Well, we have sites with two languages :)

Also: editing (big) content fields through the SSM sounds less than ideal.

That depends on your taste. If you store all the meta data in the main section it should be just fine and give the authors a nice interface.

Woah: responsive community at work :) (thanks guys!)

@vladG cool. It might just be my lack of experience, but it seemed both fragile and complex. I'm probably wrong and should go with these extensions (even if I don't need stuff like Language Redirect etc.). Maybe I just need a bit of a starter tutorial for a site you describe. Do you know of any write-ups on using these extensions?

@klaftertief I have not experienced bugs querying the correct language with the REST API. Appending &language=en works fine. So this was not an issue (after I figured out the correct language parameter).

@Nils Does the REST Api extension use common Symphony DS'es in the background? (excuse me if this is a dumb question). If so I could customize the DS although I have 0 experience with this. Thanks

Regarding the SSM: Do wysiwym editors run in the SSM interface? If I have all the meta data in 1 Section I need to edit the linked entries in that section too: through a SSM. My fear was that editing a bunch of textfields and textareas (with preferably some wysiwyg editor) in the SSM was unwieldy… Also my client might want to add e.g. images in the translated blocks. This would mean I need to edit an entry in a SSM, potentially needing another SSM (to add e.g. images). Nested SSM's will probably result in a bad inception experience ;)

@Vlad: sounds good. Once I have more experience and can do Symphony sites myself, I'd definitely look into using extensions like that if more languages are required than just two.

@David:

Editing would be very easy but it would require sending all fields (all 'languages') when only 1 is required no?

The site we have Publish Tabs in has two seperate data sources for the content per page (one for each language). I'm guessing Nils' code would be added to a custom data source?

Nested SSM's will probably result in a bad inception experience ;)

I set up nested SSMs once, and it was actually okay for the purpose it served (which was a test for a new site which might not be going ahead). Pretty cool it can be used in that way if desired.

Does the REST Api extension use common Symphony DS'es in the background? (excuse me if this is a dumb question). If so I could customize the DS although I have 0 experience with this. Thanks

Actually, I don't know. If you need to serve multiple domains, I propose using Michael's ninja domain approach.

Regarding the SSM: Do wysiwym editors run in the SSM interface?

It depends on the editors. I don't maintain any of these text-formatters so I don't know.

If I have all the meta data in 1 Section I need to edit the linked entries in that section too: through a SSM. My fear was that editing a bunch of textfields and textareas (with preferably some wysiwyg editor) in the SSM was unwieldy…

That's what SSM was made for so it shouldn't be a problem

Also my client might want to add e.g. images in the translated blocks. This would mean I need to edit an entry in a SSM, potentially needing another SSM (to add e.g. images). Nested SSM's will probably result in a bad inception experience ;)

Here it might get complicated. I'm working on optimising nested Subsection Managers, but I wouldn't recommend it as the interface get's complicated. It works, but personally, I don't like it. SSM was made for parent/children and not parent/grand-children connections.

@DavidOliver Yeah: one could create a special (custom) DS for each language. This requires us to create a new DS for each language which makes it not as flexible as we wish. Still: we could even create the custom DS'es in advance since their quite simple (if it's only adding the correct language suffix) and we can expect certain languages to pop up.

Cool experiment: still, I think I'm going to stay away from Inception Manager™ :)

@Nils in my setup I still need separate Admin areas and the sites, although similar, should also be different in some aspects. I don't think the Ninja Domains technique would, therefore, be the best option.

I might take another look at SSM for this though. For simple content-sections (with few fields an no strange nested SSMers) it might be workable.

I'm still very interested to see a tutorial on Multilanguage Symphony setup (using the extensions) though.

Does the REST Api extension use common Symphony DS'es in the background? (excuse me if this is a dumb question).

Yes, it uses a Symphony data source to read entries, but I wouldn't recommend changing it. If you wanted to change the fields returned:

http://site/symphony/api/entries/my-section/?fields=title_en,body_en

So if you wanted to append the _en to the fields you would do it in your Dynamic XML data source on the local site, rather than in the REST API data source on the master site. It's a case of changing the string that it used as the URL for the Dynamic XML data source.

Good point. However, in my|the case of quite a lot of languages the solution of duplicating each text field (body_en > body_de) seems impractical and querying the DS as such is not necessary.

I think I'll either go with the 'default' option (using the available multi-language extensions) or try and see if I can decouple the Meta content from the Text content in multiple Sections. These could be added/edited 'inline' through SSM. If the fields are limited and not very special (as in strange wysiwyg or extra SSM's) the only challenge remaining would be to have some way to query the correct linked Entry.

Local site A (EN) should be able to query the (meta) content and subsequently query one(!) of the linked text content entries (only the English one).

When I query an entry with a SSM, all linked entries (of the text section) are automatically included, correct? In my case I need this to be limited to only the entry with the required Language (or in the case this is not available a fallback [EN]).

How would I achieve this: the SSM would only return one of the linked entries.

How would I achieve this: the SSM would only return one of the linked entries.

Just don't output the SSM field in your data source but use it to generate a output parameter which will contain all your attached subsection item ids. These ids could be used in another data source which directly returns entries from the subsection, filtered by the output parameter and the currently needed languages.

@Nils

Right, think I understand. The REST Api, however, does probably not handle this out of the box which would require me to use a 'standard' Dynamic DS across my sites, right? This is not a big problem but I think I'd rather use the Api.

Anyway, thanks for your suggestions people. I am loving this forum.

In my opinion, the perfect interface for this kind on content where actually all field of a section need to be translatable would look like this:

It would be an advanced subsection concept, where you could define a parent section that works as as a container for entries of another section. The parent section is just a container and only references the subsection but you use this section to create entries. Each subentry is represented as a tab that should be sortable. The value of the first field in the first subentry/tab could be used as handle/identifier for the parent entry. For the data source output you could use the tab name as filter.

PS: Actually, it would be possible to integrate this concept into Subsection Manager. But it's a heavy task ...

Attachments:

sym_multientries.png

@davidhund

Maybe I just need a bit of a starter tutorial for a site you describe. Do you know of any write-ups on using these extensions?

Well, actually no. I installed them and started playing with them until I understood what they actually do.

Language Redirect takes care of the redirection for the desired languages.

Multilingual Text (needs Language Redirect) it's just a text field with content in all the languages. It outputs the content in XML very nice.

Page LHandles (needs Language Redirect) provides support for localising titles and handles of pages in each language. I also wrote some stuff in it to support multilingual "navigation" type Datasources.

The static strings that appear in a page, including custom messages for contact forms etc (e.g. "You are here" = "Vous etes ici" = "Sunteti aici" etc) are stored in XML and loaded via a custom dynamic DS. Each page has it's own XML file in all languages: page_contact_en.xml, page_contact_fr.xml, page_contact_ro.xml etc.

Nils, something like you describe would be awesome. that's exactly what I was thinking about.

VladG true: I'll play around a bit, thanks.

Nils, I had a similar idea when I created Publish Tabs. I was going to create the ability for a tab to link to an entry in another section. The idea was that sometimes a master entry (an article) might sometimes have additional components attached to it (a gallery, a quiz) which all have their own field requirements. Rather than throw all of these fields into the master section, I wanted the tabs to link to the respective sections and retain an understanding of whether the entry had been created or not. A bit like a Select Box Link (one to one), but rendered as a tab.

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

Still, both solutions would fill a gap ('inline editing of linked entries in other sections'). Would something like Nils's or Nick's solutions be difficult to create?