Currently, we hide certain features and user interface elements from users unless they've enabled the "Asian" and "Complex text layout" checkboxes in Options -> Languages and Locales -> General. We should consider showing all of these features to all users, instead. The options to disable these language groups would be removed, and LibreOffice would be hard-coded to behave as if they are always enabled, regardless of configuration. Pros: - These features cannot be automatically turned on for all users who need them. By always showing these GUI elements, we would be fixing a usability problem. - The conditional GUI increases implementation complexity, both on the code side and on the UX design side. By removing these toggles, we would significantly reduce the number of potential GUI variants to design, code, and test. Cons: - Western-only users may get a more "cluttered" GUI in certain places, such as the character dialog. (But RTL/CTL and CJK users have been living with this, so maybe it will force us to think of ways to improve their experience too.) - Western-only users may start using language-specific features incorrectly, e.g. treating RTL text direction as right-align, or Asian vertical direction as a 90 degree rotate. (But users are already doing this, so to a certain extent it's unavoidable. Maybe we can also adjust text or UX to make it more clear what these features are meant to do.) See more discussion in bug 168624.
+1
+1 from me. See also: bug 104318 comment 19.
I am biased in favor of this - as an RTL-CTL user and as a "power user" who feels they understand the more cluttered UI well enough. So, I would support it; and I will assume RTL-CTL and CJK users would appreciate it if it were 100% absolutely certain they would have full support for their scripts. But that's also why I feel I have to play devil's advocate, or "RTL-CTL-CJK-uninterested user"'s advocate. Before actually arguing this way or that, however, I have some requests to make of us: * More specificity I: I claim we need to explicitly map, here on this bug, the UI changes resulting from enabling RTL-CTL and CJK, and evaluate the "prices" of each of these for users who, today, do not see them and don't need them. Also, the "prices" for RTL-CTL users who have to contend with CJK-related UI and vice-versa. * More specificity II: Same point, but regarding the "number of potential GUI variants", and the code we are hoping to reduce or simplify. Naturally this would be something that developers will be able to grasp more than QA/UX contributors. * Alternatives I: The supporters of this change should justify it not just vis-a-vis the current state of affairs in LO, but also other possible alternatives. Specifically, it is possible to improve the heuristics for enabling RTL-CTL and CJK so as to significantly reduce their false-negative rate; that is bug 161255 (and Jonathan has just made a commit to this end in bug 168540). Perhaps it is even possible to do it so that the false-negative rate is nearly zero, and the false-positive rate is not that high. If that is the case, the pro of "these features cannot be automatically turned on" vanishes almost entirely. Is it still then worth it? * Alternatives II: Same point, but regarding the The possibility of enabling these by default but allowing for their disabling (e.g. by asking the user about it somehow in the startup dialog, or doing so by default in localized packages for locales where RTL,CTL or CJK use is very uncommon, and so on.) This approach is the suggestion in bug 161258. * "Users are already doing this" regarding the conflation of direction and alignment, rotation vs vertical direction... this requires some elaboration, I would think. For an example, or discussion, regarding vertical directio, see bug 162200).
Seems to be uncontroversial. Most users are probably not aware of these options and will be surprised of the new feature. But there is probably no good alternative if bug 168624 should be done. +1
(In reply to Eyal Rozenberg from comment #3) > * More specificity I: I claim we need to explicitly map, here on this bug, > the UI changes resulting from enabling RTL-CTL and CJK, and evaluate the > "prices" of each of these for users who, today, do not see them and don't > need them. Also, the "prices" for RTL-CTL users who have to contend with > CJK-related UI and vice-versa. Highest impact will be the character dialog, which will now show the Complex and Asian tabs even to Western-only users. Second-highest will be showing the LTR and RTL toolbar buttons by default. The rest are extra menu bar items, extra tabs in certain dialogs, and infrequently an extra item on an existing tab page (likely none of which will be an issue). For CJK, non-CTL users: I think the only difference is the LTR and RTL toolbar buttons. For CTL, non-CJK users: Bug 161205 will land at the same time, so the major difference is some extra menu bar items and dialog tabs. > * Alternatives I: Specifically, it is possible to improve the heuristics for > enabling RTL-CTL and CJK so as to significantly reduce their false-negative > rate; that is bug 161255 (and Jonathan has just made a commit to this end in > bug 168540). Perhaps it is even possible to do it so that the false-negative > rate is nearly zero, and the false-positive rate is not that high. There are cases where we will never be able to perform automatic detection reliably, but we don't know how many installs fall into those cases because we don't collect data. I suspect that if we studied the problem, we'd find some pretty surprising ambiguous cases (like every en_US Linux desktop). If we want to minimize false negatives at the expense of false positives, we're still talking about making a lot of false positives. If we're comfortable with doing that, we might as well go with the identity heuristic of always enabling these features and instead put the effort into making these unused features easier for Western-only users to live with. > * Alternatives II: Same point, but regarding the The possibility of enabling > these by default but allowing for their disabling (e.g. by asking the user > about it somehow in the startup dialog, or doing so by default in localized > packages for locales where RTL,CTL or CJK use is very uncommon, and so on.) > This approach is the suggestion in bug 161258. I got the feeling that others are opposed to using a FTUE for language config, but I'm not opposed. If we did that, we would still need to somehow train users on what languages are Complex and what languages are Asian during startup, so they know whether they need to turn them on/off at the time (and guide them if they get the settings wrong). We'd create more false negatives and false positives, and we wouldn't get the code/GUI cleanup benefits.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/11c3d7bb03ab1daa8f14fff076987f65b7e36700 tdf#168719 Always show RTL/CTL and CJK editing features It will be available in 26.2.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.
The above commit is a minimal implementation. The intention is to make it as easy as possible to revert, if we decide it is necessary. I've filed bug 168719 for follow-up code cleanup.
The above commit is a minimal implementation. The intention is to make it as easy as possible to revert, if we decide it is necessary. I've filed bug 168780 for follow-up code cleanup.
(In reply to Jonathan Clark from comment #8) > The above commit is a minimal implementation. The intention is to make it as > easy as possible to revert, if we decide it is necessary. Please revert. We were in the middle of a discussion on whether or not this is a good idea, the commit is premature.
(In reply to Jonathan Clark from comment #5) > Highest impact will be the character dialog, which will now show the Complex > and Asian tabs even to Western-only users. Second-highest will be showing > the LTR and RTL toolbar buttons by default. The rest are extra menu bar > items, extra tabs in certain dialogs, and infrequently an extra item on an > existing tab page Which items? Which tabs? Which dialogs? Which extra items? > (likely none of which will be an issue). On the contrary, one of those items you neglected is alone enough of an issue for me to weakly-oppose this commit: The direction/writing mode, which with CJK and CTL-RTL enabled should now have at least 5 options: lrtb, rltb, tblr, tbrl, inherit ; with just RTL-CTL it should have 3 options. I do not believe it's appropriate to force RTL-CTL users to be aware of vertical writing modes. > For CTL, non-CJK users: Bug 161205 will land at the same time, so the major > difference is some extra menu bar items and dialog tabs. > If we want to minimize false negatives at the expense of false positives, > we're still talking about making a lot of false positives. 1. Reduce, minimize, and make-zero are different things, different options we need to consider before taking a decision. 2. Why would minimizing false negatives result in "a lot" of false positives? Or rather, what is "a lot"? > If we're > comfortable with doing that, we might as well go with the identity heuristic > of always enabling these features and instead put the effort into making > these unused features easier for Western-only users to live with. The conclusion of that sentence does not at all follow from the premise. You're basically assuming that there this alternative does not exist, pretending that "some false positives" is the same as "all possible false positives". > > * Alternatives II: Same point, but regarding the The possibility of enabling > > these by default but allowing for their disabling (e.g. by asking the user > > about it somehow in the startup dialog, or doing so by default in localized > > packages for locales where RTL,CTL or CJK use is very uncommon, and so on.) > > This approach is the suggestion in bug 161258. > I got the feeling that others are opposed to using a FTUE for language > config, but I'm not opposed. What is FTUE? Anyway, if even you are not opposed, then - certainly you should not have made the commit. > If we did that, we would still need to somehow train users on what languages > are Complex and what languages are Asian during startup, so they know > whether they need to turn them on/off at the time (and guide them if they > get the settings wrong). We'd create more false negatives and false > positives, and we wouldn't get the code/GUI cleanup benefits. Not necessarily. We could: 1. Ask users on startup something like "LibreOffice believes you use languages XXX or YYY; should we enable support for such languages?" 2. Show some pop-up the first time the user enters a dialog tab with RTL-CTL/CJK-related items, doing the "education" at that time; or just offering them to disable support without much education, and merely a link. For me, this is not such a great option. But if the alternative would is just enable-and-that's-that, then - I would expect at least something like this. Why would a person who only use Ethiopean be faced with two font choices in Format > Character... and need to figure out what those mean? When it's also quite difficult (discoverability-wise) to disable that?
I for one applaud exposing all users to any existing features. I always thought it was condescending for software makers to second-guess users' intelligence. Back when I was a teenager, I used to design songbooks for my friends, and I tried non-professional layout software like Word to lay out lyrics pages to look as funky as possible, and I wish I knew how to do vertical writing, which was impossible for me to learn as that feature was hidden away from me (this is exactly why, to this day, I simply cannot learn how to use minimalist text-based interfaces like ChatGPT and exploit its possibilities. I am VISUAL, give me something to click on!)