Symphony.

Add a field for the lang_id in the entriy-data-table was my first approach when I create the multilingual text field, I discard this option because all the core aspects was affected, then I search an easier solution (I have not so many time to implement it) and then I put the lang code at the end of value / handle columns. This was not my preferred option, I think the first approach was more polite.

I like the idea to use extensions to build multilingual sites because keep the core simpler, but some core hooks / functions to make easier to develop multilingual fields extensions or to implement extensions compatibles with multilingual fields could be great.

I think not all fields must be multilingual, I think only text based fields (textarea, textinput, textbox, tags ...) are affected, other fields like checkbox, uploads, select, etc... Usually has same values for all languages (upload fields could be an exception if for example files are videos or images with text, this could be arranged with subsection manager with language field, but a multilingual upload field could be a great solution too to keep forms simpler).

Now the first multilingual extensions (language redirect, multilingual field, etc...) are more stable thanks to the contribution of the people how use it, the new class of Language Redirect that give some functions to deal with languages could be used for other extensions to make it compatibles with multilingual fields, maybe include some of this functions to the core, document it, create a section "Multilingual" in the extensions download page and create a Multilingual ensemble could help developers to set up their multilingual CMS and multilingual extensions.

@brendo: What do you think of the suggestion to abstract the database-table-generating functions for field-extensions?

I don't think it's a solution at the moment, purely because it relies on fields 'opting in' to support multilingual. The ideal solution works at a low level so that fields don't have to do anything to support multilingual (or versioning for that matter).

I would be interested in seeing how a setup that uses Language Redirect and Subsection Tabs extensions would work for multilingual content. I imagine the main issue would be linking fields in the backend (eg. viewing the German tab should only show the German entries in other sections through the SBL/RL/SSM, unless the linked section doesn't have a German equivalent in which case it would show all entries)

Another approach could be the make use af an extra table for meta-information. This way, extensions won't have to alter the database structure and extensions won't have to be adjusted. Such a meta-table could have a structure like:

- id
- relation_id
- meta_key
- meta_value

Such a meta-table could extend the possibilities of extensions beyond just the use of multilanguage. For example: in a multilanguage extension it could have something like:

id: (auto generated)
relation_id: (the id of the related field (or entry))
meta_key: 'language'
meta_value: 'en'

But it could serve other purposes as well, such as version control, documentation on field-level, permissions, additional user information, etc...

Now such a table could be easily generated by another extension, but I do not like the idea of one extension being dependend on another. I also believe this doesn't stroke with Symphony's philosophy: that each extension should function on it's own.

That's almost an identical approach to what currently happens now with the fields table (think entries table) and the field_{extension} tables. The core fields table has the default core settings, and the field extension tables add the extra settings specific to that field.

This something that could be added at the core level because it's not actually 'doing anything', it's allowing entries to be extended by extensions and because this has already been done in Symphony, it follows a convention.

I think you're onto something here :)

I really like the idea of having multilingual support in Symphony and I think a multilingual extension would be the proper way to implement this feature (I just had to build my first multilingual website and it was annoying). But we have to be honest to ourselves: it's another beast like Members.

Beside the implementation, we need to keep flexibility in mind: Some websites might need a localised backend and front-end, others might not. Some might need language redirection, others might not.

So we have to find a way that allows the developer to taylor the needed multilingualism without being forced to use one "official" approach. An official multilingual extension must offer enough flexibility to set the level of multilingualism needed for a project.

My quick opinion:

I'm all for better multilingual site support but i think it should be kept in "small pockets of functionality" that can be mixed and matched.

I did some multilingual sites using Language Redirect + Lhandles + Multilingual textfields and this worked like a charm. Perhaps because i did not need any other field than textfields to be multi language.

My take on this is to make better integrations between this kind of extensions. Add delegates in the core to assist in the effectiveness, let go of the taboo of dependencies between extensions and let the core supply a way to register dependencies and warn when they are not met.

I love the way symphony lets me mix and match extensions, sections and datasources to create the website i want. I'd hate to see a monster extenssion that dictates the way i setup and run my site.

It should be said that delegates don't have to be provided by the core. Extensions can freely make their own delegates if they choose too. The problem with dependencies is just that, the success (or failure) relies on how much others agree with it and choose to support it.

The way I see it, with no multi-lingual experience (a fresh perspective?) The current extensions do most of the job.

The answer in it's simplest form is to bash out the most usable way of doing multi-lingual from all the methods available, then figuring out which bits are needed to be refined, and doing it as one extension.

As I read that both multi-lingual extensions kind of rely on each other, why are they still separate? They need to be merged and then the gaps filled in.

Editing tables in the DB to add new features by column smacks for serious error IMO and should be seriously stricken from the discussion. The DB schema shouldn't really be under discussion at all. It works the way it is, with extensions referencing other tables and storing values under their own tables, and it should stay like that. I agree that table generation should be abstracted in the future, but not for the purpose it's being suggested for.

I think the only core changes that should be made to support new methods of doing things, should be new delegates.

As I read that both multi-lingual extensions kind of rely on each other, why are they still separate? They need to be merged and then the gaps filled in.

Well, the extensions in discussion are Language Redirect, Page LHandles and Multilingual Field.Both Page LHandles and Multilingual Field need information from Language Redirect but all of them are separate things.

Let's say they all mix up. Language Redirect takes care of languages and redirect. What if someone else decides to use another approach for redirection but still wants to use the already-incorporated Page LHandles?

They represent a unified approach to creating multilingual sites rather than an extension. Small pieces, dedicated stuff. The developer chooses the tools to build with.

Don't forget the Tabbed Subsection Manager

I don't know where that branch/tag lives and/or is developed at the moment but I would love to see where that extension is going.

Interface-wise this SSM-tabs together with Language Redirect would be sufficient for a lot of my clients needs.

I don't know where that branch/tag lives and/or is developed at the moment but I would love to see where that extension is going.

It's the 2.x branch that contains the Subsection Tabs field. Static tabs work just fine, dynamic don't.

Nils, thanks. What do you mean with dynamic tabs? Do you mean that dynamically created subsection tabs do not work correctly? As opposed to subsection tabs created beforehand?

@vladg thanks for your explanation there.

What if someone else decides to use another approach for redirection

Do you mean something like URL Router?

I have been watching to discussion from day one and I think we are on something.

Basically, keeping the core slim is primordial and I realize that the only really important thing we need in the core is:

• Have a reference to all languages known to ISO
• Have a reference to the setting of currently supported languages: Could be null or default to the language symphony is already built-in, English.
• Have a reference to the current language

This is 90% of the Language Redirect ext, and that why we build upon it. I have modified the SBL extension and the Tag Ext in order to make filtering work in the good language using the LanguageRedirect Class.

The core should implement the 3 points mention in the Frontend, since it is already supported in the Backend.

The solution pointing towards including delegates in all extensions for other extension to do the multilingual magic is ok too, but if I had the Language or Culture always available I would not need any.

I did a lot of .NET development and always having a culture set is great. But I don't wanna go back to .NET :)

@designermonkey

Do you mean something like URL Router?

Wasn't thinking about something particular, was just a thought example.

There are a lot of mentions of Language Redirect in this thread. We have to keep in mind that language redirction is not always desired (neither on the front nor on the backend) - it's already a quite specific usecase.

I think there are three things we can do with this. Each method has its up and downsides, but I think it will be worth taking one step back (from actual implementation to the fundamentals) to see which approach is the most promising.

Note: the following points are in random order.

Method 1: Multilang in the core - one standard to which all fields can comply

A lot has already been said about this, but maybe it is a good idea to realise why this could be a good idea. If we are to support some sort of multilang (either using an extension or in the core) it would be required that basically all fields support this.

However, because the multilang features/implementations may differ per field, it might be very hard or even impossible to "automagially" make fields support multilang. In other words, it might be needed for extension developers to modify their extensions to support it.

Now, if multilang was supplied by the core, the chance of this happening is a lot bigger. Not only because it is a core feature, so if it is missing it could be regarded as a bug, but also because there might be different multilang extensions doing pretty much the same thing with a different implementation, making it very hard to the developer to know what to support.

In other words, if we bundle multilang in the core, it will result in high quality support from extensions because the task of getting their extension multilang supported is in their hands, rather than in the hands of the multilang extension developer.

Method 2: Multilang as an extension - automagically turn fields multilangual or a lot of work for the ML extension developer.

At this moment, this seems to be the most popular approach, but let's step back and see what this really means.

If we are to do this, it will not be required for the individual extension developer to support ML (simply because it is not in the core). This means that we can either have some auto-multilang-feature, or support for each field has to be baked in the ML extension (or a combination).

In my opinion, a combination might work: make some simple assumptions in the extension as to how it should work, but leave room for modifications per field. As an example on why this could be useful, let's take the unique text input field. By default, the extension could be handling ML the same way a normal text field would be treated. This would mean that within each language the value should be unique. However, if you wanted to change this to a unique value for every language, you would have to make a few (small!) changes.

Method 3: No backend multilang support - just build it in the frontend.

I have not seen this option in the discussion yet. But a generic multilang extension is nearly impossible to create, because the needs are very different for each project: some projects have the same content editor for every language, other projects will have an editor for each language).

Because symphony does not have a very good ACL in the backend at this moment, the only way to get around this is to replicate the backend in the frontend, and use the members extension.

All the building blocks to create multilang in the frondend are already there: you can setup a section for the content in each language, with a different section for the entries themselves. In the backend this would become messy, but this can be turned into something very useful in the frontend.

The main reason for me mentioning this option is because at this moment I see two kind of sites requiring some sort of ML: big multinationals and sites from strange countries (Netherlands, Belgium, Wales, etc). The first category of sites will most likely require a rewrite of the backend in the frondend anyway.

Thanks for that Huib, that's a pretty fair summary I feel. Like Members, there is more than one way to skin a cat, so whatever we end up doing is likely to have pro's and con's and will work in some situations but not others.

I'm still interested in how a Subsection Tabs and Language Redirect combo works (and how it doesn't work).

Let's also keep in mind that Huib's option three is actually being implemented by many enterprise CMS systems (including, but not limited to Umbraco and Hippo). Those systems also don't support multi-language in their core: they provide a very flat structure offolders and documents, with document types as a templating mechanism.

Users that want to create a multi-lanuage site with those CMS systems would need to create a folder for each language and duplicate the required documents within the thee. The content selection is done on the front-end by the web application. That is the place where you add the language awareness.

I'm not saying this is a very nice approach, for it leaves a lot of work to both developer and content managers, but it is pretty straightforward.

Users that want to create a multi-lanuage site with those CMS systems would need to create a folder for each language and duplicate the required documents within the thee

Thankfully this can be done presently in Symphony just as easily — add a select box named "Languages" to a section and create a duplicate entry with a different language.

First of all, thanks to everyone above for such articulate expressions. I've given this some thought, and we discussed at some length during a conversation about how this hypothetically could be tackled in a future Symphony 3 (if we would start from scratch). The consensus was much like #1 above:

• the core supports the concept of multilingual-ness at some level — it doesn't provide the entire functionality, just the hooks
• hooks are in the form of delegates and database columns
• a language flag (column) on each field's data row would define the language (and is optional)
• a version flag (column) on each field's data row would define a version (i.e. the same concept as multilang might permit content versioning of sorts)

Let's disregard the versioning idea because it muddies the waters beyond the scope of this discussion. But it should be noted that the same principle (a column in each field data table) can be applied both for multilang and content versioning.

Huib makes potentially the best point of the discussion:

In other words, if we bundle multilang in the core, it will result in high quality support from extensions because the task of getting their extension multilang supported is in their hands, rather than in the hands of the multilang extension developer.

I speak from experience when I say that catering for the existing multlang extensions, in my own extensions, has been farcical to the point of impossibility. I had a wonderful pull request adding support to Search Index, but unfortunately I had progressed the extension way beyond the codebase in the time before receiving the pull request. It needed a lot of customisation to get it working, and I was not happy merging something so proprietary, given that it six months time someone may devise a new, better way of implementing multilang sites.

Search Index is all about manipulating content, and so multilang implementation is central to the way it functions. I'll probably need to rewrite large parts of the extension once an approach to multilang has been agreed upon. So I'm keen for there to be "one true path" that I can implement against.

To this end, I fully support Method 1 above. Symphony could (and should) support the concept of multilingualism at its most basic level, providing the architecture for extensions to implement in a robust and succinct way. If that means updating field extensions (of which there are 66 registered) then so be it.

Michael is correct in saying that the core mustn't be too prescriptive in the way multilang is implemented. Each site has slightly different requirements ranging from extremes:

• no multilang at all, nothing exposing this concept should be visible to users
• one field in an entry needs to be translated, but not others
• all fields in an entry need translation without exception

What would be really useful is to collect examples of how people are presently using multilang concepts on their own sites. We've started doing this in the UX WG when planning some ideas for Symphony 2.3 (Tabs and Drawer). Boiling these down to their most basic forms would clarify what Symphony's core needs to include.