- Issue created by @hejazee
- Status changed to Closed: duplicate
11 months ago 10:51pm 12 July 2024 - Status changed to Active
7 months ago 12:03am 4 November 2024 This issue remains unresolved
and issue #3461112 is not a duplicate of this.I recently updated to 5.0.0 and the problem is not solved.
Let's clarify the requirements:
An element in the editor can have three distinct states:- State No. 1: an element with dir set to "rtl": <div dir="rtl">
- State No. 2: an element with dir set to "ltr": <div dir="ltr">
- State No. 3: an element with no dir attribute set:
Currently, this module includes two buttons but does not support all three states. Only State 1 and State 3 are supported.
The intention is that no admin configuration should be required for all three states to be available to users simultaneously. The admin should not need to configure the editor to allow toggling dir="rtl" or dir="ltr"; rather, users should always have the option to select between the three states, regardless of any admin configuration.
(At the very least, an option should be provided in the settings to allow users to choose among the three states.)
Proposal:
We should have two buttons:
1 - A button to toggle between dir="ltr" and no dir set.
2 - A button to toggle between dir="rtl" and no dir set.Note: the two buttons can not be active at the same time. Only one of them or none of them can be active at a time.
- 🇮🇱Israel israelshmueli
I believe we can fix this issue by providing, via the JS, default direction value based on current page direction. Please see the enclosed patch.
These daye we are upgrading the Bar-Ilan University multiple department websites from CKEeditor 4 to ckeditor5
Most of our department websites needs that the bidi plugin will work on pages in both directions since usually Hebrew and English is enabled on same website.
Currently the module is not working as expected on the RTL pages because the default language is defaults to LTR.
In the enclosed patch the default direction is set dynamicly according to the current document/page direction. - First commit to issue fork.
- Merge request !16Resolve #3413674 "Get default direction from editor locale" → (Merged) created by anairamzap
- 🇦🇷Argentina anairamzap Buenos Aires
Hey, I was about to create a new issue with a MR to be able to set the default direction using the editor language/locale configuration, but I saw this one opened and I thought it was better to create a new branch here since the requirements for the project I'm working on are quite similar to this issue description.
For sites using english backed but rtl languages for the frontend (in my case that's Arabic) is important to keep the ckeditor and drupal pages in english (thus, ltr direction), but to be able to set the default content direction to rtl.
When we used the ckeditor4 BiDi plugin, we were able to do this using the ckeditor4 config
contentsLangDirection
and passing that in a drupal hook like:/** * Implements hook_editor_js_settings_alter. */ function module_name_editor_js_settings_alter(array &$settings) { foreach ($settings['editor']['formats'] as $name => $value) { $settings['editor']['formats'][$name]['editorSettings']['contentsLangDirection'] = 'rtl'; } }
If we look at the ckeditor migration docs, we can do the same for cke5 using
language
configsui
andcontent
so the hook should be modified:/** * Implements hook_editor_js_settings_alter. */ function module_name_editor_js_settings_alter(array &$settings) { foreach ($settings['editor']['formats'] as $name => $value) { $settings['editor']['formats'][$name]['editorSettings']['language'] = [ 'ui' => 'en', 'content' => 'ar' ]; } }
But if we set the default direction/language for the content with that hook, the current implementation of this module latest version doesn't work as expected. As soon as you set a default content lang, the bidi buttons becomes unusable.
Soooo I'm adding here a MR that changes the `isDefault` method to retrieve the default value from the editor locale config. If that config is not set, it will fallback to 'ltr'.
It keeps the previous "logic" that only sets the direction attribute on those elements/paragraphs that do not have the default direction.
In this way if your site content is in arabic, only the non arabic content should have a direction attr, since those will be an exception, sort to say.Attaching here two screen recordings testing the changes in a new D10 test site, with and without the hook.
- 🇮🇱Israel israelshmueli
Hi, @anairamzap , did you tried to apply my patch from #6 ✨ Allow setting direction to either ltr or rtl Active ?
I think it solves the issue since it set the default direction to current page direction.Actually it is few weeks that this patch is active in production in many of departments websites of Bar Ilan University.
Most of these websites are multi language and multi direction (mostly Hebrew/English landuages)My strategy was to change the isDefault function in utils.js in a way that it will take into account the value of the dir attribute.
This way it will not depend on the language but on document direction.
So in the patch I have changed ckeditor_bidi/js/ckeditor5_plugins/direction/src/utils.js
Fromexport function isDefault( direction ) { // Right now only LTR is supported so the 'ltr' value is always the default one. return direction === 'ltr'; }
Into
export function isDefault(direction) { // Get the computed direction of the root HTML element or default it to ltr. // We do not rely on <html> dir attribute since in rare cases it may not exist. const rootHtmlDirection = window.getComputedStyle(document.documentElement).direction || 'ltr'; return direction === rootHtmlDirection; }
Please let me know what do you think and if it works for you.
-
israelshmueli →
committed c5402793 on 5.0.x
Issue #3413674: Dynamic set default direction based on current document...
-
israelshmueli →
committed c5402793 on 5.0.x
- 🇮🇱Israel israelshmueli
It was fixed in release 5.1.0 by applying the #6 patch
This issue is not fixed yet. The problem still persists.
Please read the issue description:This module should have two buttons:
One button to toggle the [dir="rtl"] attribute
And another to toggle the [dir="ltr"]We should be able to choose the value of dir attribute, regardless the current page direction.
(The current page direction in the edit form, is not important, but the editor's opinion and will are much more important. The person who uses the editor, should always have an option to choose between rtl, ltr, and none)(similar to what was available in Ckeditor 4)
- 🇦🇷Argentina anairamzap Buenos Aires
@israelshmueli I saw and tried your patch at #3413674-6: Allow setting direction to either ltr or rtl → but that will not work as expected in projects that use different languages for the backend (drupal UI) and the frontend (content).
For example, sites using english (or any other LTR language) for Drupal UI/backend, while the content of the site is in Arabic (or any other RTL direction language). That's why in this kind of projects we keep using the
hook_editor_js_settings_alter
that allows us to differentiate the UI and the content languages.As in the example I pasted in my above comment, the
ui
is set to english, but thecontent
is set to arabic. Using the new config provided by cke5 https://ckeditor.com/docs/ckeditor5/latest/getting-started/setup/ui-lang...That's why I thought it was best to use the approach in the MR #3413674-8: Allow setting direction to either ltr or rtl → , modifying the
isDefault()
method to get the default value from the language content settings of cke5 itself, and not from the backend html direction, that could be different from the content language.I think this approach would make the module to behave more like it did in previous versions (for cke4). So, would you re-consider adding this approach in a release instead of the source html direction that you committed to 5.1?
Thanks,
m
- 🇮🇱Israel israelshmueli
OK @hejazee, I think I finally succeeded in understanding and reproducing the problem you pointed out.
I did not experience it until I manually added dir="ltr" to
<p>
tag while editing on the admin page that is on the English side of the website. Same behaviour exists on the RTL side of the website (Hebrew), while somehow a dir="rtl" exists in the markup even though it is not needed since the whole page direction is already RTL.I am going to reopen this issue and will try to find how to solve it.
- 🇮🇱Israel israelshmueli
Yes @anairamzap, It does make much more sense to rely on locale.contentLanguageDirection
Now that I have realized that current issue original intention is related to different problem than default direction I guess it is better to create new issue for an improved way to set the default direction. - 🇦🇷Argentina anairamzap Buenos Aires
ok, great. Thanks!
Did you tried the changes in https://git.drupalcode.org/project/ckeditor_bidi/-/merge_requests/16 ?
We are using this since a couple of months now and it seems to be OK. Please ignore the page direction, content language, or any similar settings.
The only correct approach is to allow the editor to choose between "rtl", "ltr", or an empty value ("").There are various scenarios where we need to explicitly set the direction to "rtl" even when the entire page is already in RTL mode.
In some cases, we may need to switch directions multiple times within a hierarchical structure.
For example, consider the following code:<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title> </head> <body> <p>some text</p> <p dir="rtl"> یک متن به زبان فارسی با یک کلمه <span dir="ltr">C++</span> </p> </body> </html>
- 🇦🇷Argentina anairamzap Buenos Aires
@hejazee using the
contentLanguageDirection
on cke5 covers those cases since you would set it to the direction that the site content uses, in your example that would be LTR (the dir attr on the body tag).The direction for each paragraph (when not stated) will be inherited from the parent (in this case, the body). This simplifies the html. I can't think of any scenario where adding an explicit direction to a paragraph that matches a parent tag would be necessary.
Also, if I remember correctly, this was the same behaviour that this module had in its version for cke4 (where you could set the default content direction using the
contentsLangDirection
config for the editor). - 🇮🇱Israel israelshmueli
@hejazee, Thank you for the code example, the C++ string inside RTL paragraph demonstrate very well the need to be able to place a dir attribute also to inline element like span and not only to block element like paragraph.
Our plugin did not supported that valuable feature in the past (CKE4) and ufortunatly do not support it also in current version (CKE5).The text part of the html code snippet you've provided could not be crated by CKEditor since it contains dri attribute on inline element like span.
<p>some text</p> <p dir="rtl"> <!-- Swith to RTL --> یک متن به زبان فارسی با یک کلمه <span dir="ltr">C++</span> <!-- Switch back to LTR within an RTL section --> ادامه متن </p>
Your snippet demontrates the use case or need to support proper handling of a dir attribute that did not created via editor interface but pasted from external source like MS Word, website page etc.
- 🇮🇱Israel israelshmueli
@anairamzap, There is a need to support nesting block elements that originated from pasted HTML. For example , pasted markup may contain a paragraph element with a dir="ltr" inside div with dir=rtl that is nested inside another element, for example a list item with dir=ltr.
Your solution of getting the default direction from contentLanguageDirection is much better than mine that relies on the dir of the document root
<HTML>
element, but maybe we need to rely not on contentLanguageDirection but on the caculated direction of the closest parent block level element. In such case the direction of contentLanguageDirection may provide an initial parent direction as a starting point to the whole editing area.What do you think?
-
israelshmueli →
committed 3fd0917b on 5.0.x authored by
anairamzap →
Resolve #3413674 "Get default direction from editor locale"
-
israelshmueli →
committed 3fd0917b on 5.0.x authored by
anairamzap →
- 🇮🇱Israel israelshmueli
@anairamzap I have merged your MR into 5.1.1, current stable release.
@hejazee this release still not removes the dir attribute when it has, initially, same direction as that of the edidor. So I keep the status of this issue as "needs work".Please note that for setting direction of an inline element to be the oposite direction of its parent block level element you can rely on CKEditor's Language plugin.
The Language plugin applies only to inline elements like span while our BiDi plugin applies only to block elements like paragraphs. Why don't you simply allow the editor to manually choose between LTR, RTL, and None ?
Hello,
We are using your ckeditor bidi version 5.1.1 in SOGo Open Source Webmail (https://www.sogo.nu/). SOGo used ckeditor5 as html editor for sending mail. In the current version of your ckeditor bidi you get the current language direction from the ckeditor's itself. Example when the language of the ckeditor is RTL language like Arabic or Hebrew you point the direction to right without to add the (dir="rtl") on the block. But on the view or read of the email content the direction will point to left not to right. How to force to add the direction on the block when the language is right to left language like Arabic or Hebrew. Please look at the below images:
Thank you
Hello,
We are using your ckeditor bidi 5.1.1 in SOGo Open Source Webmail as editor for sending emails (https://www.sogo.nu/).
In current version your are get the current language direction from the ckeditor itself without adding the direction in the block "
" but the problem in RTL language like Arabic and Hebrew in SOGo webmail other mail client when read and view the email the direction is from left to right like the attached images. Please how to force add the direction in the block (dir="rtl") when the language is TL language like Arabic and Hebrew.
[url=https://postimg.cc/tZbrgTz8][img]https://i.postimg.cc/tZbrgTz8/CK1.png[/...
[url=https://postimg.cc/S2GgYhTR][img]https://i.postimg.cc/S2GgYhTR/CK2.png[/...
[url=https://postimg.cc/y3YvFbtP][img]https://i.postimg.cc/y3YvFbtP/CK3.png[/...Thank you