https://bugs.documentfoundation.org/show_bug.cgi?id=168624

--- Comment #6 from Jonathan Clark <[email protected]> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Reply via email to