Navigator presents the trees for various categories, e.g. Headings, fully in LTR. This, even if the entire document is RTL: Default page style, Heading N styles, Default Paragraph Style, the works. For "RTL documents" (defining that as one will), either the entire tree, or at least the subtrees of: Headings, References, Bookmarks, Tables, Indices, Comments, Footnotes and Endnotes - should be RTL. Note that the effect of the current state of affairs is, that if your Navigator is not very wide, you are likely to not be able to see the numbers and the first several words of headings, bookmarks, etc. - which is exactly the content you _must_ see to understand what item this is. This is somewhat similar to the issue of the Cross-Reference dialog hierarchy of items.
Eyal, thank you for the report. Looks like an enhancement request to me. Sounds reasonable to me. Heiko, Jim, what do you think?
Eyal, how do trees look like in other RTL applications? For example the file browser.
(In reply to Heiko Tietze from comment #2) > Eyal, how do trees look like in other RTL applications? For example the file > browser. Can you clarify the question? If you're asking how other applications behave with wholly-RTL documents, the answer is - I don't think I even use other applications which edit documents with a specific document-level directionality. File browsers don't have some strong directionality of anything, certainly not an inherited one.
(In reply to Eyal Rozenberg from comment #3) > Can you clarify the question? I can imagine and agree that it would be desirable. Asked just out of curiosity how it looks. Trees with a deep hierarchy are discouraged in general and for less complex layouts a list is recommended. So I wonder if the tree implementation support RTL anyway. Haven't found any example for Gtk. The request is not limited to the Navigator but also relevant for the Stylist, for example.
Created attachment 179762 [details] screenshot when the LANG is he_IL-UTF8 My understanding is that all those UI things follow the UI Language rather than the document language so for me with LANG=he_IL.UTF-8 (and the hebrew langpack installed) then I get the above, where for at least the gtk case I have an apparently RTL navigator treeview
(In reply to Caolán McNamara from comment #5) > My understanding is that all those UI things follow the UI Language rather > than the document language Yes. But - this becomes a problem when you fill up the UI with document content - which is what happens in Navigator. It also happens in the xref dialog (bug 131725). The worst part of it is how you get the ends of labels rather than the beginning of labels.
I'm not sure there is a general solution when using the LTR UI to get good outcomes in the dialogs with such lists of RTL text. It is possible to override the direction of individual widgets but in the general case the text that will appear in the list is arbitrary. One could try and bubble the "document language" around the place and override default direction based on that, but its a big amount of UI to attempt to try and tackle that widget by widget
(In reply to Caolán McNamara from comment #7) > but its a big amount of UI to attempt to try and tackle that widget by > widget But almost no LO UI needs this. I currently know of two places. Maybe you can find another example or two.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Heiko Tietze from comment #4) > I can imagine and agree that it would be desirable. Asked just out of > curiosity how it looks. > > Trees with a deep hierarchy are discouraged in general and for less complex > layouts a list is recommended. So I wonder if the tree implementation > support RTL anyway. Haven't found any example for Gtk. Gtk and Qt themselves provide support for RTL trees. Are you talking about VCL implementation? For example, compile examples for GtkTreeView: https://docs.gtk.org/gtk3/treeview-tutorial.html but add this line: gtk_widget_set_direction(view, GTK_TEXT_DIR_RTL); > The request is not limited to the Navigator but also relevant for the > Stylist, for example. This is correct. I think the RTL layout for the trees would be desirable, but the problem would be mixed LTR RTL contents that happens because of the untranslated English text. For MS Word, even the style names are translated, so the output ins nice looking, but when the style names are English, the result is not always visually attractive.
As Caolan I expect RTL control when the UI language is set respectively.
An example from the other office suites, in Arabic: https://answers.microsoft.com/en-us/msoffice/forum/all/word-2013-navigation-pane-for-arabic-headings/822a7ad2-9a94-48fa-90e7-15e034dec6a5 As you can see, "Heading 1" is translated into "عنوان 1".
(In reply to Hossein from comment #12) > An example from the other office suites, in Arabic: With LTR UI, the tree is partially-LTR, partially RTL: * (LTRish) Expansion controls are on the left * (RTLish) Alignment is to the right, extra space is to the left * (RTLish) One sees the right part of the tree item text, with "..." on the left
wrt comment #8 if there was only two places where this was wanted I could see it as practicable to implement. Widget::set_direction exists to override the default UI direction for a widget so that capability exists. Possibly worth exploring.
(In reply to Caolán McNamara from comment #14) > if there was only two places You can check... the relevant criterion is inserting runs of text from the document into the UI. Obviously that's not done often.
Maybe table of contents dialog? and some bookmark/index selecting dialogs, not sure off the top of my head but presumably of lesser importance than the already mentioned cases.
well, we can give https://gerrit.libreoffice.org/c/core/+/133646 a shot which for the document in https://bugs.documentfoundation.org/show_bug.cgi?id=131725 would give a RTL treeview in an otherwise LTR UI which allows exploring that idea for a while at least.
(In reply to Caolán McNamara from comment #16) > Maybe table of contents dialog? Nope, you don't get actual document content in there. > some bookmark/index selecting dialogs, Bookmark - that's the XRef dialog, isn't it? And index is the ToC dialog.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/84ad4fe061ebfbbcdc0ffeec329e117250627157 tdf#148432 in LTR UI override the navigator treeview direction for RTL doc It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Now in a LTR UI if the document is RTL (where I decided to use the direction of the first page style to determine that) the navigator content list is RTL (the cross reference dialog also does similar now)