Created attachment 100161 [details] 3 lines each with a different language setting Clear direct formatting does not clear language specifications made within the text. 1. Open the attachment 2. Select All (Ctrl+A) 3. Clear direct formatting (Ctrl+M) Actual Result: Text in bold is removed, but each line withholds its set language setting Desired Behaviour: that the language setting is set to the language of the default style.
Can you explain what you mean by "this line is set to X" - how do you set each individual line. In the future please provide detailed steps on how to reproduce the problem along with the sample document. Marking as NEEDINFO - once you provide a full explanation mark the bug as UNCONFIRMED. Thanks For what it's worth - I have never seen a per line setting and I don't think that the language is set in the styles so clear direct formatting would have no affect.
Sorry, i tried to be concise, but i was too concise! A) "This line is set to X" means that I had set the language for that text to "X" B) To change the language: 1. select the text 2. change the language (the bar at the bottom of Libreoffice, where there is the zoom size) C) Language settings can be given also to single words or to a group of paragraphs. I do not know how it is set internally but I think that on CTRL+M the selected text should return to the language of the stylesheet (Each stylesheet can be assigned a language from the FONT TAB). I have noticed that if I use "clear formatting" from the FORMATTING TOOLBAR the language does reset to the default language. Steps to reproduce the bug: 1. Write a line of text, eg "Text 1" 2. Write another line of text, eg "Text 2" 3. Write another line of text, eg "Text 3" 4. Select one line and change the language to "Italian" 5. Select another line and change the language to "French" 6. Select all text (Ctrl+A) 7. Clear direct formatting (Ctrl+M) Actual Result: Each line withholds its set language setting Desired Behaviour: that the language setting is set to the language of the default style.
Thanks for the perfect steps - investigating now :)
Confirmed in Linux Mint in 3.3.0, 4.2.4 and 4.3 beta. @Michael: Should the clearing of formatting also clear language formatting?
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.1 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
I have tested it on LibreOffice Version: 5.0.0.0.beta1, Win 7, x64 The bug is still present The question posted by Yousuf Philips has still not been answered officially: "@Michael: Should the clearing of formatting also clear language formatting?" For me personally it should since I would like to 'reset' all settings and get them in line to the default stylesheet but an official decision should be taken about the issue.
Lets get ux-advise about this. So the question is: Should the clearing of direct formatting (Ctrl+M) also clear language formatting?
I wouldn't do so. The use case is to format passages in a written document, e.g. as some kind of a note or to show relevant parts to colleagues, and to remove that formatting afterwards. Language isn't affected by those actions. That means text written in English instead of the native language wouldn't change it's origin in any condition. Another con argument: if language was part of the paragraph or character style it makes sense to handle it as any other property. But it isn't.
(In reply to Heiko Tietze from comment #8) ... > Another con argument: if language was part of the paragraph or character > style it makes sense to handle it as any other property. But it isn't. Well language setting can be set in paragraph styles as well as character styles. You find the setting on the tab Font if you modify a paragraph or character style. So to me it makes perfect sense to reset the language to whatever is set in the style in use, in other words if the language has been applied as with the means of direct formatting it should be cleared by pressing Ctrl+M.
(In reply to Niklas Johansson from comment #9) > You find the setting on the tab Font if you modify a paragraph or > character style. Touché! So for sake of consistency it makes sense to clear the direct language setting.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
The issue is still there and has the same behaviour LO Version: 5.2.1.2 Win 7 64-bit
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
Problem still present on Version 5.4.1.2
same behaviour on LO 5.3.6 Win 7 64-bit
Back in OpenOffice.org times, when (IIRC) Michael Bauer worked on the menu Tools > Language, he explained that language was not a property of text, but that for reasons ... it was in the character dialog. I never searched for specific info, but that might very well be the explanation of the situation.
so that my be ground to reconsider the first part of the argumentation in comment #8
and where clear direct formatting is needed to resolve problems cause by uneducted use of formatting/too much direct formatting, changing a language to the wrong one, is just vandalism :D So if you are repairing formatting trouble, and in the same action remove a good language setting, that is not helpful. So I would say: NotABug. (Mind: personally I do make use the language setting of the font in styles!)
(In reply to Cor Nouws from comment #16) > Back in OpenOffice.org times, when (IIRC) Michael Bauer worked on the menu > Tools > Language, he explained that language was not a property of text, but > that for reasons ... it was in the character dialog. > I never searched for specific info, but that might very well be the > explanation of the situation. I'm not an ODF expert (far from that), but if I build a document with a particular paragraph style on an alien language like, say, English ;) and then unpack the resulting odt file to open style.xml on a text editor I can see something like this <style:style style:name="my-english-text" style:family="paragraph" style:parent-style-name="Text_20_body"><style:paragraph-properties style:writing-mode="page"/><style:text-properties fo:language="en" fo:country="US" style:font-size-asian="10.5pt"/> ... So language is one of the first properties defined on a style. Applying a language through direct formatting ignores the style definition so not cleaning it when "clean direct formatting" is issued is, IMO, against the idea of using styles.
Have to agree with RGB as if the language is set at the direct formatting character-level, then clear direct formatting should remove it.
Styles are here to serve us. I doubt if that is the case if we remove language settings with clear direct formatting. That looks more like style police :) I'd like to see more opinions and would appreciate search for expert input (see my comment #16)
Michael, your expertise is required.
(In reply to Cor Nouws from comment #21) > Styles are here to serve us. I doubt if that is the case if we remove > language settings with clear direct formatting. That looks more like style > police :) Sorry, but I do not understand your comment here. Nobody is talking about removing language settings rightfully defined on a style, but about removing language settings applied as direct formatting on top of a well defined style. "Remove direct formatting" means exactly that: remove formatting applied directly that overwrites what's defined on the base style. And that includes the language. If on top of a text with a paragraph style whose language is "Spanish" someone applies as direct formatting the language "Portuguese", the option to clear direct formatting should clean the language applied as direct formatting in the same way italics or bold are cleaned: to restore what the style says. IMO that's not "style police", that's just the use of styles as they are intended to be used.
(In reply to RGB from comment #23) > Sorry, but I do not understand your comment here. Nobody is talking about > removing language settings rightfully defined on a style, but about removing > language settings applied as direct formatting on top of a well defined > style. Maybe you can read the various comments again, that give reasons to consider that maybe in this case another choice can be good.
How about a quick poll on G+ what the community thinks?
(In reply to Cor Nouws from comment #24) > (In reply to RGB from comment #23) > > Sorry, but I do not understand your comment here. Nobody is talking about > > removing language settings rightfully defined on a style, but about removing > > language settings applied as direct formatting on top of a well defined > > style. > > Maybe you can read the various comments again, that give reasons to consider > that maybe in this case another choice can be good. I read the other comments before answering and then I provided my view on this issue as someone who writes and shares documents on three languages on a regular basis. Clearly we have different opinions on this topic and that's fine. Let's see what other people have to say.
(In reply to RGB from comment #26) > I read the other comments before answering and then I provided my view on > this issue as someone who writes and shares documents on three languages on Sorry, but then I do not understand your comment that you do not understand my comment.
(In reply to Heiko Tietze from comment #25) > How about a quick poll on G+ what the community thinks? Not needed. Clear direct formatting removes direct formatting and if language is set at the direct formatting level, clear direct formatting clears it. Its as simple as that. Cor must seem be misunderstanding the issue. If i select some text, and Ctrl+B, it adds bold at the direct formatting level, and Ctrl+M will remove it, so in the same way if i open the character dialog and change the language of the selected text, Ctrl+M should remove it.
(In reply to Heiko Tietze from comment #25) > How about a quick poll on G+ what the community thinks? When people start to educate me on styles :D that may be a wise thought indeed.
Both opinions highly appreciated by me, and both looks right, so seems both are needed. A solution can be while keeping the current "clear direct formatting" adding a new one "reset to character, paragraph, list and table styles" clearing everything not only format attributes, perhaps there are more settings than language involved.
Sorry @Yousuf, have you teste, not for me with Version: 6.0.0.0.alpha0+ Build ID: ccb1894c02d77ed89741ca1f82bad87a17fd76fa CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: es-ES (es_ES); Calc: CL
(In reply to m.a.riosv from comment #31) > Sorry @Yousuf, have you teste, not for me with Gotta love typos. Comment 28 should have read "Clear direct formatting removes direct formatting and if language is set at the direct formatting level, clear direct formatting *should* clear it. Its as simple as that. Cor seems *to* be misunderstanding the issue." So i checked out the XML of some text that was set to french and here is the relevant parts in content.xml <office:automatic-styles> ... <style:style style:name="T2" style:family="text"> <style:text-properties fo:language="fi" fo:country="FI" /> </style:style> ... </office:automatic-styles> <office:body> <office:text> ... <text:p text:style-name="Standard">LibreOffice is <text:s /> <text:span text:style-name="T2">the greatest</text:span>software</text:p> </office:text> </office:body> So all that is needed is for .uno:ResetAttributes to remove the fo:language and fo:country attributes of character and paragraph level direct formatting, similar to what happens when you click the 'Reset to Default Language' context menu entry in the text language field of the statusbar.
(In reply to m.a.riosv from comment #30) > A solution can be while keeping the current "clear direct formatting" adding > a new one "reset to character, paragraph, list and table styles" clearing > everything not only format attributes, perhaps there are more settings than > language involved. I'm against a new function. Users would have to understand the reasoning behind the difference to CF and I doubt that. Even me following this thread don't understand what "Reset to character style" would mean for standard formatted text (guess nothing). When it comes to interaction we should rather think about expert workflows with double- or ctrl- click on clear formatting, or the like.
** Please read this message in its entirety before responding ** 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 http://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
Problem still present in 6.1.2
Bug present in LO 5.4.7.2 (x64)
So I re-read the issue (more or less) and think with a changed summary, it is good to see what UX can decide. (Then hoping that it is technically feasible too)
Both behaviors have their positive effects. As style user I principally support the enhancement request. But my experience is that I never created own character styles for words in other languages than the other text has (maybe because it wasn't necessary today as Ctrl+m ignores language settings). If the majority prefers the here suggested way, then the change only should be implemented AFTER fixing of enhancement request in bug 35186 (especially see bug 35186 comment 13). Paragraphs incl. styles are lacking language information therefore fixing this would have some side effects for many users. This was also mentioned in comment 16 here. As I stumbled over the problem to not be able to "reset" language information to the setting in the paragraph style, I suggest a middle way: Add a real Ctrl+m-like command for resetting language setting in the language chooser menu in the status bar. This wouldn't clutter other places of the UI with new or extended commands e.g. what was suggested in comment 30.
We talked about this request in the design meeting. And while it makes a lot of sense to handle the language as just like any other property there are strong arguments against: a) it's not a visual property, b) we have options to reset to default (tools > options > language > * > reset or via statusbar) c) resetting the langauge returns English if users haven't modified the default style (bug 35186) So the resolution is NOTABUG (actually WORKSFORME).