This project is read-only.

Orchard's localization is weird...

Topics: Localization
Dec 12, 2014 at 2:40 PM
Edited Dec 12, 2014 at 2:46 PM
I never ever saw anything so strange and counterintuitive like this.

Almost every single multi-language website on the Internet uses the simple website/lang/... pattern. Like in (or just /en/..) and trying to be 1-in-1 for different cultures.

Why in the world Orchard introduces these useless culture switchers on content items and other strange and unusable mechanism and patterns? You'll never find anything like this, when you have to click separate culture switchers on a parts of the website.

All these modules with cookie culture selectors and other things are just ridiculous. How search engines will ever find and index all the contents that becomes available only if the user has some specific settings in browser or special cookie set by widgets?

Why not just to let Orchard users to use almost standard mysite/en/products and so on? And why not give users the ability to have the localized homepage (mysite/en/ and mysite/de/ etc.)?
Dec 13, 2014 at 1:19 PM
Ridiculous and useless to you maybe, but perfectly useful to others.
Orchard does support the URL structure you mentioned, and you can configure the URL on a per content item basis. You don't have to use the cookie culture selector at all. I prefer the URL pattern you mentioned as well, and have successfully used it without the cookie selector.

That being said, I did have to write a few things of my own to make it smooth (using the ridiculous culture selectors you mentioned), and I totally agree that the localization story is far from perfect and in dire need of an overhaul.
We actually have plans to improve it as you can see here:
Many people agree that the current localization story sucks, but in the end, what gets done depends largely on what people contribute.

Anyway, you're in good company - myself and many others that I know of would love to see Localization perfected in the next version.
So it might just happen.
Dec 13, 2014 at 6:47 PM
I agree that the cookie culture selectors I think are a little bit of an anti pattern when it comes to localization, and I agree that your culture picker should take you too the culture of that page!? Well... it does :) if you use this shape..

So you could for example have a shape widget, and do New.FrontEndCultureSelector() or put it into you layout file. All is up to you. This will just display links to the localized version of your pages, be it /en or /fr or whatever, the slug naming convention is up to you. You can even add the culture to the route automagically using the autoroute template.

When it comes to modules or routes where you are not dealing with parts... you may need to change the implementation slightly, however, Orchard does know about culture, if culture is in the route dictionary - but that up to you to specify in your Routes.cs file... just add {culture} to the url template - you can see that code here - the reason this is needed is to avoid using cookies but still serve up translations.

There is a cookie culture selector added in for the admin screens, but you could also use that for the front end if you want to. and there is also a fallback to the browser language

The big problem I think - is that none of this is documented, So maybe a blog post is in order?? Localization is not a straight forward topic, lot of weird and wonderful layers need to be taken in to account.

@Sipke - what changes do you make? it would be interesting to know where it is lacking.
Dec 14, 2014 at 9:31 AM
I'm sorry I can't recall the details. It was some minor enhancements done from a custom module to achieve exactly what I needed.
Primarily what we need is an improved admin experience when it comes to localized content.
Dec 15, 2014 at 2:25 PM
Edited Dec 15, 2014 at 8:06 PM
Great! And this RouteCultureSelector... do you have any estimates for the release version? I mean, 1.9 or 2.0?

And it looks like there is no {Content.Culture} token for AutoRoute...

sfmskywalker wrote:
I prefer the URL pattern you mentioned as well, and have successfully used it without the cookie selector.
And how did you localize the homepage? Also, what did you do to the content's AutoRoute pattern (assuming that you don't have {Content.Culture} token)?
Dec 17, 2014 at 3:31 PM
I'm not sure how to correctly write GetRoutes() in my IRouteProvides to include {culture} pattern for the entire website. Can anyone help?
Dec 17, 2014 at 5:12 PM
Hey guys,

Have you tried Datwendo.Localization Module ?

You can choose from:

User Culture Selector
Content Culture Selector
Browser Culture Selector
Cookie Culture Selector

And you can also set priorities, in case you are using some of the options simultaneously.
In this module you also have other features like localized homepage settings, culture layer, menu culture filter etc ...
Iḿ using this module and iḿ very satisfied with it.
I think that most of the features in this module should be integated in core.
Dec 17, 2014 at 5:23 PM
It looks like the most of it is already there (in core, 1.x). At least content, browser and cookie selectors. Culture layer will be great. Currently I'm filtering layers by url("~/en*"). And I didn't find the culture picker widget although there is a cookie selector and there is a picker in admin panel.
Dec 17, 2014 at 5:47 PM
thims wrote:
It looks like the most of it is already there (in core, 1.x). At least content, browser and cookie selectors. Culture layer will be great. Currently I'm filtering layers by url("~/en*"). And I didn't find the culture picker widget although there is a cookie selector and there is a picker in admin panel.
Have you tried Menu Culture Picker?
Dec 17, 2014 at 5:55 PM
From Datwendo? Yes. But we're talking about Orchard.Localization built-in module now.
Dec 17, 2014 at 6:10 PM
thims wrote:
From Datwendo? Yes. But we're talking about Orchard.Localization built-in module now.
Did Datwendo work for you?
Dec 17, 2014 at 6:23 PM
Yes, it worked. But I find this functionality mandatory for any CMS. This is why I think it has to be in Orchard.Localization.
Dec 17, 2014 at 6:42 PM
These questions are to Jetski5822 (i believe he is responsible for the localization branch):
Why reenventing the wheel? Why not looking at the community contributions/modules?
And yes cookie culture is needed in some cases, depending on the project/client needs (just because you dont need it, doesnt mean its anti pattern).
Dec 18, 2014 at 10:01 AM
Hey All,

Layer filters are built in to the 1.x branch (to be 1.9) ( Most of the current modules on the gallery say that the culture is the language, which is completely incorrect, they should be the two letter iso value. Here are the rules in 1.x :-

culture-isrtl("true") <- Deals with RTL languages

all determined on the Culture selectors. We have most of the culture selectors from that module you are mentioning, not all, but we also have some different ones, all in the 1.x branch... But the implementations we have are different

User Culture Selector - We don't have, but I think sits outside of the core Orchard module... maybe a Orchard.Users.Localization (maybe I will write one)
Content Culture Selector -
Browser Culture Selector -
Cookie Culture Selector -

Localization should not be based on a cookie if you can avoid it. A site is driven by its content, content therefore has a culture attached to it. so if you for example are viewing /foo or /bar the current culture is going to be what ever those pages are localized too. If /foo was en-US, you wouldn't view it in en-GB, you would view the content that is localized to en-GB. Using a cookie selector kinda says, I want to view a en-US page in en-GB culture which is not something you would want to do. (At least that is my view) - But I am not saying you cant do that, you totally can - override the shape FrontEndCultureSelector ( and drop a cookie.

However, this is different when it comes to viewing the admin screens, you might be a Arabic speaker, but entering your content in English. So you can have your Admin screen in RTL mode, whilst entering your content in LTR.

Have you tried the culture filters in 1.x? Just turn them on and filter your content to the culture you want.

The one thing I do thing is interesting from that module is the ability to reorder the selectors... so, maybe that could be built in to a future iteration.
Dec 18, 2014 at 3:07 PM
Edited Dec 18, 2014 at 3:07 PM
All these culture-... rules are just great! I'm going to utilize culture-lang() immediately.
Dec 18, 2014 at 3:13 PM
awesome - let me know how you get on with them.
Dec 18, 2014 at 3:30 PM
Not sure how to turn culture-... rules on. Can you please advise?
Dec 18, 2014 at 3:36 PM
Are you on 1.x?
Dec 18, 2014 at 3:37 PM
Edited Dec 18, 2014 at 3:57 PM
Yes, sure. And mentioned culture selectors work flawless. But Orchard doesn't recognize the culture-... rules...
Dec 18, 2014 at 3:58 PM
can you paste your later rule in here?
Dec 18, 2014 at 4:02 PM
Dec 18, 2014 at 5:13 PM
Maybe this is because of the "-" character?
Dec 18, 2014 at 6:12 PM
Edited Dec 18, 2014 at 6:17 PM
Hi Jetski5822,

I´m glad all those features you mentioned are integrated in core, I also advocate that localization in orchard should be treated as a "first citizen" if we want it to be used globally, but i also see that localization is still a work in progress, that needs several improvements specially in the admin.
I also believe that localization shouldn´t depend on external modules, because of the risks ineherent to the fact, that future orchard core updates might break them.
So we all agree in the importance of localization beeing in core.
I´m using an external module because at the time i started one of my clients project (October) the localization features in the Localization Branch weren´t enough for the project´s requirements. But as soon as i get a chance i´ll try these new features in 1.x branch.

About the cookie selector, not every thing is black or white. Probably you didn´t understand me or i didn´t explained myself right. Here goes:

I´m also aware that cookie selector by itself is bad (seo is a good example), but that´s not what i´m doing, instead i use it combined with content culture selector and then set the priorities, giving a higher priority to content culture, so if a cookie is not set the url is always availabe.
I also use the culture token in autoroute to generate the urls example:


And now you ask me why the hell do I need a cookie selector?
The answer is simple, my client wants it (just because he can, and he pays), but he also gave me a very good reason:
"I want the visitors of my site, to have the option of having their prefered language stored, so the next time they visit my site, they dont have to do it again. Imagine if i was chinese company, would it be reasonable for my western visitors to be changing the language every time the visit the site? Trying to figure out where the language selector is in the middle of all those chinese characteres"

PS. Last week i went to a meeting with a new client, and he also want´s cookie selector as well.
Dec 18, 2014 at 6:40 PM
Edited Dec 19, 2014 at 9:26 AM
thims wrote:
Maybe this is because of the "-" character?
Yes. This is it. Just replaced "culture-lang" with "culture" in CultureRuleProvider.cs and it works. It looks like the Parser in Scripting interprets "-" as "minus". Therefore, you can't use "-" in rule "operators".

Submitted the Issue.
Dec 19, 2014 at 9:54 AM
weird, this was all tested so the "-" should have worked. I will take a look this weekend. Sorry about that chaps.
Feb 18, 2015 at 5:12 PM
I have removed the - from the rules. So now it is

cultureisrtl("true") <- Deals with RTL languages