Symphony.

The trick is an helper section where you make the page translation. The page field is usefull with that.

My first steps with symphony I was both surprised and frustrated. But when I learn more and more I mostly see only the power of the 'oldskool' xslt transformation and templating. Symphony fills the gap to give the data I want.

If I want to offer my visitors ability to switch languages, what do I have to do. Do I just need to offer them a link that leads to mypage.com/another-language/some-page and extension will notice another-language in the address and automatically switch en to e.g. he if another language is hebrew?

Exactly.

Do I have to set the cookie my self through template, or does extension notices if person switched from mysite.com/en/page to mysite.com/he/page and automatically sets language parameter to he?

No cookies here. Language is only set via URL at the moment, so if you want to implement a language switcher, you simply create some sort of menu with the language specific versions of your current URL, like you already said.

I want to have this kind of url:

http://mysite.com/en/gallery and http://mysite.com/he/gallery,

but I can't do that without the routing extension because I can't make two pages with same handle gallery even if I apply different parent page (e.g. en, he).

Should be possible, otherwise it's a bug in the core.

@jens routing is only for language dependent urls?

I use Routing for other projects as well. Allows for nicer URLs. For example, Symphony only can handle URLs like example.com/blog/article/hello-world/ while with Routing you can handle example.com/blog/hello-world/ and still have two separate pages blog and article.

If I use navigation data source to generate menu, and also if I use routing extension instead of creating separate page for each language, how can I translate menu items?

I'm not sure if it's even possible with such setup, or is there some trick?

Doesn't work with the navigation datasource, sorry.

The trick is an helper section where you make the page translation.

Yep, that's one possibility and generally a good approach.

Updated version ready for testing on GitHub. Tested with 2.3.3 - 2.x.x, but I recommend updating to 2.5.0-rc.2 right away. Symphony 2.4 has some issues that are fixed in the upcoming release.

I also changed the version numbers to follow SemVer, so the current 2.0 release is renamed to 1.0.0 and the new version is 1.1.0.

Adding 10 languages is a major increase in page creation (roughly from 0.5s to 2s).

Is it possible to only create/get the entries from the current language and eventually the default language?

Adding 10 languages is a major increase in page creation (roughly from 0.5s to 2s).

Yeah, that's what I thought. Performance wasn't really a concern when creating the original workflow because I assumed people would use some sort of output caching anyway.

My biggest concern is performance

If your only concern is performance and you want to keep the tabbed interface and don't mind creating so many fields manually, you could still use Multilingual and set up different datasources for different languages, including only the current language and the default language as you suggested.

You'd also need a separate datasource to output only a specific field but for all languages if you want to create some kind of URL based language switcher.

For an alternative workflow, see my response in your other thread (later ;).

you could still use Multilingual and set up different datasources for different languages

Nice if it is out of te box. But how? An extra field with the language?

Did I miss the alternative workflow in the other thread? Only got a response of vladG on the other thread ... ah double check and there it's said later

Nice if it is out of te box. But how? An extra field with the language?

No, in this workflow you set up your datasources as you already do (with Multilingual), but instead of creating one datasource that outputs all fields for all languages you create one datasource for each language that outputs only the fields for that language and the default language.

You'd also get rid of the routing extension and set up translated URLs for each language manually in the core. That way you can attach the right datasource (for a specific language) to the right URL (for that language). To avoid duplicating templates, you can simply include the actual markup template in the language specific page template.

Got it. It is roughly what I have in mind.

Default multilingual outputs all the fallback fields. I dont think this approach won't work with multilingual.

Default multilingual outputs all the fallback fields.

That's what it's supposed to do.

I dont think this approach won't work with multilingual.

Why not?

Keep in mind, I'm not trying to convince you to stick with Multilingual in its current incarnation for 10+ languages. I would probably use a different approach myself in such a case.

But it should work as described above, so I'm curious... ;)

Agree it works but not the performance.

That's what it's supposed to do.

So we got at least 10 seperate data sources multiply with 10 languages ... and that is a major performance decrease ;-).

After endless trial and error I stick with one section which contains the default language and another section that contains the translations and do the less-extensions approach.

The translation section got an association with the default language. An union data source and some templating must do the rest.

So we got at least 10 seperate data sources multiply with 10 languages ... and that is a major performance decrease ;-).

You got 10 separate data sources multiply with 2 languages (current language and default language), but you only add one of these 10 data sources to the page (one page for each language).

Doesn't seems to work that way. Enabling multilingual, set 10 languages in preferences and all datasources are multiply with the count of the languages <nav-footer> <section id="19" handle="footer-menu">footer menu</section> <entry id="167"> <menutxt handle="test-footer" lang="en" translated="yes">test footer</menutxt> <menutxt handle="test-footer" lang="nl" translated="no">test footer</menutxt> <menutxt handle="test-footer" lang="de" translated="no">test footer</menutxt> <menutxt handle="test-footer" lang="fr" translated="no">test footer</menutxt> <menutxt handle="test-footer" lang="cz" translated="no">test footer</menutxt> <menutxt handle="test-footer" lang="dk" translated="no">test footer</menutxt> <menutxt handle="test-footer" lang="it" translated="no">test footer</menutxt> <menutxt handle="test-footer" lang="ua" translated="no">test footer</menutxt> <menutxt handle="test-footer" lang="es" translated="no">test footer</menutxt> <menutxt handle="test-footer" lang="lv" translated="no">test footer</menutxt> <external handle="https-twitter-com" lang="en" translated="yes">https://twitter.com/</external> <external handle="https-twitter-com" lang="nl" translated="no">https://twitter.com/</external> <external handle="https-twitter-com" lang="de" translated="no">https://twitter.com/</external> <external handle="https-twitter-com" lang="fr" translated="no">https://twitter.com/</external> <external handle="https-twitter-com" lang="cz" translated="no">https://twitter.com/</external> <external handle="https-twitter-com" lang="dk" translated="no">https://twitter.com/</external> <external handle="https-twitter-com" lang="it" translated="no">https://twitter.com/</external> <external handle="https-twitter-com" lang="ua" translated="no">https://twitter.com/</external> <external handle="https-twitter-com" lang="es" translated="no">https://twitter.com/</external> <external handle="https-twitter-com" lang="lv" translated="no">https://twitter.com/</external> </entry> </nav-footer>

one page for each language

My templates are based on an one page template. So the client got maximum flexibility.

You got 10 separate data sources multiply with 2 languages

That should mean that the client have to copy the default language 10 times

I would probably use a different approach myself in such a case.

;-) Yup, same here. The hardest part was to make some logical between default language and translation. But it seems I'm on track now.

That should mean that the client have to copy the default language 10 times

The default language would be in each data source, but you'd only include one data source per page. So there's indeed a massive overhead for developers when creating data sources (not to forget the manual replication of every field in each language when creating sections), but not during runtime.

With extension enabled, the user is redirected to /defaultlanguagecode/ but a 404 error redirection appears instead of desired page

SymphonyCMS: 2.5.1

Multilingual: 1.1.0

With extension enabled, the user is redirected to /defaultlanguagecode/ but a 404 error redirection appears instead of desired page

The extension only redirects, but doesn't create or reroute pages. So you have to create pages for /en/, /de/ (depending on your languages) first. The idea was to do as much as possible with core functionality.

so, htaccess will do the rest?

so, htaccess will do the rest?

Yep.

Multilingual updated to version 1.1.0 on 27th of October 2014