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!)
If this is the final solution, you should remove the choices from the Languages settings that falsely imply that you can turn this feature off, assuming that the Asian users also will be forced to see the English version in all their dialogue boxes, too.
(In reply to larrybradley from comment #12) > If this is the final solution, you should remove the choices from the > Languages settings that falsely imply that you can turn this feature off... Where exactly is an option left?
I have just read through this bug and in it observed the complete disregard of actual USERS by the developers who decided -- in the midst of the discussion -- to implement. A great many of us -- likely the vast majority -- have no use AT ALL for Asian language features. On that score alone, the decision to remove the ability to disable is extra-ordinarily wrong-headed. So, okay, leave the disable box unchecked by default -- that's not a great idea but can be lived with, but to eliminate it entirely is backwards, or as Claude put it when I began to investigate, it is a regression. Claude was, BTW, unaware. The result is clutter and complexity that is not needed or wanted. Whawn
This is one of the dumbest changes I've ever seen. It's apparent that the people who make these decisions have zero real-world/corporate/user experience. Why would you intentionally clutter up an otherwise clean interface with an intrusive interface and not provide the option to disable it for users who will never use it? Why do you think all Operating Systems and applications have language settings? Have you ever seen another product that forces this on users who don't want it? I really question the experience of people making these decisions. I've asked this in the past, but I'll ask it again, is there no change control board to this product? I've been told there is, but that it's 'easy' to bypass and have developers just do what they want without proper oversight. This never should have been allowed to be implemented.
(In reply to whawn from comment #14) (In reply to MacAhi from comment #15) First note opposing this change does not translate into marking this bug REOPENED. That would just mean that the suggested change is not fully implemented. Making comments is fine - although I would temper the rhetoric somewhat; but what you probably want to do is file a new bug in which you explain that the recent change is detrimental because X Y and Z, and that you suggest that A B and C. For this reason (and not because I'm discounting the feedback) I am changing the resolution of this bug again. Also, to gives more context: Note the dependent bug 164250, and the three avenues to ameliorating the problem there, which were arranged into three dependent bugs, this one and another two. Finally, please note the following minutes from relevant design meeting, on Dec 03rd, 2025: https://listarchives.libreoffice.org/global/design/2025/msg00116.html " * Strategy for increasing likelihood of auto-enabling full RTL-CTL/CJK UI support + https://listarchives.libreoffice.org/global/design/2025/msg00099.html + https://bugs.documentfoundation.org/show_bug.cgi?id=164250 + https://bugs.documentfoundation.org/show_bug.cgi?id=168719 + Tools > Options > Languages: toggles for RTL/CTL and for CJK have been removed, which needs to be confirmed or rejected => can be reverted if unpopular (Jonathan) + alternative is to introduce some heuristics or to allow disabling + happy enable all and wait for user complaints (Heiko) + Am worried we will get complaints due to making some UI more complex for users who don't need RTL support, but ok with doing it (Eyal) " I did accept this, but it was ex-post-facto, with the alternative being fighting for a backout of work that had already been done. And - I do concede that there are some benefits to the "cut the Gordian knot" approach of everybody getting the UI for all language groups, so this is somewhat of a tradeoff; and it was agreed that we would be willing to "revert if unpopular". The thing is, there is not enough testing of nightlies and pre-releases for us to get the complaints about this - and thus we're getting them after the 26.02 release rather than before.
(In reply to Eyal Rozenberg from comment #16) > Finally, please note the following minutes from relevant design meeting, on > Dec 03rd, 2025: > > https://listarchives.libreoffice.org/global/design/2025/msg00116.html > > " > * Strategy for increasing likelihood of auto-enabling full > RTL-CTL/CJK UI support > + https://listarchives.libreoffice.org/global/design/2025/msg00099.html > + https://bugs.documentfoundation.org/show_bug.cgi?id=164250 > + https://bugs.documentfoundation.org/show_bug.cgi?id=168719 > + Tools > Options > Languages: toggles for RTL/CTL and for CJK have > been removed, which needs to be confirmed or rejected > => can be reverted if unpopular (Jonathan) > + alternative is to introduce some heuristics or to allow disabling > + happy enable all and wait for user complaints (Heiko) > + Am worried we will get complaints due to making some UI more > complex for users who don't need RTL support, but ok with doing > it (Eyal) > " > > I did accept this, but it was ex-post-facto, with the alternative being > fighting for a backout of work that had already been done. ... What a great way to run a project. "Let's break this then wait and see if anyone complains." I've heard this approach up here before. Your process is broken.
https://bugs.documentfoundation.org/show_bug.cgi?id=169504#c38