This Issue was found in Version: 5.1.6.2, Build-ID: 1:5.1.6~rc2-0ubuntu1~xenial4, CPU-Threads: 4; BS-Version: Linux 4.4; UI-Render: Standard; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group and also in LibreOffice Writer Version 6.1.2.1, Build ID: 65905a128db06ba48db947242809d14d3f9a93fe, CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gt but it is likely to be present in other versions too. BTW: I can not select version 6.1.2.1 in the drop down list of the bug reporting software. I have a multilingual document. In order to set the language of some paragraphs, I select them with the mouse. After selecting text I set the language for those paragraphs e.g. to English(US). However, this setting does not work as expected. If my selection spans more than one paragraph, setting the new language only affects the last one. Fortunately setting affects the whole last paragraph, even if it is only partially selected. I don’t mind that whole last paragraph is set to the new language, but I expect this operation to work as if the whole paragraphs with at least one character marked in them is set to the new language if my selection spans more than one paragraph. One should be able to set the language for more than one paragraph in one step. Similar critics also applies to setting the language for selection only: I expect that prior to actually applying the new language, the current selection is automatically extended to cover whole words (at both ends of the selection) because language is a property of at least words, not parts of them. To prevent any ambiguity for the user I propose to visually extend the selection during this process and leave it afterwards such that the user sees what LibreOffice Writer does when setting the language for some selected part of a document. One more proposal (which goes beyond fixing this bug): There should be a function associated to a selection, let’s call it “extend selection”, which extends the selection to all involved words if the current selection is less than a paragraph. This function should be callable through the context menu of the current selection (like Cut/Copy/Paste/Paste Special/Character/Paragraph/Bullets/...). If the current selection covers more than one complete paragraphs the extended selection should first cover the whole paragraphs (if necessary extending at both ends of the selection to the paragraph beginning and the paragraph end). If it is applied to whole selected paragraphs, the extension should expand to all neighboring paragraphs using the same style. In a document with text and headlines marked properly with a style sheet, this one would select e.g. all text under a specific headline (unless there are paragraphs using other styles arranged under the same headline – in this case I would propose one more step of “extend selection” to select everything up to the next level of headlines etc. But this part of my post is just a future usability improvement not my bug report itself. But there already must be some function “extend selection”: If I double-click on a word, the whole word is marked. If I triple click, the whole sentence is marked. If I quadruple-click, the whole paragraph is marked. The quintuple-click seems to be not yet implemented, however: This one would mean: extend to all neighboring paragraphs using the same style and so on.
It is true Tools - Language - For paragraph behaves like that. I had not paid attention to how exactly it is set and it looks like it changes the direct character formatting. Tested on 3.3.0 (Win 10) and seems it has always behaved like this. A more elegant way to change it for multiple paragraphs currently is to set it in the paragraph style. See https://helponline.libreoffice.org/latest/en-US/text/shared/guide/language_select.html "Selecting a language for a Paragraph Style" or edit a style from the Sidebar. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 750ccfb2a60582a5652c08f3cbb6f11d4c152275 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3_kde5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 22 November 2018
I had no doubt that it has been like this in all previous versions. Thank you for the hint of using different styles for different languages. I did not know about that. But that's not really a workaround because it blows up the number of styles because you need a complete set for every languages you are working with. If you are using LO a lot and deal with more than two languages, this becomes very cumbersome. The bug should be corrected at its root. The currently implemented functions accessible to the user just don't do what they promise to do.
Today I tried a daily build version, in particular I tried Version: 6.3.0.0.alpha0+ Build ID: aa31976c2e4399a86bc6f70f140972d9ccef6fc0 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-02-12_16:47:45 Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded and I was able to set the language for a selection spanning several paragraphs completely by Tools>Language>for Selection>English (and it did what I wanted). When repeating the same procedure for the same selection, the check-mark in that dialogue was set for English afterwards. However trying to set the language for the same selection by Tools>Language>for Paragraph>English the language was not changed and repeating the same dialogue, the check-mark at English was not set (indicating that the feature had not been set). Although this is only superficial testing, it looks to me that this bug might be partially fixed in that version, however half of the bug still remaining (i.e. for paragraph).
Today I tested the bug again in LibreOfficeDev Version: 6.4.0.0.alpha0+ Build ID: 0328e0af9532d5ab26840cf58b9dcbb69bb8c33d CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-06-28_14:36:08 Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded I marked a text portion spanning several paragraphs. I used Tools>Language>for Paragraph. No language carried a checkmark at that state of my testing. Then I continued such that finally I checked Tools>Language>for Paragraph>English (USA). But this did not change the language: Everything was still underlined with red curly lines indicating typing errors. I checked, if the checkmark for the paragraphs being English (USA) was set: No, it was not, no checkmark on any language in Tools>Language>for Paragraph. Then I repeated my trial with the selection only spanning one paragraph or less and that worked such that the content of the whole paragraph was turned to English (USA). After this, I checked if the checkmark for English (USA) was set fpr that paragraph: No, it was not set. No checkmark at any language in Tools>Language>for Paragraph. Trying to find more about this glitch, I checked several parts of the paragraph to which I had applied Tools>Language>for Paragraph>English (USA), but I checked the properties of the marked test portions with Tools>Language>for Selection. This showed me that the whole content of the paragraph had been turned to English (USA), but as characters, not as a paragraph. Preliminary Conclusion: a) EITHER the language flag is a property of characters rather than a property of paragraphs. b) OR there is a language flag which can be associated to paragraphs, but it is handled by setting this flag to the characters in the selection and the whole surrounding paragraph in which it is located. I don't know enough about the underlying data structures. At least, the function is not properly implemented in the case for a selection spanning more than one paragraph if a) is true and the option to apply a language to a paragraph is meant as "extending the selection to the involved paragraphs first, if necessary". My proposal aa) for case a): In this case the option to assign a language for a paragraph should EITHER be removed, since there is nothing to associate a language to a paragraph OR ab) (still for for case a): it should be implemented to also work, if the selection spans more than one paragraph: extending to all associated paragraphs. bb) for case b): If the data structures are such that they apply a language to characters and to paragraphs, the hierarchy of those settings should be explained in the help function and the function should be applied accordingly. The current user interface at this point is just anti-logical (since it works for less than one paragraph extending but does not work at all, if the selection extends across paragraph bounds). It just surprises the user. Sometimes he is happy, sometimes he is unhappy. But the user does not know about it ahead (unless he has spent as much time as I did to find out when it works and when it doesn't). Probably removing the option to set the selection for paragraphs is the quickest one to implement. It has the advantage to make the program more logical to use and less "mystic exceptions" to learn for a beginner.
Dear Adalbert Hanßen, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug