Orchardcore: Editing LTR contents from RTL admin panel and vice versa.

[ampadashi]

The current HTML editor in Orchard Core doesn't let us to change the direction of the html text. So, in multilingual websites, when we create LTR content, we will not be able to edit it from RTL admin panel and vice versa.

[Skrypt]

/cc @hishamco
I thought we had added a RTL css class for this on the editor?

[hishamco]

As @Skrypt said we already did this before, be sure your culture is set to fa-IR to make the editor support RTL

[hishamco]

FYI https://github.com/OrchardCMS/OrchardCore/pull/3575

[ampadashi]

what i mean is to set for example only fa-IR culture which is rtl and be able to manage both rtl and ltr content items using it. Just like other CMSs like Wordpress, Joomla or DNN

[hishamco]

Nothing stop you for doing that, nothing but the default flow depends on culture text direction. For instance fa-IR culture will flow the direction to RTL, but still you can write en

If that is not the case, let us know your scenario

[Skrypt]

I need to test to understand better. Maybe something that would be related again with admin culture picker. Though what you are explaining is actually a module "Content Localization" which needs to be enabled to be able to create content items that have LocalizationSets.

[ampadashi]

Hisham, suppose that we have a content type contains content localization part and we create one content item for en-US culture and also localized version of this item for fa-IR. Suppose that the default culture of the admin is fa-IR, so, the language is Persian. When we try to edit the en-US version of this content item with fa-IR culture set, the direction of the inputs must be changed to ltr automatically. No matter what the direction of the default culture is. Right now, the only way to change the direction is to change the default culture of the admin, then try to edit the localized version of that content item.

[ampadashi]

Jasmin, is there any culture picker for admin panel letting us change the current culture of admin panel easily from every page?

[Skrypt]

No there is none so far. But what you are describing seems like an issue to me. If you are editing a content item that is "fa-IR" it should show the Wysiwyg editor as LTR even if you would use a admin culture picker.

[sebastienros]

Looks like the direction of the editor should depend on the content item's culture and not the admin culture (Thread).

We should introduce some metadata for the culture of a content item so the html editor (and others) don't have a dependency on the localization part. LocalizationAspect or something like this in the Localization.Abstractions project.

Then also change the text fields and markdown, or anything that is sensitive to that.

[hishamco]

Amir I just understand the issue right now, because you didn't tell at the first thread it's content localization related

As @sebastienros said that editor should aware about the content localization

So Seb can we do this before 1.0.0 or shall we shift it to 1.1?

[sebastienros]

Can be done before. Nothing is blocking it.

[hishamco]

don't have a dependency on the localization part.

The localization set of is very handy to guide us which culture we are working with, so the direction of the editors should respect that, but this need to override the default behavior

[sebastienros]

Design:

• Create a CultureAspect class in the Localization.Abstractions project. It has a CultureInfo Culture property.
• Implement GetContentItemAspectAsync in LocalizationPartHandler to return a CultureAspect with its culture the one of the Localization part.
• In the Html editor (and other ones) call

var cultureAspect = await _contentManager.PopulateAspectAsync(context.ContentItem, new CultureAspect { Culture = Thread.CurrentUIThread.Culture });

Then use the CultureInfo RTL property to use in the editor.

[hishamco]

@sebastienros why GetContentItemAspectAsync() not called?!! When it should called?

BTW I find a simpler way to changed direction of the editors by looking into a culture for the associated content item for the rendered field

[hishamco]

Seems a new code change introduced a Content Culture Picker feature, which register the LocalizationPart, this made me crazy 😄 I spent a lot of time on this

I'm not sure if this a better way to register LocalizationPart, I expect it will be register on enabling a content localization module

/cc @jptissot

[ampadashi]

It still doesn't work properly. When we use a part or type as a widget in a Flow Part, the direction does not follow the direction of the selected culture.