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