This project is read-only.

Localization/RTL Updates

Topics: Core, Localization
Aug 10, 2014 at 7:07 PM
Edited Aug 10, 2014 at 10:30 PM
I have just pushed a new branch to start looking at changes to the inbuilt Localization features.

As I know there are a lot of people who have started their own, and most of the reasons are because we haven't got core support for them. So this is to try and address this.

Changes so far:

Added TinyMCE localization scripts to TinyMCE module

I have downloaded and added all the Localization Scripts from and included them in the solution

The problem is that within TinyMCE, if you specify a language that does not exist, TinyMCE will not fall back to another culture...

i.e. if your culture is de-DE as your language it will look for the script de_DE.js. If this script does not exist, it wont fall back to de.js. (This is the TineMCE behaviour not Orchard behaviour)

To work around this, I have added two checks for the language files before pushing the language into editor. So First it will look for the Content Culture (de-DE) in this instance, if that does not exist, then it will look for "de", if that does not exist then it will fall back to the TinyMCE default "en".

By specifying the language file it set the Toolbar and Directionality to be RTL/LTR.

If the site culture is RTL, but TinyMCE does not have a language pack for it, then Directionality is set separately, this is based on the Content Culture if it exists, else it will fall back to the Site Culture.

Culture Picker

I have added a culture picker feature to Orchard.Localization. This is a default implementation being just a Shape, which means it is up to the themers to add it to their theme. The Shape surfaces all cultures within Orchard.

The Storage of the value is pushed to an ICultureStorageProvider, with the default implementation being a HttpCookie (Yum).

Admin Theme

I have added a Culture Selector Shape to the Admin Theme, if the Culture Picker feature is enabled, though this is done in the Localization module using ShapeDisplayEvents

Things to be done
  • Add RTL/LTR to the Admin screens. (currently working on) : This is tricky, Do you make the whole Admin RTL? Or just the Content Zone. - I think just the Content Zone... Not sure.
  • Add TinyMCE LTR/RTL buttons
  • Ability to do translations within the Admin Screens.
  • Culture Layer rules.
  • Investigate jquery.mjs.nestedSortable.js RTL rule.
  • Investigate jquery-ui-sliderAccess.js RTL rule.
  • Investigate all javascript files in Orchard.Templates\Scripts\codemirror\ for RTL.
I am sure there is loads more, but this is a start to get it going, and as always suggestion welcome.

Aug 10, 2014 at 9:11 PM
Very good initiative!

Regarding the client-side localization files for TinyMCE, I meant to tell you that I had to do the exact same thing for the calendar picker. Based on the configured culture I check for the existence of a corresponding localization module in the script folder, and load it conditionally. I believe I also do the country-neutral fallback you mentioned, but I don't remember 100%. If you haven't already, you should be able to reuse some code from that.

Not sure I get what the culture picker is for - is it for front-end use? Actually I'm not clear on what the admin culture selector shape is either... :)

Add to the TODO list: enable manual override of RTL using a button in TinyMCE if no conclusive culture for the content can be found.
Aug 10, 2014 at 10:01 PM
Edited Aug 10, 2014 at 10:03 PM
If the various culture selectors and pickers are features we can disable no pb, else you break many current modules better implemented.
Concerning culture layers, I am reserved on this feature and any idea to extend it. There are better ways to handle the situations it was intended to solve.

I would prefer having a javascript code forcing the tinymce default when the localization controller Translate methods are used.
Aug 10, 2014 at 10:24 PM
Edited Aug 10, 2014 at 10:45 PM
@Decorum The idea to have the Admin Culture picker was to allow users to change the culture of the Admin Screens which they cannot do at present. The cool thing though, is that the Culture Picker is just a shape, so you can use it for the Admin and non Admin themes.

Good call on the TinyMCE button! - Will add that in.

I will also check out you fall back code too. I read the reason why the plug in authors didn't do it was to avoid 404's, which I guess makes sense.

@CSADNT The new culture picker has the UI, Storage and CultureSelector separated, a lot of implementations I have seen currently don't do this and you end up having multiple ICultureSelector implementations linked to your storage mechanism. Giving you the separation should require module author to write less code to get to the same goal, and yes, because this is a feature, you can use SuppressDependency to use a different storage.

The Translate methods that @Decorum mentioned will be there when you have more than one language on your site where 1 at LTR and 1 is RTL. There is no point having them if all your cultures are LTR, or RTL.

Side Note - I am wondering if we need a Default Admin Culture.
Aug 11, 2014 at 7:51 AM
Edited Aug 11, 2014 at 7:52 AM
Nick, please give a try to this, code is free :)
Just to say that I have pushed the idea of Admin culture selector and culture fallback further, with a different approach than controller for language selection, everything being in its own feature.
I also fixed bugs in current localization Translate method and related javascripts used in UI, as for exemple the null culture

I don't see where @decorum mentions Translate method?
Aug 30, 2014 at 3:35 PM
Edited Aug 30, 2014 at 3:36 PM
Hi All,

Okay so an update form where I was last time. I have now done these inclusive of the last post.

Add RTL/LTR to the Admin screens.
This has RTL split on Site and Content Zones, so you can view the Admin screens in English but edit in RTL for a content item that is localized so, and vice versa.

Localization Core Change
Allow the ability to create the Master Content Item from any Culture

Added RTL/LTR buttons.
If you change your culture when editing the content item, the directionality will now change.

Culture Layer
I have added culture layer rules. This allows you to create a culture specific layer using either culture-code('en-GB') or culture-lcid(1234)

I have added support for Transliteration of Urls. the Api is extensible, so if you want to do it for more that just URLs, then have at it.

Culture Filters
Sebastien has added Culture filters for Widgets and Content Item view.


What does everyone think about adding a Translation Service. I think the ability to provide a translation service is quite an important aspect of localization. Things like, clone this content item to ar-IQ etc. Most if not all CMSs allow for human translation (which Orchard currently has), but machine translation is also a beneficial feature that can be packaged within a system. While machine translation does not have perfect results, it is useful on smaller projects where accurate translation comes second to getting a message quickly across to a new or established market.

I was thinking that if we do provide a "Default" implementation, that does nothing but allows users to turn on their own, such as the "Microsoft Translator API" ( then editors who are translating content can easily translate within context. Not sure of the UI or how it will work, the API would be as simple as this...
public interface ITranslationService : IDependency {
    string Translate(CultureInfo from, CultureInfo to, string value);
Ideas on a postcard. N
Aug 31, 2014 at 2:00 PM
Awesome work Nick!

Would it be useful to also have a layer rule for RTL?

Regarding machine translation, I think it would be useful. But I would wrap up the other stuff for 1.9 first and make translation a feature for 2.0.
Aug 31, 2014 at 4:34 PM

Good point!!! I will add that then pull the whole thing in to core.

Translation is totally another branch.

Sep 1, 2014 at 5:41 PM
I don't think it would make sense to have an RTL rule. We already have a culture one. Any example of what would be displayed specifically for RTL?
Sep 1, 2014 at 6:42 PM
For example if you have two different versions of some widget, one for LTR and one for RTL.
Sep 1, 2014 at 10:39 PM
I had already added it. culture-isrtl is the rule, accepting a true of false. I dont see an issue in have this.

Do you think the Culture Layer should be a feature? or on by default with Localization?
Sep 2, 2014 at 12:43 AM
I would vote for making it part of the Localization feature.
Sep 4, 2014 at 2:38 AM
I found this issue wich could be fixed as part of the current work done on localizations.
Sep 4, 2014 at 9:08 AM

Sounds like the workaround is the fix... @T(name) Whatcha think?

Sep 4, 2014 at 11:26 AM
Isn't there a problem in your CultureStorageProvider always using cookies ?
Sep 4, 2014 at 3:31 PM
What the problem?

Sep 4, 2014 at 5:37 PM
Edited Sep 4, 2014 at 5:39 PM
Well you set a cookie even when cookies are not the current culture selector....and may be when there is not httpContext (batch).
But may be I have not understood the situation where you need to save current UI culture.
Aside a small name mismatch CutlureSelectorController - > CultureSelectorController , or it is a style effect
Sep 4, 2014 at 5:46 PM
Moreover, you still have code setting culture to null and potentially breaking everything according this
                var culture = originalLp.Culture;
                if (culture != null) {
                    culture.Culture = null;
                model.Content = _contentManager.BuildEditor(contentItem);
                return View(model);
here it should be
                if (culture != null) 
                    culture.Culture = null;
                model.Content = _contentManager.BuildEditor(contentItem);

                // Cancel transaction so that the CultureRecord is not modified.

                return View(model);
should be better to not use culture.Culture = null;
Oct 13, 2014 at 6:50 PM

I tested the latest update 1.x branch.
Why do not I see FrontEndCultureSelector.cshtml on the front end?