Post on 28-Jun-2015
description
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)
3I 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
4
Types of directionality for characters
‣ Strong characters
‣ Weak characters
‣ Neutral characters
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
5
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
6
The Goal
5
6
Final goal- fully mirrored UI, mixing RTL and LTR elements and text
7
The goal- a closer look
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.
8
Just plain flipping isn’t enough
8
You would think that setting dir=rtl to the body or html element will do the job. But look what it caused here...
9
From an early build
9
10
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
11
Layout issues
Look out for elements near the edge of the screen, esp. when resizing
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.
12
Window made larger
12
The window was made larger, but the menu was still in the old location, covering the text and buttons. refresh would fix the display, but would also reload the full inbox (the wonders of ajax)
13
Window made smaller
13
Same page- window made smaller, menu jumped off the screen (notice the scroll bars)
14
Contact suggestion
14
The suggestion to auto-complete the contact fired nicely on a Hebrew key press, but the actual completion is way too far away (although properly RTL)
15
Snippets
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).
16
Things to look out for
‣Menus‣Fixed width elements‣Absolutely positioned elements‣“Auto complete” /Suggest‣Resizing‣Working in lower screen resolution
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.
17
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
Also, try to have clear style sheets. Why oh why didn’t begin and end get into css 3?
18
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
Truncation
19
19
20
Cut off location
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
21
Cut off
21
And the same under FF- FF cut the beginning of the text.
22
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
Work around for table cut off bug in Firefox we saw- put a fixed 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!)
23
Element order
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 ‏ in places
24
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 ‏ / ‎
‣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
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
26
Conversation display
26
you can play “find the bugs” in this picture. But the interest is the brackets (ok on top, broken on bottom)
27
Contact display
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 filters
29
Brackets and arrows
29
Keep and eye open for arrows pointing at stuff, back/forward icons, and disclosure triangles
30
30
31
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 ‎/‏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
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...
32
Things to look out for
‣ Arrows pointing to stuff
‣ Next / Previous icons
‣ Disclosure triangles
‣ Copyright symbol
‣ Brackets at element boundary
32
33
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
(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.
34
How to fix
To:
<span dir=rtl> [label message] </span> <span dir=rtl> (16) <span>
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.
35
Bidirectional text editing
For more than a few words of text, users want control!
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.
36
Bidirectional toolbar
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.
37
Mixing both in the same email
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.
38
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
39
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
Geresh and Gershayim
40
HEBREW PUNCTUATION GERESH- 05F3HEBREW PUNCTUATION GERSHAYIM- 05F4
40
Geresh Examples
41
George Bush
Winston Churchill
Jean-Jacques Rousseau
Doc. Dolittlee
Prof. Kahneman
5th of Iyar
41
Gershayim Examples
42
USA
Attorney
LTD
Accountant
UN
Katz (common sure-name)17th of Sivan, 5,738
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
44
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
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.