Description: When there is the situation, that there are several text:spans carrying the same locale information. LibreOffice moves the locale information from the text:spans to the parent paragraph. This is fine, but LibreOffice sets the locale information of the text:spans to "none" instead of removing it. Then there is no correct locale information on those text:spans resulting i.e. in non correct hyphenation and spell check. Steps to Reproduce: 1. Save the attached document and look in the "content.xml". Note that the spans carry the french locale information. 2. Open the document with the writer and save the document again. Now take a look in the "content.xml" again. Note that the spans carry the "none" locale information. Actual Results: Text style has locale value set to "none". Expected Results: Text style has the french locale or no locale. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: The best would be when libreoffice optimizes the locale information to remove the "fo:country" and "fo:language" completly instead of setting them to the value "none". User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36
Created attachment 139435 [details] the document carrieng the spans
Comment on attachment 139435 [details] the document carrieng the spans This is a test case.
Yep I see <style:style style:name="T1" style:family="text"> <style:text-properties fo:language="none" fo:country="none" /> </style:style> and spans using the style <text:p text:style-name="P1"> <text:span text:style-name="T1">Popotan </text:span> <text:date style:data-style-name="N79" text:date-value="2018-01-17T11:37:27.375999949" text:fixed="true">mercredi 17 janvier 2018</text:date> <text:s /> <text:span text:style-name="T1"> <text:s />est un visual novel de type eroge japonais développé par Petit Ferret, avec pour designer Akio Watanabe dessinant sous le pseudonyme de Poyoyon Rock.</text:span> </text:p> This actually does not happen in 3.6. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: 26783527823883ccd5bbf3b9e014a0a3c1e3a022 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on February 16th 2018 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Hmm, tested with 4.3.0 beta1 and it changes the locale to en-US <style:style style:name="T1" style:family="text"> <style:text-properties fo:language="en" fo:country="US" /> </style:style>
Bibisected with Linux 42max. Unfortunately there were lots of skipped commits due to refusal to launch and a peculiar case where the file opened with missing data. Git finally regurgitated a list of 52 potential bad commits. I edited the list so it had "git log" at the beginning of each line and then triple-click copied & pasted and examined each and every commit. The suspicious commit was of course the last one I checked: commit d23fb81d81dd4bddd1ddb095fae729a7e10e249f Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Sep 5 18:57:48 2015 +0800 source-hash-4935422b410757bb4920b98a2d81da3c11b8e3d7 commit 4935422b410757bb4920b98a2d81da3c11b8e3d7 Author: Eike Rathke <erack@redhat.com> AuthorDate: Tue Jul 9 15:48:10 2013 +0200 Commit: Eike Rathke <erack@redhat.com> CommitDate: Tue Jul 9 15:52:21 2013 +0200 read/write ODF *:script* and *:rfc-language-tag* This prepares to be able to read/write the attributes, it does not enable proper handling of unknown language tags yet. An unknown tag usually falls back to SYSTEM locale. Adding Cc: to Eike Rathke
Dear Christian.gruemme, 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
The problem still exists in Version: 7.1.0.0.alpha0+ (x64) Build ID: 1e0cfd5662d95cea84e80e4fe10d52c3b1101ae6 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL But the bug is not related to ODF. Original and resaved files are valid ODF. Therefore I remove blocks 108198.
Dear Christian.gruemme, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug