By default, LibreOffice hides some aspects of its UI, related to full support for RTL, CTL and/or CJK scripts. This support has toggles under Tools > Options > Languages & Locales > General > Default Languages for Documents . It is often the case, that people writing and editing RTL-script documents (e.g. Arabic, Hebrew), who install LibreOffice or have it installed for them, do not enable the "Complex text layout" toggle. In that case, they will have trouble editing their documents (e.g. not see paragraphd direction indication nor be able to switch it; possibly not be able to choose the font used for their RTL text as they only see the Western language group listbox, etc.) This meta-bug defines the target of making this happen less, or not at all; with blocking bugs being ideas or suggestions which may mitigate the situation.
... as for CJK languages - I'm not sure how frequently this happens and how much CJK script users consider this a problem. Assuming that it _is_ a problem - let's track also bugs regarding CJK scripts.
If we don't toggle RTL/CTL/CJK support on more "aggressively", then we should at least offer this in the Welcome menu.
Unlike bug 47969, which has a specific condition "enable when respective keyboard layouts are installed", which translates to a trivial reproduction of "install OS a; set locale to b; install keyboard layouts c, d, e; open LibreOffice; see the problem" - the two other bugs added at this points have no reproduction scenario at all. This bug must first collect the *reproduction scenarios of the problem*, before collecting ideas how to improve.
(In reply to Mike Kaganski from comment #3) In bug 161258 there is nothing to reproduce. It's not something that happens unexpectedly, in a certain situation - it's a claim that the policy should be changed. So you're really just commenting on bug 161255.
(In reply to Eyal Rozenberg from comment #4) Then it needs a change in its title, which still has "when can't confidently determine otherwise", implying a scenario "when".
(Quoting Heiko from a comment in bug 164571 which I believe belongs here...) We discussed the topic at the design meeting. A new installation/user wont know about Tools > Options > Languages > CTL/CJK and miss some support for their language. The minimum necessary setting is changing the locale, which affects the CTL/CJK option below. Some possible solutions come in mind: * Show a "Welcome Screen" on first startup with appropriate info and choices (bug 54593) * enable CTL/CJK by default (and let Western user disable it) * some heuristics during the installation to switch the option on / change the locale * pop-up an infobar at the first time when RTL content is inserted * tip of the day (bug 125257) * implement a guided tour (bug 164725)
(In reply to Eyal Rozenberg from comment #6) There is still no steps to reproduce the "RTL, CTL, CJK users are failing to enable full RTL-CTL/CJK support". Is this specifically about "improve discoverability of the settings for the users who do not use a RTL, CTL, CJK system locale, or make the support enabled unconditionally"? Comment 0 has the "It is often the case, that people writing and editing RTL-script documents (e.g. Arabic, Hebrew), who install LibreOffice or have it installed for them, do not enable the "Complex text layout" toggle" claim, that is not clarified at all. Depending on the situation, the proper fix could be e.g., improving detection of that case - not fitting to the proposal here. Without proper clarification of the *scope* of this bug (which has a clear proposal, but still no clarity in which *problem* that proposal is intended to solve), I see this report INVALID (after so long period of asking for clarifications).
(In reply to Mike Kaganski from comment #7) It's not that users are actively _trying_ to enable expanded/full support, and failing. The problem is that they're not trying (or at least, not trying what would actually works). So, is this a (meta-)bug about discoverability? Partially. Broadly speaking, there are two approaches to getting RTL-CTL/CJK clicked when it needs to be: * Do this automatically for the user (e.g. in some circumstances) * Make it more likely the user does it themselves Different blockers (or related bugs) improve things in one of these avenues About the "it is often the case" claim - I spoke about this in the design meeting, but the minutes are very succinct and bottom-line-ish. Let me elaborate a little: Looking at a LibreOffice module, there is nothing to lead one to believe that there may be "better RTL support", that's just disabled. You can open a document with RTL content, it will be rendered RTL, and you can insert RTL and LTR as you please. You would notice, at some point, that you can't change the RTL text's font - but again, nothing will lead you to think "oh, I just haven't told my app to _really_ support RTL". It's not like how some apps have a choice between "simple mode" and "advanced mode" when you start them up. But, one would ask, isn't RTL-CTL support enabled by default if you download a version localized for Arabic, or Farsi, or Hebrew etc.? ... Well, the thing is, it is often the case that that's not the version people have installed. Why? * Many RTL language speakers/writers prefer English UI for their OS and applications - because they're used to it, because of collaboration with others on the same machine, because it then feels weird to use the English UI when you're on some public computer, because the translation is not really there yet, etc. So, they are likely to download the "default", or English-language, LibreOffice - either by explicit choice or by the locale choice of their browser when they visit the download page. * The "default version" that gets installed if you use a package manager is typicdally not your country-localized one. This is true both for GNU/Linux distributions and for Windows package managers like WinGet or Chocolatey.
(In reply to Eyal Rozenberg from comment #6) > (Quoting Heiko from a comment in bug 164571 which I believe belongs here...) > * enable CTL/CJK by default (and let Western user disable it) +1. I'd even not let disable it, for simplicity / uniformity. Wherever the UI is overloaded in this case, it needs a redesign of the specific UI, not disabling some "support".
(In reply to Mike Kaganski from comment #9) > +1. I'd even not let disable it, for simplicity / uniformity. Wherever the > UI is overloaded in this case, it needs a redesign of the specific UI, not > disabling some "support". The less far-reaching version of this suggestion is bug 161258.