Bug 161258 - Default to enabling full RTL-CTL, CJK support (as in Tools|Options|Languages|General) when can't confidently determine otherwise
Summary: Default to enabling full RTL-CTL, CJK support (as in Tools|Options|Languages|...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: RTL-CTL CJK RTL-UI
  Show dependency treegraph
 
Reported: 2024-05-24 09:13 UTC by Eyal Rozenberg
Modified: 2024-06-14 11:34 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2024-05-24 09:13:28 UTC
A large fraction of people on Earth use scripts/language which are either right-to-left (RTL), involve complex text layout (CTL), or are ideogram-based (CJK). Yet - by default, LO disables support for these languages. Even those users who don't write in such languages are somewhat likely to want to read them, for international communications, for religious purposes (e.g. Islam uses Arabic) etc.

It seems to me that, by default, LibreOffice should have support for these language groups _enabled_.
Comment 1 Mike Kaganski 2024-05-24 10:06:40 UTC
It is unclear what is the problem specifically.

1. The "support" for these languages groups is *likely* the checkboxes in Options->Languages and Locales->General. This is not specified in the description at all.
2. It is not correct (or if it is, it is a bug), that "by default, LO disables support for these languages". The options mentioned above depend on the locale (or maybe UI language? Needs checking); so it is expected, that users using respective language / locale groups would have these options *enabled* by default.
3. Disabling these options *is not intended* to disable *reading support* for any documents, with or without the said language groups' text. They are intended to show/hide some related UI. Whenever they also affect layout (or other aspects of display of the documents), this should be a bug.
4. Many people actively disagree with seeing respective UI by default.
Comment 2 Eyal Rozenberg 2024-05-24 10:15:21 UTC
(In reply to Mike Kaganski from comment #1)
> 1. The "support" for these languages groups is *likely* the checkboxes in
> Options->Languages and Locales->General. This is not specified in the
> description at all.

Fair enough, added this to the title.

> 2. It is not correct (or if it is, it is a bug),

That is bug 161255. But given no heuristic or inconclusive heuristic check result, let's enable the full support by default.


> 3. Disabling these options *is not intended* to disable *reading support*

That's true. I should have added "and if they write them, they will occasionally use them in replies etc." but granted, it's a weak point.
Comment 3 Stéphane Guillou (stragu) 2024-06-12 01:11:15 UTC
I don't think all language support settings should be turned on by default for all locales, and would prefer if efforts were directed towards improving the automatic use of relevant settings depending on locale (if they don't work as expected currently, as in e.g. bug 161255), and clarifying/improving language support options, as in e.g. bug 104318 and bug 39935.

Of course, I understand the historical western-centric default is not ideal for many. But I don't think everything on by default in an already option-heavy application is the way to go.
For example, it is not desirable to have something as prevalent as the Font tab of the Character dialog be split in two halves when that's not going to be useful to the user, ever.

(Wondering in passing how feasible it would be to add a tick box to "turn off" Western/LTR support so it isn't the default anymore...)

(My non-RTL/CTL user 2 cents)
Comment 4 Eyal Rozenberg 2024-06-12 09:10:51 UTC
(In reply to Stéphane Guillou (stragu) from comment #3)

I'm not suggesting that support for RTL-CTL and CJK be _always on_; I suggest that the _default_ be on. That is, instead of applying a heuristic for verifying it needs to be turned _on_, the heuristic will check whether we need to turn it _off_. And only if we're sure it can safely be turned off - it will.

In other words, the "gray area" will be decided in favor of enabling support.

> I don't think all language support settings should be turned on by default
> for all locales

Stephane, you're making the assumption that the choice on/off for language support is, or should be, simply a function of locale. I reject this assumption. But even if it were true - there are locales which certainly need RTL-CTL support on, locales which certainly don't, and locales in which it may be necessary. And for those where it may be necessary, it should be turned on - that's my point regarding the default. If we improve our heuristics, we can move more situations from the "maybe" to the "certainly off" and "certainly on" groups.

>, and would prefer if efforts were directed towards improving
> the automatic use of relevant settings depending on locale (if they don't
> work as expected currently, as in e.g. bug 161255), and clarifying/improving
> language support options, as in e.g. bug 104318 and bug 39935.

that would complement my suggestion.

> Of course, I understand the historical western-centric default is not ideal
> for many.

I will assume you meant to say "is not ideal, period".

> For example, it is not desirable to have something as prevalent as the Font
> tab of the Character dialog be split in two halves when that's not going to
> be useful to the user, ever.

... ah, perhaps you actually did mean that a western-centric default is ideal, after all?

Nearly half the people of the world live their lives using more than one kind of written language, typically their native one, and some West-European language - English, French or Castillian mostly. That's true for most of Africa and Asia (including Russia, although Cyrillic can't currently benefit from the dialog being split.)

For those users, a split is desirable (or some other future arrangement if we switch to more complex font choice schemes as per bug 151215). If we can't say for sure whether the user only uses Western languages or not - we should split the dialog, rather than requiring the user, especially the newbie user, to have to locate the appropriate LO language option to be able to work.

To reiterate: Minor inconvenience for westerners must not trump major inconvenience to non-westerners.

> (Wondering in passing how feasible it would be to add a tick box to "turn
> off" Western/LTR support so it isn't the default anymore...)

Filed bug 161523 (although ability-to-turn-off and being the default are two different things.)
Comment 5 Mike Kaganski 2024-06-12 09:31:38 UTC
(In reply to Eyal Rozenberg from comment #4)
> > For example, it is not desirable to have something as prevalent as the Font
> > tab of the Character dialog be split in two halves when that's not going to
> > be useful to the user, ever.
> 
> ... ah, perhaps you actually did mean that a western-centric default is
> ideal, after all?
> 
> Nearly half the people of the world ...

Did you choose to simply ride a favorite horse, and turn the words as they were spelled into something that wasn't there? Given the following Stéphane's idea to treat the Western group the same way as others, I would naturally read his words as "if a user only needs one (ANY) group, it would be natural that their character dialog wasn't split, and only had the section for one (CHOSEN) group". Why did you decide to lecture others on something that wasn't suggested?
Comment 6 Eyal Rozenberg 2024-06-12 10:04:09 UTC
(In reply to Mike Kaganski from comment #5)
> I would naturally read his words as "if a user only needs one (ANY)
> group

Not my reading, but I'll take that part of my comment back.
Comment 7 Stéphane Guillou (stragu) 2024-06-12 11:36:29 UTC
(In reply to Eyal Rozenberg from comment #4)
> I'm not suggesting that support for RTL-CTL and CJK be _always on_; I
> suggest that the _default_ be on. That is, instead of applying a heuristic
> for verifying it needs to be turned _on_, the heuristic will check whether
> we need to turn it _off_. And only if we're sure it can safely be turned off
> - it will.
> In other words, the "gray area" will be decided in favor of enabling support.
Right, I understand better now, and I think that makes sense.

> I will assume you meant to say "is not ideal, period".
Yes, sentence should have stopped there.

> ... ah, perhaps you actually did mean that a western-centric default is
> ideal, after all?
As Mike said, that's quite unfair. But I appreciate you taking that back.
 
> Nearly half the people of the world live their lives using more than one
> kind of written language, typically their native one, and some West-European
> language - English, French or Castillian mostly. That's true for most of
> Africa and Asia (including Russia, although Cyrillic can't currently benefit
> from the dialog being split.)
> [...] If we
> can't say for sure whether the user only uses Western languages or not - we
> should split the dialog, rather than requiring the user, especially the
> newbie user, to have to locate the appropriate LO language option to be able
> to work.
> 
> To reiterate: Minor inconvenience for westerners must not trump major
> inconvenience to non-westerners.
Thanks for spelling it out. As said above, I think it makes sense, but I'll now leave it to UX and developers to decide whats preferable and technically feasible.
Comment 8 Heiko Tietze 2024-06-13 10:04:01 UTC
In bug 161523 you want to disable one of the three and here to enable all. And again, I think we should get rid of the artificial trinity.
Comment 9 Eike Rathke 2024-06-14 11:34:13 UTC
The artificial trinity stems from Microsoft Word (at least) and is also part of ODF for interoperability, see all style:*-asian and style:*-complex and style:script-type attributes in https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html