Would it require a dictionary to be able to select a language there?
And in general, what is the actual advantage of hiding UI for part of functionality? IMO, it would be better to just drop the checkboxes altogether, and have all the UI exposed all the time.

Some arguments:

- This UX carries all of the same baggage we see with the language trichotomy more generally (bug 162336). LO does not function correctly for language users unless configured properly, and in order to configure it properly, users must know ahead of time how we categorize their languages into our trichotomy. The language trichotomy is *not* a natural partitioning of writing systems; it's just something office suite programmers invented. We shouldn't expect users to understand our implementation details in order to use our software correctly.

- This UX does not allow users to configure more than one language per group. That's counterintuitive: our Western, CTL, and CJK categories are geographically-clustered. Bilingual within the same category is the more common case (e.g. English and German), but our current UX subverts expectations by making the more common case impossible to configure. Due to LO implementation details (bug 151215) we can't yet do anything too interesting if users could set multiple languages within the same group, but we're leaking those implementation details by disallowing the attempt.

- Having a single preferred proofing language across all categories is significant for Office interoperability. For example, bug 167673.

- Having a user-specified, prioritized list of proofing languages would unlock further UX improvements in certain areas. For example, we could simultaneously fix bug 95274 (user cannot choose the language for a selection because it is not offered as a candidate) and bug 47896 (user cannot choose the language for a selection because it is buried by irrelevant candidates) by always letting the user select from among their configured proofing languages.

My first reply wasn't a response to your questions. I wanted to outline the argument separately from the feature description, to avoid confusion.

(In reply to Mike Kaganski from comment #1)
> Would it require a dictionary to be able to select a language there?
No. We don't require one now, and I don't think we'd need to change that.

> And in general, what is the actual advantage of hiding UI for part of
> functionality? IMO, it would be better to just drop the checkboxes
> altogether, and have all the UI exposed all the time.
The argument in favor of hiding them is they're confusing or seem buggy to users who don't understand their purpose (especially the Western-only majority). RTL paragraph direction, for example, is close enough to right-align that it does bait users into using it as one, only to get confused/angry when they're confronted with the feature working correctly. Vertical right-to-left also only really works for East Asian text, but is another case of being close enough to text rotation that people will try to use it that way and will be surprised when it seems to break.

I'm not strongly in favor of one or the other, just outlining the argument. Currently, we get bug reports from users who are missing features. If we change this, expect bug reports from users who are using features incorrectly.

First, a question What are "proofing languages"? I don't see those anywhere in Tools > Options. Do we have a feature involving those?

Now, while I agree that choosing "one default language", and per artificial languiage group, is kind of silly - it is an actual setting that LO has and uses - for the language choice in the default paragraph style of documents (at least, LO is supposed to be doing that). While the trichotomy is in place, I disagree with crippling users' ability to configure the app as it is. So, I oppose this implicit setting via an opaque prioritization of languages; users will just have to do a different kind of guessing.

I doubly object because this will place an even more powerful mask on full support toggles for the RTL-CTL and CJK language groups. Yes, it's true that users might get support enabled "for free" - but they might miss that, not caring about "proofing languages", and not find the setting anywhere. No, this is not good enough. On the contrary: What I would like to see is:

1. More panes in the navigation tree which, when clicked, suggest enabling full support for the relevant language group (or just allow enabling it right there).
2. A separate section for just the two toggles of support for RTL-CTL and for CJK, with an attractive title, e.g. "Full support for languages", separately from default language choice, and
3. A clearly-worded label for each of these checkboxes, e.g.: "Enable full UI support for Right-to-Left and Complex-Text-Layout text" and "Enable full UI support for CJK East-Asian languages". This can be bikeshed of course. 
4. Perhaps a warning message at the bottom of this pane, that dismissing this dialog may hinder use of LibreOffice with written language such as X, Y and Z from the two groups. Kind of like a "Ministry of Health Warning" sticker.

... and maybe something to direct the user to the right place in the nvaigation pane.?

(In reply to Eyal Rozenberg from comment #5)
> First, a question What are "proofing languages"? I don't see those anywhere
> in Tools > Options. Do we have a feature involving those?
Yes, we do. We call them "default languages for documents".

> While the trichotomy is in
> place, I disagree with crippling users' ability to configure the app as it
> is. So, I oppose this implicit setting via an opaque prioritization of
> languages; users will just have to do a different kind of guessing.
>
> I doubly object because this will place an even more powerful mask on full
> support toggles for the RTL-CTL and CJK language groups.
For a comparable, see recent versions of Microsoft Word.

Like us, Word has the exact same trichotomy with all of the same issues, and they also have CTL/CJK features hidden dependent on configuration. Despite that, they successfully migrated their configuration away from what we currently have toward something like what I'm describing. They did this years ago, and I've never seen or heard anyone complain about it.

> On the contrary: What I would like to see is:
> 
> 1. More panes in the navigation tree which, when clicked, suggest enabling
> full support for the relevant language group (or just allow enabling it
> right there).
> 2. A separate section for just the two toggles of support for RTL-CTL and
> for CJK, with an attractive title, e.g. "Full support for languages",
> separately from default language choice, and
> 3. A clearly-worded label for each of these checkboxes, e.g.: "Enable full
> UI support for Right-to-Left and Complex-Text-Layout text" and "Enable full
> UI support for CJK East-Asian languages". This can be bikeshed of course. 
> 4. Perhaps a warning message at the bottom of this pane, that dismissing
> this dialog may hinder use of LibreOffice with written language such as X, Y
> and Z from the two groups. Kind of like a "Ministry of Health Warning"
> sticker.
> 
> ... and maybe something to direct the user to the right place in the
> nvaigation pane.?

I'd argue a lot of the problem re: bug 164250 is the fact that our user interface is too deeply nested, too expressive, and asks the user to read too much. I'm having a hard time thinking that this situation could be improved by spreading things out even more or adding labels and warning messages that we already know people don't read.

(In reply to Jonathan Clark from comment #6)
> (In reply to Eyal Rozenberg from comment #5)
> > First, a question What are "proofing languages"? I don't see those anywhere
> > in Tools > Options. Do we have a feature involving those?
> Yes, we do. We call them "default languages for documents".

Users will not know what "proofing languages" are. Nor will they realize setting these languages affects support for language groups.

> For a comparable, see recent versions of Microsoft Word.
> 
> Like us, Word has the exact same trichotomy with all of the same issues, and
> they also have CTL/CJK features hidden dependent on configuration. Despite
> that, they successfully migrated their configuration away from what we
> currently have toward something like what I'm describing. They did this
> years ago, and I've never seen or heard anyone complain about it.

That's because you don't need to configure anything on MS Office. RTL-CTL support "just works". I'm not sure if it's enabled on all systems, or whether they use some heuristic though.


> I'd argue a lot of the problem re: bug 164250 is the fact that our user
> interface is too deeply nested, too expressive, and asks the user to read
> too much.

That's true, but your suggestion would exacerbate the situation even further.

>  I'm having a hard time thinking that this situation could be
> improved by spreading things out even more or adding labels and warning
> messages that we already know people don't read.

If more paths through Tools | Options suggest that you need to enabled RTL-CTL, or CJK, support, then you are more likely to notice that suggestion.

And the more clear the suggestion is, the more likely you are to understand and follow it.

(In reply to Eyal Rozenberg from comment #7)
> Users will not know what "proofing languages" are.
"Proofing languages" is what Microsoft calls them in their own user interface. This wording seems clear to me, and I'm not aware of any confusion among Office users about this, so I felt comfortable borrowing the terminology here. Please feel free to suggest an alternative.

> Nor will they realize setting these languages affects support for language groups.
The whole point of this metabug (bug 164250) is that users don't know what language groups are and don't realize they need to do anything to affect support for them. This is an argument in favor of the change, not an argument against it.

> That's because you don't need to configure anything on MS Office. RTL-CTL
> support "just works".
This isn't true. Certain things may work automatically for certain OS regions, but coming from en-CA, even with RTL and CJK input installed I always have to add proofing languages manually (or install a language pack, which just does it for you).

https://support.microsoft.com/en-us/office/language-accessory-pack-for-microsoft-365-82ee1236-0f9a-45ee-9c72-05b026ee809f

The real difference isn't that Office gives a better user experience automatically. What Microsoft has done is spend decades training their users to expect a bad experience until they install a language pack. We're being held to a higher standard.

> I'm not sure if it's enabled on all systems, or whether they use some heuristic though.
RTL/CTL and CJK features are all hidden by default. They are enabled by configuring a relevant proofing language (and/or a language pack).

> That's true, but your suggestion would exacerbate the situation even further.
I disagree. My suggestion will consolidate 5 difficult-to-explain user interface elements into a single easy-to-explain one.

> If more paths through Tools | Options suggest that you need to enabled
> RTL-CTL, or CJK, support, then you are more likely to notice that suggestion.
> 
> And the more clear the suggestion is, the more likely you are to understand
> and follow it.
If enough people looked through Tools | Options, I doubt bug 164250 would be much of an issue.

(In reply to Jonathan Clark from comment #8)
> "Proofing languages" is what Microsoft calls them in their own user
> interface. 

1. The fact Microsoft does something is not in itself an argument for us to do it.
2. I don't remember MS doing that in their user interface.

> This wording seems clear to me, and I'm not aware of any
> confusion among Office users

Please don't call Microsoft Office "Office". 


Anyway, I use Microsoft Office often, and like I said - I've never heard that term either. So it's not confusing by virtue of behing unheard of.


> about this, so I felt comfortable borrowing the
> terminology here. Please feel free to suggest an alternative.

You're the one suggesting a change to the UI. These are the default languages used for the 3 different language groups. I would, however, support changing the section label name to something which better clarifies that, if you have a suggestion.

> The whole point of this metabug (bug 164250) is that users don't know what
> language groups are and don't realize they need to do anything to affect
> support for them. This is an argument in favor of the change, not an
> argument against it.

No, it's not. You're suggesting a change while the trichotomy is still in effect - when users are forced to deal with it. A change which half-pretends it does not exist is not an improvement with the current state of affairs.


> This isn't true. Certain things may work automatically for certain OS
> regions, but coming from en-CA, even with RTL and CJK input installed I
> always have to add proofing languages manually (or install a language pack,
> which just does it for you).

Hmm, proofing _tools_. I vaguely remember there was some kind of extra product called "Office Proofing Tools". Does that still exist? How many people use it?

> The real difference isn't that Office gives a better user experience
> automatically.

It seems you mean Microsoft Office. Don't call it Office please.

> What Microsoft has done is spend decades training their users
> to expect a bad experience until they install a language pack. We're being
> held to a higher standard.

Don't know what you mean. Whenever I installed MS Office (which admittedly is not recently), I did not install any language pack, but RTL-CTL worked.


> RTL/CTL and CJK features are all hidden by default. They are enabled by
> configuring a relevant proofing language (and/or a language pack).

I don't think so.

> > That's true, but your suggestion would exacerbate the situation even further.
> I disagree. My suggestion will consolidate 5 difficult-to-explain user
> interface elements into a single easy-to-explain one.

A complex multitude of harder-to-explain options.

And of course, ease of explanation does not matter, because users typically don't wait for explanations. There are self-evident things, and there are complicated-looking things which most users tend to skip.

> If enough people looked through Tools | Options, I doubt bug 164250 would be
> much of an issue.

We're talking about Tools > Options - and the users who do use it for some thing or the other, in this bug. Naturally, people who don't open Tools > Options will not be affected by the change, neither for better nor for worse.

Created attachment 203094 [details]
screenshot of languages settings in MS Word 365.

Microsoft Word uses the terms "authoring languages" and "proofing tools", see attached screenshot of the settings.

Which language packs are installed by default in Word, depends on the locale. I had initially a German Word and need to install language packs to get different text directions.

(In reply to Eyal Rozenberg from comment #9)
> No, it's not. You're suggesting a change while the trichotomy is still in
> effect - when users are forced to deal with it. A change which half-pretends
> it does not exist is not an improvement with the current state of affairs.
I'm not comfortable with the suggestion that we can only design away from the language trichotomy if we do everything in a single step. Even if I thought we could make any progress like that, it would be an enormous risk.

This is a small area of the UI that most users don't interact with regularly. It seems quite safe to start experimenting with post-trichotomy UX here. We already know we will need this kind of configuration mechanism no matter what form our trichotomy replacement takes. More importantly, though, we have other non-trichotomy use cases that call for this sort of configuration mechanism. Even if we didn't do anything else with the language trichotomy, LO users would still see benefit from this change.

> Don't know what you mean. Whenever I installed MS Office (which admittedly
> is not recently), I did not install any language pack, but RTL-CTL worked.
Your OS locale is likely en-IL, so that makes sense. I'd be interested to know if they installed other languages by default, or if they've just enabled RTL-CTL features as part of that English locale.

> A complex multitude of harder-to-explain options.
No, it's one option: a list of languages you want to use to write documents.

And to reiterate, this replaces: a Western language; a CTL language; an Asian language; whether or not you want Asian typesetting features; and whether or not you want RTL typesetting features. (Note for users: Many Asian languages are actually Western, so make sure you search all of the dropdown menus carefully!)

I find the term proofing languages confusing, but otherwise I feel that this suggestion is an improving (if I'm correctly understanding the proposal). Instead of the cryptic CTL and Asian nomenclature, users have a simple UI showing what languages they intend to use. Would this also handle spelling and hyphenation etc. dictionaries as well (so less UI places to configure languages one wants to use)?

(In reply to Regina Henschel from comment #10)
> Created attachment 203094 [details]
> screenshot of languages settings in MS Word 365.
> 
> Microsoft Word uses the terms "authoring languages" and "proofing tools",
> see attached screenshot of the settings.

I now (think I) understand where Jonathan brought this term from; in fact, this screenshot casts the suggestion in the different light of aligning this part of our preferences with those of MS Office.

However - that does not make this change a good idea.

First, and in principle, we should not copy what MSO does, because MSO does it. Even if one tried to argue for this as a measure of easing transition - it would have little effect: Most MSO users probably don't interact with it, and even then, it would not be exactly the same UI as what Jonathan proposes.

Second, even in the MSO dialog, the word "proofing" is used once, and as a secondary characteristic of entries on the list in the screenshot. This probably has to do with the "MS Proofing Tools" which one can download. Few MSO users know about that, and no LO users know what that should mean - nor do I. So let's just drop that word regardless of any UI changes.

Third - the MSO UI is a way to install or remove language-specific data/compiled code. If we had the ability to add or remove our own "language packs" - then a UI for that, similar to MSO's, would make sense.

(In reply to Khaled Hosny from comment #12)
> otherwise I feel that this
> suggestion is an improving (if I'm correctly understanding the proposal).
> Instead of the cryptic CTL and Asian nomenclature, users have a simple UI
> showing what languages they intend to use.

Except that it would not be a simple UI, as it hides what it actually does. It is a bit like a UI asking you for what you do for a living, and then later offering you templates which are relevant to your profession. Our users _are_ stuck - for now - with the RTL-CTL/Asian/Western language trichotomy. It is not a good idea to pretend that it doesn't exist in Tools > Options; we must let users clearly and explicitly control the behavior of the application; we must avoid, as much as possible, them having to guess what their choices actually imply.

> Would this also handle spelling
> and hyphenation etc. dictionaries as well (so less UI places to configure
> languages one wants to use)?

... this question illustrates the point I made in my last comment. If this UI were simple, this question would not come up. It is not simple in itself, and it gains more complexity when considered in the context of the authoring languages UI in MS Office.

Writer uses the trichotomy for different fonts per category. Should this become a setting per language? It applies only to Writer, yet, while the other options like Asian kerning are relevant in other modules too.

(In reply to Jonathan Clark from comment #6)
> (In reply to Eyal Rozenberg from comment #5)
> > First, a question What are "proofing languages"?
> We call them "default languages for documents".

Oh!
Please don't call them "proofing".
The "languages" (actually, locales) are used for more than that. E.g., for hyphenation, and for the locale used for numbers, currencies and dates in text (like in fields).

(In reply to Jonathan Clark from comment #4)
> > And in general, what is the actual advantage of hiding UI for part of
> > functionality? IMO, it would be better to just drop the checkboxes
> > altogether, and have all the UI exposed all the time.
> The argument in favor of hiding them is they're confusing or seem buggy to
> users who don't understand their purpose (especially the Western-only
> majority). RTL paragraph direction, for example, is close enough to
> right-align that it does bait users into using it as one, only to get
> confused/angry when they're confronted with the feature working correctly.
> Vertical right-to-left also only really works for East Asian text, but is
> another case of being close enough to text rotation that people will try to
> use it that way and will be surprised when it seems to break.
> 
> I'm not strongly in favor of one or the other, just outlining the argument.
> Currently, we get bug reports from users who are missing features. If we
> change this, expect bug reports from users who are using features
> incorrectly.

It is inevitable anyway. I am still in favor of imply showing the UI always - and then, it would likely make large part of the problem that Eyal mentions go away. People manage to make these errors even in the current setup, e.g. inserting RTL characters from special characters dialog, the precautions don't stop them...

(In reply to Heiko Tietze from comment #15)
> Writer uses the trichotomy for different fonts per category. Should this
> become a setting per language? It applies only to Writer, yet, while the
> other options like Asian kerning are relevant in other modules too.
What do you mean by "applies only to Writer"? I surely can set different fonts for Western and Asian texts in Edit Style dialogs with Calc and Impress.

(In reply to Heiko Tietze from comment #15)
> Writer uses the trichotomy for different fonts per category. Should this
> become a setting per language? It applies only to Writer, yet, while the
> other options like Asian kerning are relevant in other modules too.
I think this comment is asking about Options->LibreOffice Writer->Basic Fonts (X).

For background, MSO already has per-language default fonts. They're defined in the document theme and applied automatically on an input language change. In my opinion, this is a hack. We shouldn't do this; we should fix the root cause, instead (e.g. bug 151215, bug 162331). It also wouldn't be a viable approach for all of the platforms we support (e.g. bug 108151).

Yes, default fonts should become a per-language setting. However, it shouldn't be part of this specific bug. We already get the default fonts wrong for second languages within the same category, so this change by itself wouldn't make the problem worse in the short term. Per-language default font configuration is a useful early step in replacing the trichotomy, so that would hopefully follow soon after.

(In reply to Mike Kaganski from comment #16)
> It is inevitable anyway. I am still in favor of imply showing the UI always
> - and then, it would likely make large part of the problem that Eyal
> mentions go away. People manage to make these errors even in the current
> setup, e.g. inserting RTL characters from special characters dialog, the
> precautions don't stop them...
I filed bug 168719 to track this discussion.