L10n:B2G/RTL

Other Valuable References

The tracking bug is bug 906270.

See UX Guidelines at the UX guidelines published on November 5, 2014.

Developer Resources for Writing Bi Directional Enabled Code are on developer.mozilla.org

Product planning/tracking docs at https://wiki.mozilla.org/RTL

Platform

Things related to the Unicode Bidirectional Algorithm, which is implemented in Gecko. By leveraging the existing platforms which conform to the W3C standards we make sure to minimize the risk of running into problems in this category. Bugs that go into this category should block the tracking bug and have [rtl-platform] in their whiteboard: bugzilla query.

UI development

Things related to the code responsible for showing the UI to the user. They are mostly due to a developer hardcoding an LTR layout in the source code, e.g. when specifying the position of an icon in relation to the text label. Ideally, developers would take advantage of the Bidi Algorithm to achieve correct positioning for all languages, but this is sadly not always the case and is source of bugs for us to fix. Bugs that go into this category are the most common ones; they should block the tracking bug and don't need any special whiteboard tags: bugzilla query.

UX design

Last but not least, we're seeing a need in more bidi education for our UX designs. This is particularly interesting in touch interfaces which rely on spatial metaphors and finger gestures, like swiping. Bugs that go into this category should block the tracking bug and have [rtl-design] in their whiteboard: bugzilla query.

Spatial metaphors

• indicating progress:
  • in FTU the progress indicator slides towards the right edge of the screen,
  • in various places, the back button is on the left and the next button is on the right,
  • in Haida, the history of navigation is represented as sheets on a LTR timeline,
  • subpanels slide in from the right edge of the screen
• learn more, expand, start:
  • in FTU, the image inviting user to start the tour is a hand with the index finger pointing right,
  • indicator arrows on dropboxes are always on the right
• number progression:
  • in the Radio FM app, the frequencies increase from left to right
  • in the Calendar app, months are arranged from left to right
• sidebars
  • in the Calendar app, the settings sidebar is always on the left

Finger gestures

• swipe to dismiss notification currently only works from left to right
• [x] and [<] to close should be consistently on one side; right now it depends on the app
• scrollbars are on the left; is this okay for using the right hand's thumb?
  • for instance, for RTL, Android places scrolling indicators on the left, but a quicklook index of each letter on the right for easy thumb access
• currently the swipe to unlock is always to the right,
• checkbox state: off [o ], on [ o] - should this change in RTL?

Performance

Currently each app is responsible for setting the lang and dir attributes on the html element. This happens only after the 'localized' event is emitted, which is usually after the firstPaint event. This results in a jarring experience for the RTL users, as the entire content jumps from left to right a few hundred milliseconds after the launch of the app.

• The refactor of l10n.js (bug 914414) will fix this by setting dir and lang early on during the launch.

Competitive analysis

Other mobile operating systems have recently improved their support for RTL languages.

Android

Starting with version 4.2 (25% penetration as of Jan 8, 2014; source), Android has native support for RTL layout: http://android-developers.blogspot.com/2013/03/native-rtl-support-in-android-42.html. Things to note:

• checkbox states: reversed (ON is on the left)
• scrollbars: on the left
• scrollable letter index in long lists: on the right
• ordering of app icons in the apps menu: reversed
• time and notification icons: reversed
• apps vs widgets: reversed
• back arrow (software) points to the right
• timelines: reversed
• calendar: next week is to the right; months are displayed vertically
• progress bars in the browser: not reversed
• sidebars, subpanels: reversed
• swipe to unlock: you can swipe in any direction, but the icon indicating unlocking is not reversed

Prior versions don't support RTL layout at all. The text is rendered RTL, but the layout remains LTR.

iOS

Tested on iPad with iOS 7

• checkbox states: NOT reversed: off [o ], on [ o]
• scrollbars: NOT reversed
• ordering of workspaces on the homescreen: NOT reversed
• time and icons in the notification bar: NOT reversed
• back arrow: NOT reversed
• calendar: week view LTR, month view vertical
• progression: NOT reversed
• sidebars; subpanels: NOT reversed
• swipe to unlock: NOT reversed
• labels: text always aligned to the left
  • in many places text is aligned to the left
• dialogs: 'confirm' button always on the right
• text inputs: reversed, exception: Safari
• timer: X minutes Y seconds, always in that order, only the words 'minutes' and 'seconds' are RTL

Windows Phone 8

• changing the language requires restart
• checkbox states:reversed
• setting icons (e.g. wifi): not reversed
• scrollbars: on the left; IE is an exception (content scrollbar on the right)
• ordering of app icons in the apps menu: vertical
• time and icons on the notification bar: reversed
• back arrow: hardware, not reversed
• timelines: reversed
• month switching in the calendar: vertical
• progress bars: reversed
• sidebars; subpanels: reversed
• swipe to unlock: vertical