If I have a multilingual document with multilingual headlines, spell checking in the headlines of the automatically generated table of contents (TOC) should be off by default in the styles associated with the table of content. If there are spelling errors in a headline, they will be flagged and can be corrected there. The corrections automatically spill over to the TOC once this is updated. The current behaviour is not a bug. My proposal is merely an enhancement. Currently I have to edit the languages for all headlines in the TOC for each style sheet. Unfortunately there is no option to extend the language selection along the dependency of styles. It would also make sense to let one choose whether to extend or not the chosen language, (if it is handled internally like the other properties) the chosen colour, the chosen font, the chosen obliqueness, the chosen language or none to all lower styles of that category. By the way: It is quite unclear to me, whether the spell checking language is a property which can be set in two ways like many others (colour, slant, font, ...) which might be set by direct formatting or by styles (direct formatting prevailing if present). When writing documents on software, where you have single words in the text which have e.g. the "source" style, if you change the language for the paragraph, it also extends to single words or characters of with the "source" character style making them misspelled in many cases. One might consider to prepend the execution of direct formatting like changes of the spell-check language -if there are parts affected, which have the "no spell check" set- with this question: "Do you really want to set the spell check language for those included parts, which have the property "no spell checking"? No / Yes / Cancel (where No should be the default).
(In reply to Adalbert Hanßen from comment #0) > If I have a multilingual document with multilingual headlines, spell > checking in the headlines of the automatically generated table of contents > (TOC) should be off by default in the styles associated with the table of > content. So if I understand correct, the aim is to give an option to avoid spell checking in TOC. Please correct me, if I'm wrong. You made a proposal for that. Perhaps it is also possible to add a checkbox within the TOC dialog. cc: Design-Team for further input and decision
Yes Dieter, something to switch off spell checking in the TOC is one part of my proposal (among others). Presently one already can switch off spell checking in all styles associated with the TOC. Unfortunately it is a bit tedious because you have to set it that way for each level of a headline in the TOC separately. The most urgent part of my suggestion would even be quite simple to implement: One would only need to preset "no spell check" for the paragraph formats of the headings in the TOC. Digging a spade deeper, when setting the properties of hierarchically organized style sheet elements of headings in the document and those in the TOC, one would ask if what is set for font and markup (font, size, color, slant, boldness, language, etc) should also be applied to all levels below at the moment one sets that.
Since changing the content of fields is not possible neither ignoring the words in the document has an effect on the ToC, I agree with the request and would change the language for all "Index" styles to "None". This setting applies to all subordinated styles. Patch at https://gerrit.libreoffice.org/c/core/+/119222
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/137a1d5380e310a43d36932c643e1331a94fd70d Resolves tdf#143066 - Language set to None for indices It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/4b5dd477bbe1647c6c60374da2e4cabcf5b6b58b Resolves tdf#143066 - Language set to None for indices It will be available in 7.2.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #5) > Heiko Tietze committed a patch related to this issue. > It has been pushed to "libreoffice-7-2": > > https://git.libreoffice.org/core/commit/ > 4b5dd477bbe1647c6c60374da2e4cabcf5b6b58b > > Resolves tdf#143066 - Language set to None for indices > > It will be available in 7.2.0.2. > > ... Thanks, I have tested it and I am happy with the improvement. Unfortunately I came across another bug in the TOC, which I have reported as https://bugs.documentfoundation.org/show_bug.cgi?id=143589, since ti si not related to this one, which is an improvement rather than a bug. Thanks for providing the improvement!
(In reply to Adalbert Hanßen from comment #6) > Thanks, I have tested it and I am happy with the improvement. => VERIFIED FIXED
I'm going to revert this hack since it does not disable the spell-checking but sets the language to none. And this is discouraged by accessibility, see bug 145104.
Created attachment 176150 [details] Shows problems of accessibility test with mixed language documents This is the first occasion I see Accessibility check. Its purpose seems to be to enable screen readers to tell something on what is currently pointed to. I don’t know what the ODF norm tells about the meaning of “spell checking language”. Perhaps it is a misconception to use this to let a screen reader tool find out how it has to pronounce text. On the other hand, it might be a feasible choice to help disabled people. If one would support such “misuse” of something intended for a completely different purpose for the composer of a text rather than for the consumer of it, one would have to deal with it differently than at present: The language of every single part of any headline would have to be transferred to the corresponding words in the generated headline in the table of contents. Still: what should the language of the paragraph be? The paragraph’s language of the associated headline? Anyway, a reasonably constructed screen reader tool would not solely rely on the language of paragraphs but rather on the language of words (or even parts of words, to get along with mixed-language composites). But what is the language of mathematical text? What’s the language of bash code cited in a document? I always use some styles like character style Quelltext and I set it to “no spell check”. One would have to add a new category “no human language” to indicate: There is no spell checking available for this particular part of text and there is no screen reader language to speak this text other than spelling it. (Unfortunately I can not really imagine how I would understand this it I were blind: find . -printf "%p\n" | grep -e ".*\.pdf$"). The only help for a blind person would be: “this is a terminal command to list all pdf files with their relative paths from the current directory down the directory tree”. By the way: If a document contains an automatically generated table of contents (TOC), lots of accessibility test failures are flagged from the TOC, because the Links associated with the headlines spell different from the headlines themselves (which can not be circumvented, because a headline “conclusion” might appear e.g. at the end of each Section, subsection or so!) Perhaps the accessibility check might soon come close to a content check, if one would also demand that every text must also be non-discriminatory in terms of content according to criteria to be defined in more detail... Then one could no longer write a text that deals with such a topic with example and counterexample. It would amount to a ban on topics.
I’ve reverted this change, and as I explained in https://bugs.documentfoundation.org/show_bug.cgi?id=145104#c9, setting language to none in a default style is wrong. If we want a way to disable spell checking for parts of the document, we should provide something independent of the language.