Alert messages in RTL mode are not mirrored

[edithk]

(tested on IE11 and FF)

Impact on all languages: text is not translated in the message box (i.e. text on the button) unless web browser itself is translated to that language.

Impact on bidi languages: message boxes are not mirrored / flipped unless web browser itself is translated to Arabic / Hebrew.

This behavior has a pretty serious impact on user experience, since there are around 18 contexts in which alert message is called.

We suggest to contribute a solution by developing a general modal message box in pure JS which will address all the needs currently addressed by alert dialog.

Do you agree that this issue should be fixed? If so, do you accept the suggested approach to the solution?

Thank you

[edithk]

alert dialog in RTL mode

[Piotrek Koszuliński]

Impact on all languages: text is not translated in the message box (i.e. text on the button) unless web browser itself is translated to that language.

Impact on bidi languages: message boxes are not mirrored / flipped unless web browser itself is translated to Arabic / Hebrew.

I have serious doubts if this is a valid ticket. If the OS language is set to English, then it's neither CKEditor's nor browser's fault that English alert is displayed. Simply, the OS wasn't configured for the user of it.

CKEditor as well as the "Web" in general work inside a browser which is inside an OS. The content of the web has no control of browser's or OS's languages and both environments are constantly visible to the user. The same problem will happen when user presses CTRL+P to print or uses the menu bar - it all will be in English.

However, I may not understand this case properly, so please correct me if I'm wrong.

[Piotrek Koszuliński]

One more thing – while I don't agree with the bug report, I do not like alerts as well. Their UI is different from the apps that launches them (CKEditor in this case) and this in general is not good for UX. So in general, replacing alerts with some JS modals would be nice.

However, adding accessible, BIDI-aware, and generally robust JS modals will require additional kilobytes of code and pretty a lot of work. That's why the idea isn't that tempting. In my opinion alert's might not be perfect, but at least they are super simple.

[Tomer Mahlin]

Language in which CKEditor appears does not depend on language to which OS is translated or / and language to which web browser is translated. If you go to ​http://ckeditor.com/demo#localization you will see that you can control the language of CKEditor UI completely independent from languages to which OS / web browser are translated.

This is also true for web software into which CKEditor is embedded. This software can be translated to multiple languages. In which specific language it appears to the end user does not depend on the language to which OS is translated or web browser is translated. Usually end user specifies the desirable language completely independent from OS / web browser and based on this preference, web UI appears in the language user selected. Please look at:

1. ​http://edition.cnn.com/ you will see "International Edition" menu at the top using which you can switch the language of CNN web site from English to Arabic.
2. ​http://www.bankhapoalim.com/ you will see links at the top right side pressing on which will switch bank web UI language from English to Russian or Spanish etc.

The fact that web browsers don't allow language specification when alert is called in JS, (neither they take browser local preference language specification into account) is a serious limitation which very negatively affects user experience.

My team (Bidi development lab) is responsible for providing Bidi support in IBM products and has long history of contributing code / functionality to CKEditor (@Edith who opened this ticket can provide more links to relevant tickets).

We are willing to provide a POC solution addressing this issue. It will be up to you to review and decide whether it is acceptable. Developing this solution is not that much work.

Can we proceed with POC solution ?

[Jakub Ś]

Language in which CKEditor appears does not depend on language to which OS is translated or / and language to which web browser is translated.

True but when CKEditor uses browser native features that it depends on browser language in that particular area.

you will see "International Edition" menu at the top using which you can switch the language of CNN web site from English to Arabic.

Ok, but what you are showing us is software being translated to appropriate locale. If that application was using native modal dialogs the result would be the same.

This behavior has a pretty serious impact on user experience, since there are around 18 contexts in which alert message is called.

I think you are exaggerating here a bit. Let's assume that your native language is Arabic. In 99% of cases you will have OS and browser set to Arabic. Try answering yourself two questions:

1. How many Arabs will have English set for OS and Browser but Arabic for application in browser? The fact is that such case is very rare.
2. How bad is that in terms of UX for such users? Since they use English for OS they most likely know it and are accustomed to it. They know it is LTR language and are quite familiar with it.

---

To summarize - I agree that it can be considered bad UX however the impact is very small because of what I have written above.
You are welcome to submit a pull request. We will of course review it. Please note that besides UX it is important that the code is small and provides same functionality as alert boxes. This is the main reason we have selected them.

---

I don't want to invalide or confirm this ticket. Perhaps the pull request will give answer what to do. Even if this pull request will not be accepted, perhaps it could be turned into custom plugin?

[Piotrek Koszuliński]

The fact that web browsers don't allow language specification when alert is called in JS, (neither they take browser local preference language specification into account) is a serious limitation which very negatively affects user experience.

I understand. I didn't considered it as such important aspect, but I'm definitely biased working in fully LTR environment and with most of the software configured to use English. Therefore, your feedback is very valuable.

We are willing to provide a POC solution addressing this issue. It will be up to you to review and decide whether it is acceptable. Developing this solution is not that much work.

Can we proceed with POC solution ?

Yes, that would be perfect. We already have a successful history of collaboration with @Edith, so I'm really looking forward to your PoC.

PS. I think that you want to address the whole #5291, so we could move this discussion there. If I'm correct, I'll close this ticket as DUP of #5291.

[Piotrek Koszuliński]

PPS. I think that @jswiderski is playing devil's advocate role very well and in many points I must agree with him. It would be good to have an understanding if this problem is realistic. I mean – if there are really many users having the OS set to some other language than the website/editor. Of course, there are definitely some, but adding a full modal dialogs feature just to improve UX for a small percentage of users might not be reasonable.

This also made me think that the solution to this problem should be optional. I mean – implemented by an optional plugin. We can do similar thing that we made with notifications:

1. We can add editor.showAlert() method which by default would use the native alert() function.
2. We can switch all places in which native alert() is used to use editor.showAlert().
3. Finally, an alert plugin can override the editor.showAlert() method to display a custom modal dialog.

This will allow developers to load the alert plugin when they want to improve the UX of their applications. It means that this ticket could be split into two separate steps:

1. Introducing `editor.showAlert() and updating code to use it.
2. Introducing the plugin.

[Tomer Mahlin]

It is beyond any doubt that alert problem is not unique to CKEditor context. It will happen in any web applications in which alerts are used. However, saying that people by now are used to it and thus it should not be fixed is not justified.

It is beyond any doubt that 90 % of PC users (at least in Israel) are using English OS. They obviously author and view content in Hebrew / Arabic. However, OS in overwhelming majority of cases remains in English language.

Making this feature optional is obviously OK (in many technologies Bidi support is implemented as optional feature).

We will continue code submission via #5291 as was suggested earlier.

[Jakub Ś]

However, saying that people by now are used to it and thus it should not be fixed is not justified.

I'm sorry but I have not said that it should not be fixed. I've said that this can be considered bad UX however impact is small (there may be some % of people using international language like English but most of them will use native one).
Looking at the solution proposed by @Reinmar, I must say that this is the best approach because users will have the ability to choose between simple, fast native alerts and custom alerts. The custom alerts have this advantage that they can have CKEditor UI applied.

We are looking forward for your pull request.

[Tomer Mahlin]

Pull request was submitted by Edith via ​​https://github.com/ckeditor/ckeditor-dev/pull/223 Please see more explanations in #5291

We would appreciate your comments.