Proposal for fixing mirroring issues in Jupyter Notebook

[samarsultan]

Jupyter Notebook

Arabic Data Handling

Overview

Mirroring is essential in case the application interface is translated to any language with a Bidirectional script (e.g. Arabic, Hebrew). The Arabic and Hebrew script natural Global Orientation is from right-to-left, hence, the native speakers of these languages expect to see the GUI layout mirrored so that the whole GUI can be read from right-to left as well. This includes viewing menu buttons on the right, the navigation tree on the right, and indentation to the left. GUI mirroring is necessary for any application which has GUIs meant to be translated to a language based on bidi (i.e. Bidirectional) scripts such as Arabic and Hebrew.

High-level Design

Whenever the Arabic or Hebrew translation is loaded, mirroring of the UI will occur, this may depend on web browser setting or UI language setting.

Preferences

No special preference needed for mirroring

Terminology and Acronyms

• LTR: Left to Right
• RTL: Right to Left
• GUI Mirroring: Change the Graphical User Interface directionality from a Left to Right orientation to a Right to Left orientation. (The effect is a horizontal position swapping of the GUI elements)

Mirroring Issues

In this section, we highlight mirroring issues found when enforcing right directionality (RTL) on Jupyter Notebook.

1- Main Page :

Comparing the below two images, it is apparent that mirroring issues with the editor. The following is a list of issues found:
• Header logo should be on the right.
• Tabbed items should be on the right (menu tabs)
• Toolbar items should be swapped

Figure:1 Main Page in RTL Mode

Figure:2 Main Page in LTR Mode

2- Dropdown Menu:

• Menu items should be aligned right.
• Tree-selector buttons should be swapped.
The following images will highlight these issues.

Figure:3 Dropdown Menu in RTL mode

Figure:4 Dropdown Menu in LTR mode

3- Dialogues:

Dialogues had several mirroring issues:
• Close button should be placed on the left.
• Action buttons should be placed on the left.

The following images will highlight these issues.

Figure 5: Dialogues in RTL mode

Figure 6: Dialogues in LTR mode

4- Notebooks:

It has several mirroring issue:
• Code editor: missing parts in the line editor.
• Dropdown menu & sub menus should be on the right.
• Menu bar blocks should be swapped.
The following images will highlight these issues.

Figure 7: Notebook in RTL mode.

Figure 8: Notebook in LTR mode.

Low Level Design

In this section, the detailed design proposed will be explained.

Document Direction

Add an attribute named ‘dir’ with value ‘rtl’ to an element, and all elements underneath will be
rendered right-to-left. For the sake of simplicity, let us assume we put this attribute on the body
element.

Code 1:
by creating a function to check the ui language & change the dir attribute if it's RTL language on the body in a separate script tag inside main.js

CSS Style

The browser doesn’t render right-to-left perfectly, and a lot of the remaining issues can be solved using CSS. For this, we will use “CSS Overriding” mirroring approach to fix the CSS classes. We will use CSS attributes to enforce the change in the CSS attributes.
We will update the CSS files by overriding them with the “dir” attribute and update the properties as
well in the same style sheet that contains the original style (LTR-mode) .

Code 2:
by overriding these styles in:

• tree.less :

---

---

• page.less :

---

Results

The screenshot shows the results of applying the design proposed in this report.

[rgbkrk]

Thanks for raising this up, we should definitely support RTL more easily.

[Carreau]

We should look into that directly for Jupyterlab. cc @ellisonbg @jasongrout

[samarsultan]

Thanks for your prompt reply, I'm from Arabic Competence and Globalization Center Team at IBM Egypt. Our team is supposed to support Bidi - Features like "GUI Mirroring " as described above .

This Ticket is to describe the design approach ,So we need an approval before proceeding to the development phase.

Thanks !

[jasongrout]

I've opened up jupyterlab/jupyterlab#1163 in JupyterLab (the next generation notebook) to point to this issue.

[rgbkrk]

@samarsultan approval from us or at IBM?

[samarsultan]

@rgbkrk , from your side .

[rgbkrk]

Your approach looks good. We won't be able to judge it much until there's a pull request. I think you should for it and find out how feasible it is in the current notebook.

[Carreau]

Thanks @samarsultan a lot for submitting #1860, we'll be happy to move forward on it.

Before you spend too much time on it we want to warn you that nowadays most of the effort is on jupyterlab which should replace the current notebook at some point in time. Handwaving we would like jupyterlab to be the default UI in a year or so, and progressively transition to the current notebook being an extension that we will slowly sunset.

Depending on your timescale and your short/long term plans, you might want to also have a look at the current state of JupyterLab. If you have any question we would be happy to clarify that, whether in public discussion (we need to do a better job at this), or even in a private conversation if you need to ask about specific things.

[samarsultan]

@Carreau ,Ok .. I need to know how bidi-work will be migrated to Jupyterlab if the mirroing support will be for the Notebook . Are you going to change the core libraries ? And Would you mind to recommend whether to continue for the Notebook or Jupyterlab as long as the current Notebook will no longer be existed !

[jasongrout]

The bidi work would likely need to be redone in JupyterLab - the css and styling are completely different.

As for working on the notebook vs lab - that depends on how much effort it is likely to take and your timeframe for needing this. If it's not a lot of effort, it'd be great to have it in both the notebook and lab. If you need it right away, the notebook is definitely the more stable/polished project. However, if it's a lot of effort, and you don't need it right away, I'd suggest working on Lab.

[tomerm]

@jasongrout @Carreau @rgbkrk . My name is Tomer. I am development manager of IBM team called Bidi Development Lab. We are working together with @samarsultan team on addressing various RTL languages requirements. Can you please share which component is used as rich text editor in JupyterLab ? In JupyterNotebook CodeMirror editor (https://codemirror.net/) is used. My team is working on contribution of missing support for RTL languages to this editor. In case JupyterLab is going to be based on some other editor I would be very much interested to know which one. This way we can assess and contribute missing functionality into the right component. Many thanks for your help and guidance.

[Carreau]

Hi @tomerm,

Currently most of JupyterLab is based on CodeMirror, though there is nothing preventing multiple panel to use different editors. The following issue track the progress for making editor an abstract component and having the ability to replace CodeMirror if desired (Monaco for example, was mentioned). A lot of in person discussion have been done yesterday as most of the team is currently in San Luis Obispo for a bi-yearly meeting, so I would expect some update soon.

Does that help ?

[tomerm]

@Carreau thanks a lot for your quick reply and information sharing. This helps a lot. Future version of Jupyter (now called JupyterLab) was known for quite a while but there was never clear understanding about time line (even on a very high level it was not clear if new product will be released one year from now or 5 years from now etc..). That is why efforts are currently invested in technology which is de-facto used by customers (Jupyter Notebook - CodeMirror). But we should always carefully review the roadmap and technological dependencies to make right choices down this path.

[Carreau]

Thanks @tomerm,

The exact timeline is still hard to project for now, but we are starting to be able to give a rough timeline.
No promise yet, but it should something along:

• if you are planning to deploy jupyterlab and have custom extensions or want to make relatively involved proposal in the design/api ; Nowish is the right time.
• It is not ready for production and day-to-day use. If you want to you can, there is still some rough edges for a few workflow.
• If you can use it a couple of hours each week to see progress and report back on what is annoying that would be great. (We ourself become blind to some usability as we might work too close to the code)
• A beta / version 0.9 should be release late 2016, early 2017.
• We want a stable 1.0 by mid 2017
• Start to sunset the current notebook shortly after if the transition goes well.

All of the above schedule depends (among other things) about community involvement and time the can be injected into jupyterlab.

@ellisonbg and @jasongrout might have a more detail schedule or correct me.

[gnestor]

I'm going to mark this as backlog for now because we are planning on releasing notebook 5.1 next week. Thanks for your efforts this!