Some pages doesn't have any visual effect on switching the page direction, and this menu item doesn't display its state too. So it looks like it's not working at all. Example: https://bugzilla.wikimedia.org/ The "Switch Page Direction" item in both View (main menu) and context menu should display a "tick" when it's active.

Sorry, but I don't see any need for "Page Switcher", since here in Israel no one use Hebrew without specifying RTL directly to the page. Even more, I prefer to remove the bidiui extension completly from the browser, and replace it with a more native text direction switcher. MS Windows use the Control-Shift combination for switching between RTL and LTR paragraphs, and I don't think Firefox should behave differently in Windows or any other operating system.

(In reply to comment #0) > Some pages doesn't have any visual effect on switching the page direction, and > this menu item doesn't display its state too. So it looks like it's not > working at all. > > Example: https://bugzilla.wikimedia.org/ > > The "Switch Page Direction" item in both View (main menu) and context menu > should display a "tick" when it's active. Actually I don't think we should put a check mark next to this menu item. We should change its text completely to either "Switch Page Direction to Right-to-Left" and "Switch Page Direction to Left-to-Right" based on the current page direction. CCing Alex to have his input.

(In reply to comment #2) > Actually I don't think we should put a check mark next to this menu item. We > should change its text completely to either "Switch Page Direction to > Right-to-Left" and "Switch Page Direction to Left-to-Right" based on the > current page direction. "Switch page direction to right-to-left" is too long for a context menu so it will make the menu too wider, while "Switch page direction to RTL" say nothing to the average user. I am still don't see any real use for this feature (sorry Mano...). Do you find it useful in your countries?

(In reply to comment #3) > I am still don't see any real use for this feature (sorry Mano...). Do you find > it useful in your countries? I don't personally find it too useful for web pages, but it's pretty useful for text boxes, because many popular sites do not provide Persian localizations now and users may still want to type Persian, so they would need to change the direction of the text box.

(In reply to comment #4) > I don't personally find it too useful for web pages, but it's pretty useful for > text boxes, because many popular sites do not provide Persian localizations now > and users may still want to type Persian, so they would need to change the > direction of the text box. Still, the 'switch text direction' and 'switch page direction' are two different items. The 'switch text direction' is indeed useful, at least until someone will land a better solution, but as for 'switch page direction' I don't think anyone is care about, therefore we can hide it by default.

I think "switch page direction" has no actual usage nowadays, so we can hide it by default. But "switch text direction" is very useful for Persian users at least, because so many popular sites doesn't support the language officially, but has many persian users. About the main subject of the bug, although it was talking about the "page dir", but the problem do exist for "text dir" as well, and IMHO adding a checkbox to the menu item would be the best solution here.

'Switch text direction' (ctrl-shift-x) can be recognized as the text cursor (and entered text, if any) changes place. I don't think there should be menu item changes, as this change will require all translators to understand what RTL mean and how to deal with it. How many of you use the menu item in order to change text direction? I think most of the people are using the keyboard command and not the context menu item, so browser.bidi.ui can be disabled by default to every locale.

(In reply to comment #7) > 'Switch text direction' (ctrl-shift-x) can be recognized as the text cursor > (and entered text, if any) changes place. I don't think there should be menu > item changes, as this change will require all translators to understand what > RTL mean and how to deal with it. I agree. > How many of you use the menu item in order to change text direction? I think > most of the people are using the keyboard command and not the context menu I have not yet met any person who knows about Ctrl+Shift+X before I tell them it exists. It is simply impossible for a user to discover this shortcut from the UI. > item, so browser.bidi.ui can be disabled by default to every locale. It is disabled by default. (In reply to comment #6) > I think "switch page direction" has no actual usage nowadays, so we can hide it > by default. We are hiding it by default. We only show it in browser.bidi.ui is set to true, or the current system locale is an RTL one.

>Actually I don't think we should put a check mark next to this menu item. We >should change its text completely to either "Switch Page Direction to >Right-to-Left" and "Switch Page Direction to Left-to-Right" based on the >current page direction. > >CCing Alex to have his input. If I remember correctly different operating systems have slightly different standards for changing the menu name versus using a check or using two radio menu items, when there are ambiguous opposites: ==OS X== A toggled menu item changes between two states each time a user chooses it. There are three types of toggled menu items: *A set of two menu items that are opposite states; for example, Grid On and Grid Off. The state currently in effect has a checkmark next to it. If you have room in your menu, it’s a good idea to display both items (rather than changing the name depending on its state) so that there’s less chance of confusion about each item’s effect. *One menu item whose name changes to reflect the current state; for example, Show Ruler and Hide Ruler. Use this type if your menu doesn’t have room to show both states. Use two verbs that express opposite actions. Make sure the command name is completely unambiguous. For example, Turn Grid On and Turn Grid Off is unambiguous. Choosing the command Use Grid, however, could turn the grid on (it describes what happens as a result of choosing the command) or off (it describes the current state). *A menu item that has a checkmark next to it when it is in effect; for example, a style attribute such as Bold. Don’t use this kind of toggled item to indicate the presence or absence of a feature such as a grid or ruler. It’s unclear whether the checkmark means that the feature is in effect or whether choosing the command turns the feature on. http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGMenus/XHIGMenus.html#//apple_ref/doc/uid/TP30000356-TPXREF121 ==Windows== Use a checkmark to toggle an independent setting on or off. If the selected and cleared states aren't clear and unambiguous opposites, use a set of bullets instead. For more information, see Check boxes. http://msdn.microsoft.com/en-us/library/aa511502.aspx#bullets ==Gnome== * Use a check box menu item only when it is obvious from the label what the set and unset states mean. This usually means that the two states are logical or natural opposites, such as "on" and "off". If this is not the case, use two radio button items instead. * Never change the label of a check box menu item in response to the user selecting the item. http://library.gnome.org/devel/hig-book/stable/menus-design.html.en#menu-item-type-check So basically OS X is the only platform that allows you to change the label in the case of ambiguous opposites (Windows and Gnome both require two items with a radio control). The menu item "Switch page direction" seems more like an action that you take on the page, than the current state of the page, so a checkbox doesn't seem to help. Also, it isn't clear if the name is indicating the current state, or what will happen when you select it. So the unambiguous opposites could potentially be: -Switch Page Direction -Normal Page Direction This is a little more complicated as mentioned in comment #0 since some pages don't have any visual change when the direction is switched. I recommended: -toggle the label on OS X -use two items with a radio control on Windows and Linux Alternatively we could potentially toggle the label on all platforms (breaking conventions), in order to save space.

As I said above - both items are not very necessary and I wish we would solve the ctrl-shift key binding instead of making the context menu larger. 'Switch page' has no any real use, and for cases it has, users prefer to use greasemonkey addon instead, and 'switch direction' should not appear in the context menu at all, similar how we don't allow users to change the typing language from the context menu.

Alex, based on the other comments in this bug, what do you think about keeping/removing the Switch Page Direction and Switch Text Direction menu items? I personally don't think that the latter should be removed, because the equivalent keyboard shortcut has 0 discoverability.

>Alex, based on the other comments in this bug, what do you think about >keeping/removing the Switch Page Direction and Switch Text Direction menu >items? > >I personally don't think that the latter should be removed, because the >equivalent keyboard shortcut has 0 discoverability. If we believe the command is used as much as even our less common menu items (like Page Style or Character Encoding) then I think we should keep it.

This is how Microsoft are handling this feature. A. Both items are displayed and they are using a bullet to indicate the active option. B. The 'Switch page direction' is instead 'Right-to-left document' and 'Left-to-right document'. C. The feature is located inside the Encoding sub menu and not in the View menu itself, which might be less trivial to find, but can users who use it daily can still find it.

Updating to reality: I won't have the time to work on this for the foreseeable future!