Gmail BiDi Enabling - A Case Study from Two Perspectives

Gmail BiDi Enabling - A Case Study from
Two Perspectives

Shoshannah Forbes, Shanjian Li

1

Agenda

‣A quick recap of bidi
‣The challenge
‣The Goal
‣Layout issues
‣Truncation issues
‣Element order
‣Brackets
‣Bidirectional text editing
‣ Geresh & Gershayim

2

2

A quick recap of bidi

Short for “bidirectional”- text flows both from Right to Left (RTL)
and Left to Right (LTR)

3
I assume that the audience here knows what bidi is, however, to make sure we are all on the same page, a quick recap is needed

Types of directionality for characters

‣ Strong characters
‣ Weak characters
‣ Neutral characters

4

4
Strong characters- they know their directionality
Weak characters- determine their directionality according to their proximity to other
characters with strong directionality Neutral characters- determine their directionality
from either the surrounding strong text or the embedding level

The challenge

‣Bidi : one of the most messy problems in I18n.
‣Many bidi issues not solved cleanly in the industry yet.
‣Browser Bidi supports are buggy, and each browser behaves
differently.

‣Direction change impacts whole layout, brings up many layout
issues.

‣GMail is a complicated, dynamic AJAX applications with restriction of
browser capability.
Mail display, composing etc, and those are not static pages.

5

5

The Goal

5
6

6
Final goal- fully mirrored UI, mixing RTL and LTR elements and text

The goal- a closer look

7

7
Users tend to have mail both in English and in local language, so we need to be able to
handle both (for example, email from international sits like facebook or last.fm).
Although element order is RTL, many small details are LTR.
Note the mixed language labels (and the numbers next to them), bi-directional sender
names, and subject lines/snippets.
Note how although the order of the elements (sender, unread count, label, subject,
snippet) is rtl, each element can be either rtl or ltr.

Just plain flipping isn’t enough

8

8
You would think that setting dir=rtl to the body or html element will do the job. But look
what it caused here...

From an early build

9

9

More complex than seen at first glance

‣ <body dir=”rtl”> is good, but hardly enough
‣BiDi is about text directionality, right? But HTML layout raised more
difficult issues.

‣LTR elements are unavoidable, even with Hebrew/Arabic only
emails.
Because it is BiDi!

‣ Typical BiDi users use a mix of English and Hebrew/Arabic emails.

10

10

Layout issues

Look out for elements near the edge of the screen, esp. when resizing

11

11
Mirroring the UI can be really tricky and have a TON of bugs. psudo-rtl can help,
although it was not used for this project.

Window made larger

12

12
The window was made larger, but the menu was still in the old location, covering the
text and buttons. refresh would ﬁx the display, but would also reload the full inbox (the
wonders of ajax)

Window made smaller

13

13
Same page- window made smaller, menu jumped off the screen (notice the scroll bars)

Contact suggestion

14

14
The suggestion to auto-complete the contact ﬁred nicely on a Hebrew key press, but the
actual completion is way too far away (although properly RTL)

Snippets

15

15
As mentioned before, although the general order is RTL, each element needs to have it’s
own directionality, as can be seen here (broken).

Things to look out for

‣Menus
‣Fixed width elements
‣Absolutely positioned elements
‣“Auto complete” /Suggest
‣Resizing
‣Working in lower screen resolution

16

16
All of these things tend to break in RTL UI, but even more when windows get re-sized
and locations need to be re-calculated by the browser.

How to fix?

‣Change whole html page's direction to 'rtl‘
‣ Apply “dir” on “html” tag or “body” tag, like “<body dir=rtl>”.
‣ Not to use CSS styling to control directionality, use markup.
-- ”Internationalization Best Practices: Handling Right-to-left Scripts in XHTML and HTML Content” by W3C

‣Rationale:
‣ Directionality is about document, not representation.
‣ CSS is not reliable, could be turned off or unavailable.
‣ Conforming user agent may ignore this CSS bidi properties.

‣This is considered as an exception. We strongly suggest heavy use
of CSS in BiDi enabling. See next page…

17

17
Also, try to have clear style sheets. Why oh why didn’t begin and end get into css 3?

How to fix?

‣CSS offer a good separation of representation data.
‣Proper use of CSS is much easier to manage.
‣W3C best practice suggest separate CSS.
‣We also want a single CSS source.
‣ I18n and L10n will always be secondary, and will be ignored if things existing in
separate source tree.

‣CSS swapping can be done on server side / client side.
‣ Swap 'left' and 'right'
‣ Swap paddings, margins, border-width, border-style …
‣ Some CSS property might want to stay. Better organize them into 2 sections,
section need to be swapped and section need not.

18

18

Cut off location

20

20
In Hebrew and Arabic, the most important information is at the right, so you need to
make sure not to cut from the right. This is the display under IE

Cut off

21

21
And the same under FF- FF cut the beginning of the
text.

Cut off

‣Make sure to cut off from the left.
‣One example: Firefox table cutoff bug
<table><tbody>
<tr><td dir="rtl" nowrap="nowrap">
<div style="width: 150px; overflow: hidden;">
first second third</div></td>
<td><- Should be cut off on the left.</td></tr>
</tbody></table>

‣Solution: Wrap a fixed width div element
<table><tbody>
<tr><td dir="rtl" nowrap="nowrap">
<div style="width: 150px; overflow: hidden;">
<div style=“wdith:600px”; align=right>
first second third
</div> </div></td>
<td><- Should be cut off on the left.</td></tr>
</tbody></table>

22

22
Work around for table cut off bug in Firefox we saw- put a ﬁxed width div inside. the
right aligned element made the browser chop off from the left.
Beware: IE 6 has a bug, causing the layout to be garbled in certain cases when there is a
div inside a cell. (fun!)

Element order

23

23
x out of y are tricky in Hebrew- each element is ltr, but the order of them is rtl. Also,
notice here that we have a run of weak and neutral characters. Need to use <span> and
&rlm; in places

How to fix?

‣Element order is not always consistent with layout order, because
layout is “Bidi”.

‣Raise embed level:
<span dir=”rtl”>blah blah</span>

‣ Insert invisible bidi mark
&rlm; / &lrm;

‣Control a element group’s internal and extern directionality.
Use embedded span tag.
<span dir=rtl> <span dir=ltr> some text! </span></span>

‣Beware of browser bugs!
If you omit the space between first 2 span tag, you will have a
surprise.

24

24
Better to use span, but you can’t always- in those cases use the right entity.
Mozilla has a weird span tag merge "functionality". If you don't separate SPAN tags with
space and newline, thing won't happen the way you want.

Bracket issues

Weak characters? I think not!

()
[]
<>

25

25

Conversation display

26

26
you can play “ﬁnd the bugs” in this picture. But the interest is the brackets (ok on top,
broken on bottom)

Contact display

27

27
The contact has set his details to have both Hebrew and English- which confuses the
display of the brackets around the email address.

28

28
Notice the brackets around the English
ﬁlters

Brackets and arrows

29

29
Keep and eye open for arrows pointing at stuff, back/forward icons, and disclosure
triangles

Brackets

Not as weak as you might think...

In unicode bidi layout algorithm, bracket’s directionality is
determined by its context.

But, each bracket is considered separately.

Solution: span tag or &lrm;/&rlm;
Javascript regex is a efficient way to deal with this issue.
str.replace(/(([^)]*))|([[^]]*])|({[^}]*})|(<[^&]*>)/g,'<span dir="rtl">$&</span>');

The span tag works more reliably in html context, but lrm/rlm is
more compact.

31

31
In applications, and esp. in email, brackets are used for more that originally thought of,
and since they are weak, things tend to break. A few examples...

Things to look out for

‣ Arrows pointing to stuff
‣ Next / Previous icons
‣ Disclosure triangles
‣ Copyright symbol
‣ Brackets at element boundary

32

32

How to fix

Have finer control where the element should go

With the span trick, you can control a group of text’s external
directionality.

From: [label message] (16)

33

33
(Consistency sometimes is more important.) "XXX (12)" and "abc (12)" will be layed out as
"(12) XXX" and "abc (12)", that's inconsistent for column display. Other things may also
need to be "guarded". Fraction character " 1⁄4", "1⁄2", "3⁄4" are examples.

How to fix

To:

<span dir=rtl> [label message] </span> <span dir=rtl> (16) <span>

34

34
(Consistency sometimes is more important.) "XXX (12)" and "abc (12)" will be layed out as
"(12) XXX" and "abc (12)", that's inconsistent for column display. Other things may also
need to be "guarded". Fraction character " 1⁄4", "1⁄2", "3⁄4" are examples.

Bidirectional text editing

For more than a few words of text, users want control!

35

35
The moment the users are going to enter more than a few words, they would like to be
able to control the directionality.
This is done by giving directionality control buttons, similar to what is seen in desktop
applications.

Bidirectional toolbar

36

36
RTL and LTR toolbars, with bidirectional controls.
Things to note:
* The current directionality and alignment are highlighted (they are related, but
separate).
* Some icons change their function/appearance according to directionality- indent,
outdent, quote, lists.

Mixing both in the same email

37

37
This is much harder than it seems, and there are many edge cases. Since we only do
“block level” inline control can’t be done.
This is the old 80/20 rule.

How it is done

‣Rich text editing is a complicated issue.
‣IE has the directionality switch functionality in design mode if you
could accept its behavior.

‣In Firefox, we manipulate DOM node.
‣Since Firefox uses <br> to separate paragraphs, you might need to
create new block element to apply directionality.

‣List needs to be treated as a whole.
‣Toolbar need to reflect directionality in current selection, and change
appearance accordingly.

38

38

How it is done: more on DOM

‣Directionality detection and switch is done on block level.
‣Block level elements need to be created when it is not there yet.
‣Block level elements could be removed when it is not needed.
‣Based on selection range, we need to grab all the block element
involved.

‣Though directionality and alignment are separate issues, user often
perceives them as a whole.

39

39

Geresh and Gershayim

HEBREW PUNCTUATION GERESH- 05F3
HEBREW PUNCTUATION GERSHAYIM- 05F4

40

40

Geresh Examples

George Bush
Winston Churchill
Jean-Jacques Rousseau

Doc. Dolittlee
Prof. Kahneman

5th of Iyar
41

41

Gershayim Examples

USA
Attorney
LTD
Accountant
UN
Katz (common sure-name)
17th of Sivan,
5,738 42

42

One possible fix

Replace latin characters with proper Hebrew ones

function I18n_QuoteReplacementInHebrew(str) {
for (var i = 1; i < str.length; i++ ) {
if (str.charAt(i) == '"') {
if (str.charAt(i-1) > 'u0590' && str.charAt(i-1) < 'u05f3') {
str = str.substring(0, i) + 'u05f4' + str.substring(i+1);
}
} else if (str.charAt(i) == "'") {
if (str.charAt(i-1) > 'u0590' && str.charAt(i-1) < 'u05f3') {
str = str.substring(0, i) + 'u05f3' + str.substring(i+1);
}
}
}
return str;
}

43

43

Summary

• Bidi has 2 directions, not just RTL.

• Apply “dir=rtl” to “html” or “body” tag.

• Fix page layout issues. If possible, do it through CSS.

• Fix text layout problems.

• Fix misc stuff, like image, popup dialog box, etc.

• Be careful about differences in browsers and each
browser’s specific deficiency.

44

44
RTL is basically a presentation stuff, CSS can help to greatly reduce the number of
issues.
A bunch of solutions are available in JS code now, and can easily be ported to other
places.
Otherwise, try to avoid explicit alignment.
Many many bugs- don’t be afraid.

Gmail BiDi Enabling - A Case Study from Two Perspectives

Recommended

Recommended

More Related Content

Similar to Gmail BiDi Enabling - A Case Study from Two Perspectives

Similar to Gmail BiDi Enabling - A Case Study from Two Perspectives (20)

Recently uploaded

Recently uploaded (20)

Gmail BiDi Enabling - A Case Study from Two Perspectives