Choosing lanuage should utilize direction from lang file

[Damian]

Considering that all language files already have the language direction set. The process loading configured language should have the option of automatically picking the correct content direction for the editor.

E.g. if a RTL language is set then contentsLangDirection: "rtl" should be set automatically.

[Frederico Caldeira Knabben]

The fact here is that the language used in the contents is note always the same as the editor UI localization. We can easily have an Arabic user, using the editor localized into Arabic, typing English text in the editor.

But it's also reasonable to accept that usually people will write in their applications UI language. So, maybe we could extend the contentsLangDirection setting by having the "ui" option (default), which instructs the editor to use the UI language in the contents. We'll leave the option to force a specific direction through this setting.

Does this looks like a good approach for it? Is that risky, having people leaving the "ui" setting there?

[Damian]

I think your proposal seems to solve the problem. It has been our experience that most of the time users will be writing in the language that the editor is loaded in.

I wonder whether the editor should allow users to override the language direction in the content area from within the editor itself (i.e not through config but a plugin)? This way, the user can have the final decision on which direction they prefer.

[Frederico Caldeira Knabben]

Replying to damo:

I think your proposal seems to solve the problem. It has been our experience that most of the time users will be writing in the language that the editor is loaded in.

Ok, so let's add this new feature.

I wonder whether the editor should allow users to override the language direction in the content area from within the editor itself (i.e not through config but a plugin)? This way, the user can have the final decision on which direction they prefer.

The problem here is not really the user, but we need to inform the application about the language decided to write in. This is not an editor level feature (by default), but app level, so we should not have anything in this sense.

Note that some applications may create plugins for the editor to indicated the language, but the plugin, other than changing the editor, will also deal with application specific APIs to save the language option.

[Alfonso Martínez de Lizarrondo]

The code in

if ( !body )
	window.addEventListener( 'load', arguments.callee, false );

would need a check to add the correct listener for IE, but I'm not sure if the patch addresses the previous comments.

It's picking the direction based on the containing html page, but my understanding is that it should take the same one that it's used for the editor chrome, so it should default to editor.lang.dir

Of course, I'm not sure about this comment so I would ask damo to please confirm what's the expected behavior.

Another different thing would be adding two buttons in the toolbar to generate ltr or rtl blocks inside the content. That should be possible by using the style system like it's shown in the styles combo.

[Garry Yao]

I've confirmed with Fred that the previous patch is based on a totally misunderstand of the original idea, which is as simple as providing a special option for contentsLangDirection.

[Alfonso Martínez de Lizarrondo]

The langLoaded event is requested in #4345, but I'm not sure if its use is needed for this fix.

Can't we put in core/editor.js the code directly?

var config = editor.config;
 config.contentsLangDirection == 'ui' && ( config.contentsLangDirection = editor.lang.dir );

If you agree, then you can provide the event code in #4345 as well as the docs for the new event.

[Garry Yao]

If you agree, then you can provide the event code in #4345 as well as the docs for the new event.

I'll provide on that ticket after this get closed.

[Frederico Caldeira Knabben]

Please have this feature committed into the 3.3.x branch.

[Garry Yao]

Fixed with [5278].