Multi-lingual sites - culture switcher/picker

Topics: Core, General, Localization
Sep 15, 2014 at 8:29 AM
Hi all,

I would like to open a topic/discussion on creating a Multi-lingual site with Orchard.
I will be honest with you, I'm a .NET developer but I don't have the time (yet) to develop, customize or write orchard modules. Like the majority of user I create custom child themes to change some CSS layout and I use existing modules.

First of all I want to give you a brief history of my 'frustrations'.
When orchard launched I've been using it for some sites.
I've been using several versions, 1.1, 1.3, 1.xxx, 1.8 and now 1.8.1.
Every culture picker module that I've used had problems: throwing exceptions, breaking my navigation or the module just didn't work.
Upgrading Orchard to a new site often broke existing modules etc...

I've seen the problems in almost every orchard version:
  • when adding new pages, menu items sometimes disappeared.
  • a selected language was reset when navigating to another page
  • when switching to another language, menu items sometimes disappeared
  • when a menu item has no translation it does not show the default translation (using the same module in different orchard versions shows them, so upgrading a site often breaks the navigation)
  • if you forget to add a Localization part to menu items and you've already created your content Pages in every language, the navigation will not update correctly.
  • modules work in version x but upgrading to another version, breaks the module, so we can't upgrate the site. (this is the reason why some of my sites are still at version 1.3)
  • ...
In Belgium we have 3 official languages (Dutch, French and German), but we almost always add also English.
You have to understand that when a culture picker module doesn't work that good while you have to maintain a site in 4 languages, you sometimes get a bit angry.


On the development roadmap there might be some improvements for Multi-lingual sites:

"•Localization improvements (on track, test/feedback needed) •Nick (Jetski5822) is responsible for this feature
•RTL support in Admin
•Culture selector (admin and front end)"


This is the latest module I've used:
http://gallery.orchardproject.net/List/Modules/Orchard.Module.Orchard.CultureSwitcher


What modules do you use to create multi-lingual sites?
Any specific configurations that you use?
I would be happy to hear some of your experience.


I hope this feedback will help and that we will see some improvements.
Sep 15, 2014 at 9:11 AM
I know you said you don't have the time to custom develop modules yourself, but for www.tacx.com I custom coded the whole lot.

A mix of a custom menu system (loosely based on the 'Advanced menu' module) and multiple ICultureSelector implementations (extracts expected culture from cookie, browser headers, url, ...)

My localization system also has a fall-back support.

In short when you ask for a page /nl/some-page and it doesn't exist, but /en/some-page (our default language) DOES exist, it'll return that instead to the visitor.

The menu is mostly per language specific, but its a single 'menu' container with items configured to show (or not show) for specific cultures.
Developer
Sep 15, 2014 at 12:27 PM
Hey Guys,

What do you want from a Culture Picker?, if the goal is to change culture of the piece of content you are viewing, then that is quite easily done using the shape "Parts_Localization_ContentTranslations", and use placement to place it in the header if that's what you want.

What is your requirement?

Culture pickers I think are split in two sections,
  1. Admin culture picker, where the route has no localizable identifier.
  2. Front End where the route does have a localizable identifier, i.e. the route is different per culture.
So the idea is to do two different implementations:

1. Admin

When an Admin enters the Admin console for the first time and the user has not chosen a localization from the Admin culture picker, then we use the users accept languages which are sent over in the browser request. If those are not supported by their version of Orchard, then we fall back to the Site culture.

2. Front End

This uses the Part as mentioned earlier, "Parts_Localization_ContentTranslations" - It lists all localizations for the piece of content, however what has changed is what happens when you change culture i.e.

Current Process:
Lets say I am on the homepage "/" with a culture of "en-US" and I click on "/en-GB" in the links, this will redirect me to the page "/en-GB" but leave my culture unchanged as "en-US"

New Process
I am on the homepage "/" with a culture of "en-US" and I click on "/en-GB" in the links, this will redirect me to the page "/en-GB" but change my culture to the one to which I am viewing "en-GB" in this instance


You can always checkout the work we have been doing on Localization.

Go here.... https://orchard.codeplex.com/SourceControl/latest and checkout the branch feature/localizationchanges

Let me know what you think, and I will see if I can address some of your issues in my branch if I haven't already.

Nick
Sep 15, 2014 at 6:51 PM
Edited Sep 15, 2014 at 6:52 PM
I just added this to gallery
https://gallery.orchardproject.net/List/Modules/Orchard.Module.Datwendo.Localization
it solves in the same way as @aimorchard stated the languaage content display (adapted content to current language) and add very usefull alternates based on culture.
Moreover there is a culture picker you can add in your menu as in the site
https://www.datwendo.co
Developer
Sep 15, 2014 at 9:00 PM
@CSADNT Out of interest, why have you got Cookie Culture Selector? when you can derive the culture from the content?

I only ask as I just decided to take that out of mine - but am thinking maybe there is a reason why people use it.
Sep 15, 2014 at 10:13 PM
Edited Sep 15, 2014 at 10:14 PM
Jetski5822 wrote:
@CSADNT Out of interest, why have you got Cookie Culture Selector? when you can derive the culture from the content?

I only ask as I just decided to take that out of mine - but am thinking maybe there is a reason why people use it.
If out of interest why so many people use it?
You missed an important point rushing on localization without some thinking :)
Some users prefer to force a culture, maybe different from their browser's culture, and to do this they use a cookie.
Then if there is a translated contentitem for this culture, great, but after a rule must tell which fallback culture to use, and for this many solutions: fixed choice, regex, etc.

Rather, in your new controller I am not sure you totally cover what was doing the code you throw to garbage collector, and does the service you supressed not make your code incompatible with all the modules using it ?
Last point, I don't see the necessity for a front-end and an admin code if you use the selectors correctly.
Sep 15, 2014 at 10:24 PM
Edited Sep 15, 2014 at 10:27 PM
Another point: when you want to see a dedicated culture in admin, it means to have the admin interface in this culture, not necessarly the content.
And the Admin interface culture may not be amongst the front-end cultures.
Today we have only a bunch of selected site cultures, and amongst them there is the Admin culture, which not necessarly needs translations for content provided by the site.
I think Admin UI culture should be treated differently than the available site cultures, with a dedicated site setting, independently of an admin culture selector which could use various rules to take the admin culture, identical or different then the front-end. This is the role of the admin culture selector and its fallback rules.
Developer
Sep 15, 2014 at 10:40 PM
I don't think I rushed in to implementing anything, else it would be in 1.x and not on a branch.

But your implementation bypasses things like if a users chooses a culture of it-IT for example, browses away from the site then types in www.foo.bar/en-GB they are then redirected to the it-IT content.... that's not user friendly.

I am not suppressing any services?

There is a difference in the way the Front End and the Admin implement localization - But both still use selectors? So I am not sure what you are talking about. There is a DefaultFrontEndCultureSelector and a AdminCultureSelectorSelector ?

I also provide a Cookie and a Browser Culture Provider out of the box, however, those are only used in the Admin culture Selector. Where as the Front End relies on the Content you are viewing by alias.

When did you last pull the latest code?
Sep 15, 2014 at 11:02 PM
Edited Sep 15, 2014 at 11:16 PM
Jetski5822 wrote:
But your implementation bypasses things like if a users chooses a culture of it-IT for example, browses away from the site then types in www.foo.bar/en-GB they are then redirected to the it-IT content.... that's not user friendly.
I don't think so, if people want to see the en-GB culture they change using the culture picker, they don't input the culture from the url.
Depends you are building a site for geeks or 'normal' users.
And this is a simple option, I have a contentculture selector, if you set a higher priority to it, it wins.
I am not suppressing any services?
Ok, I was thinking you told you suppressed the Culture Service
There is a difference in the way the Front End and the Admin implement localization - But both still use selectors? So I am not sure what you are talking about. There is a DefaultFrontEndCultureSelector and a AdminCultureSelectorSelector ?
I say that the Admin UI culture is different than which culture you display by default in Admin mode.
I also say that the Admin culture is not necessarly a 'content' culture, it could be used only by admins to have menus in their language, but no content will be translated in this language.

I create a Spanish and English site -> only spanish and english contents
but I have a French admin who will be happy to see admin menus in French.
No need to bother the site with french as a site culture because it is not.
With actual implementation we must. I see this as a bug.