Bug 134628 - Rename "Ignore system input language" in language options
Summary: Rename "Ignore system input language" in language options
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyBeginner, easyHack, skillDesign, topicDesign
Depends on:
Blocks:
 
Reported: 2020-07-07 20:30 UTC by christos
Modified: 2022-11-07 08:32 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Description and suggestions (124.23 KB, application/pdf)
2020-07-07 20:32 UTC, christos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description christos 2020-07-07 20:30:52 UTC
Description:
The labels in the language options dialog together with the fact that option "Ignore system input language" appears in the language options make one think that it applies to all of LibreOffice. However, this option applies only to Writer.

Even for Writer, the exact meaning of this option is not clear (although of course users who need it get used to it after a while).

Steps to Reproduce:
1. From the menu, choose Tools > Options.
2. On the left-hand side of the dialog window, choose Language Settings.
3. Expand the Language Settings node, then choose Languages.

Actual Results:
See the attachment for a description with screenshots.

Expected Results:
See the attachment for a discussion of possible improvements.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.4.4.2 (x64)
Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 1 christos 2020-07-07 20:32:25 UTC
Created attachment 162773 [details]
Description and suggestions
Comment 2 Heiko Tietze 2020-07-17 12:08:48 UTC
Wish every bug report would be done so carefully. To summarize the PDF:

* option was introduced in response to bug 36324
a) the label could read “Input method change language in Writer”
b) title “Enhanced language support” to “Change of language in document”
c) all modules should behave respectively
d) make more languages readily available in menus

My take:
a) +1
b) doesn't sound much better to; how about "System input language"
c) that might be tricky; and actually while bug 127898 and bug 34142 request such behavior the editing is not paragraph based. Opinions, Mike & Eike?
  + if we keep the option for Writer only, we have to move it to Formatting Aids
d) that spoils how the localization work; the list should contain what's defined in the paragraph/character style, in tools > options > language > locale, and what input languages the system provides all compared to installed dictionaries (but off-topic here as requested in bug 134737)
Comment 3 christos 2020-07-17 13:42:28 UTC
(In reply to Heiko Tietze from comment #2)
> a) the label could read “Input method change language in Writer”
> b) title “Enhanced language support” to “Change of language in document”
> c) all modules should behave respectively
> d) make more languages readily available in menus
> 
> My take:
> a) +1
> b) doesn't sound much better to; how about "System input language"
> c) that might be tricky; and actually while bug 127898 and bug 34142 request
> such behavior the editing is not paragraph based. Opinions, Mike & Eike?
>   + if we keep the option for Writer only, we have to move it to Formatting
> Aids

Thank you! Pasting from the PDF before a) gets copied without the s :)
a) "Input method changes language in Writer"
Of course this means that it is not 'ignored', so what was checked will now be unchecked and vice-versa.

b) On second look, the bottom section with the input method checkbox could just be labeled "Other". The label in a) is enough for the box itself. In case other options sneak into this dialog in the future, "Other" will still be good as a headline.

a) and c) are mutually exclusive. You decide between the two, I'd be happy with either one. But if you go for a), you may want to keep the option near the default language, as it can override that language.
Comment 4 Heiko Tietze 2020-07-27 13:31:44 UTC
So let's do the renaming. The one who picks up the topic might decide if and what term to use instead of “Enhanced language support”.
Comment 5 Mike Kaganski 2020-07-27 13:34:37 UTC
Just don't mention Writer. The setting is not intended to be limited; if it is, it's just a missing implementation/bug, not something to make the norm.
Comment 6 christos 2020-07-30 16:26:27 UTC
(In reply to Mike Kaganski from comment #5)
> Just don't mention Writer. The setting is not intended to be limited; if it
> is, it's just a missing implementation/bug, not something to make the norm.

At any given time, should the labels reflect what the software does or what it would do if certain known bugs were not there? I would choose the former; the latter is, well, an additional bug. So Writer should be mentioned until c) in #comment 2 is done.

Suggested label changes following the discussion so far:
1. Language Of > Localization
2. Enhanced Language Support > Other
3. Ignore system input language > Input method changes language in Writer
Comment 7 Mike Kaganski 2020-07-30 16:27:50 UTC
(In reply to christos from comment #6)

At any given time, the labels must not be changed to reflect bugs.
Comment 8 christos 2020-07-31 15:52:13 UTC
(In reply to Mike Kaganski from comment #7)
> (In reply to christos from comment #6)
> 
> At any given time, the labels must not be changed to reflect bugs.

This report is not about changing labels to reflect bugs (see, in particular, the description and suggestions in the PDF attachment and also comment #6).
Comment 9 Mike Kaganski 2020-07-31 15:57:12 UTC
(In reply to christos from comment #8)
> This report is not about changing labels to reflect bugs (see, in
> particular, the description and suggestions in the PDF attachment and also
> comment #6).

Hey, do you claim that I called that this is "about changing labels to reflect bugs"? You reacted on my very specific comment, where I wrote that I don't see problems in changing the wording, just mentioned *one* thing that should not be done. You started to discuss this nuance, which *is* about reflecting bugs (specifically, the function in question is *not* intended to be limited to Writer, and that it *is* is a bug); and in the course, you substituted the argument.

Again: please rename, as long as you don't mention Writer in the setting label.
Comment 10 christos 2020-09-27 17:50:52 UTC
(In reply to Mike Kaganski from comment #9)

It was a way of reiterating (partial) disagreement. In comment #6 I argued that the label should mention Writer UNTIL all modules are made to behave similarly. I know your time is very limited, but if one of us says we should do A for this reason and the other B for that reason without engaging with each other's argument, I'm afraid we'll soon end up talking past each other.

When I filed this report I did not know whether this option was meant to apply to a) Writer only or b) all modules. The response to a) would be to change the label; the response to b) would be to extend the option to all modules.

You wrote in comment #5 that b) is true. The summary of this report has been changed and is now about renaming, close to what would have been the response to a), but - taking your comment into account - not quite. Should it not be about renaming AND THEN about extending the option to the other modules?

Renaming without mentioning Writer (as you wrote in comment #5) would be fine, IF the extension of the option to all modules were to be done soon afterwards. This does not seem likely, however. In the meantime, how are users supposed to find out that the option does not work in other modules? Well, they could test it, as I did. Do you really expect that?

Again, I know time is limited. I understand that any change to labels must be translated into many languages, so the effort is multiplied. But I believe that labeling that reflects what the software does is best for the users. When the software changes, the labels can change with it.
Comment 11 Mike Kaganski 2020-11-26 07:30:05 UTC
For the context (this partially repeats some bits from attachment 162773 [details], and also adds some missing parts).

The option to *take the system input language into account* had been introduced in 2001 in https://bz.apache.org/ooo/show_bug.cgi?id=1035. It had received requests then to make it optional, e.g. its comm. 6, and in https://bz.apache.org/ooo/show_bug.cgi?id=100762. Our bug 36324 had introduced the UI option to disable the feature, but not the discussed functionality.

The option had been implemented initially for Writer, and for Windows (OOo bug had even a comment telling "on Unix I see no chance"). However, lately Jan-Marek had committed https://git.libreoffice.org/core/+/9d96088c2832b681ae079b29cbc977231674ad52, with support for Qt5 (so it is expected that v.7.2 will *partially* support it on Linux).

The "See Also" bug tdf#108151 covers the missing OS support bits, and bugs tdf#34142 and tdf#127898 - the missing component support bits.
Comment 12 Heiko Tietze 2022-06-10 06:12:17 UTC
We are discussing the correct phrasing on Gerrit since the new text would invert the logic. My comment there: 

From BZ: "Ignore system input language" is misleading with proposal to use “Input method changes language in Writer” and Mike's suggestion is "Apply system input language to new text". I don't think any of these options is self-explanatory, we need a tooltip and documentation. More generally speaking, checkboxes should be phrased positively (false: [x] Avoid Foo, correct: [ ] Foo), which makes Mike's suggestion better than the other ideas.

Key is the action "Apply" that fits nicely with the checkbox. "System input language" is for most users unclear and should be explained in a tooltip or the documentation.
Comment 13 Heiko Tietze 2022-11-07 08:32:56 UTC
Patch https://gerrit.libreoffice.org/c/core/+/135246 was abandoned due to inactivity, reverting assignee status.