Search

Do you think it is a good or usable idea for Symphony fields to have a "Multilingual" option, as they currently have e.g. the ".. is required" option?

The idea is not to having to change the field types from "text field" to "multilingual text field" and so on, or via versa, and also to avoid of losing of original values by such change.

Not sure if anyone thought about this before, but in my opinion, the multilanguage problem could be better solved in the datasource.

Developers could just create sections as usual (creating normal fields for every language and grouping languages with publish tabs, for example). Datasources on the other hand could filter by and output different fields depending on a specific modifier from the param pool, like a language parameter.

This approach would allow for building multilingual sites with mostly core functionality (if the datasources would be more flexible/powerful), but could be useful in other situations as well since it's not limited to this specific use case.

Jens, I can agree with this, including the URL Router to make a language parameter into a url-param.

I think the only drawback to this is having to duplicate all of the fields within a section. Currently that could be really time consuming. If someone could come up with an extension to do this the I would back the idea...

including the URL Router to make a language parameter into a url-param

Exactly.

I think the only drawback to this is having to duplicate all of the fields within a section.

Yeah, it's definitely more work for the developer to set things up, but it would reduce dependency on extensions dramatically, therefore makes the project easier to update and maintain in the long term.

Yes, thats a good and broader idea. Thanks for your insights. I am far of to think in true versatile options that Symphony is building on, but just to scratch out the rest of my idea:

Yes, when you would select the "multilingual" option, that field would gain language tabs just like it is now with ML extensions. I don't know if it could truly replicate all of the field types, select boxes etc, but in the idea you would get multiple checkboxes if the field would be of a checkbox type and so on. This way you could have some multilingual fields and some single in your section.

Languages would be added in a manner e.g. like JIT recipes in preferences. At least one language would have to be defined (maybe with install), because the pages are in a language anyway and you could use if for some html attributes right away.

The first language in the setup would be the default one if no language page param would be defined (in case of an index page, or a single language site etc.). You could reorder the languages in preferences with dragging and so changing the default language.

It would be nice to freely add, remove or change ("rename") existing languages on the fly, so all the associations would work and data in fields of the former language kept.

OK, enough of my stories :) Thanks.

Sorry, didn't want to hijack your thread.

Actually, our ideas could work well together. Multilingual option for all field types (including extensions) from the core (or from one extension for all field types) + conditional filtering in the datasource.

Having it done on the core-side would definitely be sweet; I think you're basically talking about 'merging' what the MultilanguageFields do to the core and make it optional.

Maybe something somewhat simpler would be to allow the FieldType to be 'upgraded' so you'd have a normal TextBox or TextArea; but you could swap this for a multilingual field. I'm sure there was talk elsewhere of being able to move from one field type to another as long as they would be of a similar type.

No no Jens, yours (and all the others) responses are very essential, thanks very much. They do move ideas forward. I did not wanted to write the whole though at once, because I thought it was too non conceptual (and I still think it is :).

Having it done on the core-side would definitely be sweet; I think you're basically talking about 'merging' what the MultilanguageFields do to the core and make it optional...

Yes, basically thats it. Maybe it wouldn't have to be strictly about "languages" at all. It could be just a set of items (variables) in preferences and they could multiply selected fields in tabbed manner. Maybe there could exists groups of them (and that group could be selected as an option for a field).

That swapping could be a more real solution too, besides Jens's one.

Yo, I am just playing with imagination, without solid knowledge of Symphony's gears. So feel free to use, change or discard any or all parts of these ideas :) I plan to write extensions too, but still catching on the howtos and how others do.

I'm currently implementing a multilingual project with basically just core functionality (without all the multilingual extensions), could write a post about it soon if someone is interested. I think it's a great way to identify the downsides of the current system and how these could be improved by better core functionality or fewer, simpler and more general extensions.

I don't think this will ever be a core feature, for the same reasons that Members was never added as a core feature, but a community team developed extension is possible.

Managing multilingual for every field would be a headache, as there are so many variations in what they do. That being said, I raised a question about fixing (not broken, but fixed as in static) granular level IDs for a field's data in the thinking of how it could benefit multilingual by being replicated, but it turned out to be quite complicated so I gave up.

Tables for entry data can definitely be duplicated for multilingual content, so I suppose an extension that specifies languages in the preferences page, provides duplicate interfaces for data entry in other languages, then hijacks entry saves to create language based entry tables for each language is a possibility. I wouldn't like to go near it myself though o_O the interface would be gruesome. I reckon a switch (select box) on a publish page to display and edit different languages would look and work so much better than tabs on fields, also, tabs in the publish page would interfere with publish tabs which I use on every project, so that's a no go.

I too am going to be doing some slightly multilingual work in the next two weeks, and will be using only core features (weird coincidence there Jens), so will report back also.

I'm actually a huge fan of the Multilingual Text Box - it's the best method of managing multilingual content that I've used - but of course preference comes into it too.

For the sake of installing a couple of extensions that do pretty much what's described above I think it's a pretty good workflow.

What I would personally be in favour of, is the ability to have tabbed fields (like Multilingual Text Box, but more general-use), or as @designermonkey describes, a select box (etc.) to group switchable content - but that's probably more an extension of Publish Tabs. I think that being able to group and divide input like that creates a lot of organisational possibilities - as well as enabling a more out-of-the-box opportunity for multi-lingual interfaces.

Another point: dividing languages into sections/tabs etc. at the language level, rather than the field level, means also needing some kind of 'general' area for non-language specific input. Like URL's, images etc. So you'd be increasing the setup time even more, and further fragmenting the content.

I've never played with subsection tabs to be honest and I build most of my websites in multilingual. We've got 3 running for whom I work, and currently working on another 4 or so, plus a couple of personal ones.

As @nathanhornby says having publish tabs might be restricting; as for example a publish-date might be similar for all, same for the Author you will only ever have one author for a blog. And since I don't want to input the content I'd rather make it easy and standardized for the authors/translators to manage.

I would also think its not a core feature not everyone really needs it; extensions are just fine, A method to swap fields would be nice cos you could upgrade to multilingual at any point in time.

@Jens, feel free and encouraged to share experiences with your ML project!

Sites I have created so far were all ML. I do still play with the concept. So far I've never used subsection or publish tabs to define the languages. Without ML extensions, I was associating a language with an entry with SBL or SM, that is if I wanted to have a single section for the web site's content, which I do want by default. But I also ended up to split the sections per language in favour of an easier administration and also in cases I needed to have different SM options for each language and I guess some other cases.

Basically, I can tell my sections were practically of mixed field types, that is some of the fields were ML and others were classic single value fields.

@Jens, feel free and encouraged to share experiences with your ML project!

Totally forgot about this discussion. In case you missed it, meanwhile I have created and released an extension for the approach I described above.

Hi Jens, thanks for getting back to this. I couldn't have missed your extension :) - will test it out for sure. Currently I am busy with some projects, will check back on it. So far I've seen from the descriptions its a nice and clean solution.

Nice extension @Jens. I use 3 extensions to make multilingual site plus another various multilingual fields extension. Not complaining, they do a great job in it purpose, but a simpler option is welcome.

I'm just curious about this:

<entry>
    <title-en handle="the-extremes-of-good-and-evil">The Extremes of Good and Evil</title-en>
    <title-de handle="the-extremes-of-good-and-evil">Das höchste Gut und Übel</title-de>
    <title handle="the-extremes-of-good-and-evil">The Extremes of Good and Evil</title>
</entry>

The DE handle should be das-hochste-gut-und-ubel?

And wondering if it is possible insert a lang attribute, ex: <title-de lang="de" handle="the-extremes-of-good-and-evil">Das höchste Gut und Übel</title-de>

The DE handle should be das-hochste-gut-und-ubel?

Oh, thanks for pointing this out. Just an error in the readme, the extension in fact does provide handles in the correct language.

And wondering if it is possible insert a lang attribute, ex: <title-de lang="de" handle="the-extremes-of-good-and-evil">Das höchste Gut und Übel</title-de>

Should be possible. What would be your use case for this?

I was thinking in some like //datasource/entry/title[@lang = $lang] xpath.

I was thinking in some like //datasource/entry/title[@lang = $lang] xpath.

My thinking behind the current implementation was, in most cases you just want the current language, so it's easier to use entry/title instead of entry/title[@language = $language].

Only usecase I can think of where you need all languages at the same time would be some sort of select language-function. Currently, you can achieve this by using something like entry/node()[local-name() = concat('title-', $language)]/@handle.

But I will think about your suggestion. Would be definitely more consistent and straight forward than the current approach.

Nice trick on this entry/node()[local-name() = concat('title-', $language)]/@handle, it's new to me.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details