Bug 115298 - Locale information is wrong when LibreOffice optimizes them from span to paragraph
Summary: Locale information is wrong when LibreOffice optimizes them from span to para...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, dataLoss, regression
Depends on:
Blocks: Paragraph Save
  Show dependency treegraph
Reported: 2018-01-29 14:14 UTC by Christian.gruemme
Modified: 2022-09-14 03:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

the document carrieng the spans (9.07 KB, application/vnd.oasis.opendocument.text)
2018-01-29 14:15 UTC, Christian.gruemme

Note You need to log in before you can comment on or make changes to this bug.
Description Christian.gruemme 2018-01-29 14:14:22 UTC
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
Comment 1 Christian.gruemme 2018-01-29 14:15:30 UTC
Created attachment 139435 [details]
the document carrieng the spans
Comment 2 Christian.gruemme 2018-01-29 14:15:54 UTC
Comment on attachment 139435 [details]
the document carrieng the spans

This is a test case.
Comment 3 Buovjaga 2018-02-17 15:20:54 UTC
Yep I see

<style:style style:name="T1" style:family="text">
    <style:text-properties fo:language="none" fo:country="none" />

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>

This actually does not happen in 3.6.

Arch Linux 64-bit
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 (Build ID: e183d5b)
Comment 4 Buovjaga 2018-02-17 17:19:26 UTC
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" />
Comment 5 Buovjaga 2018-07-10 19:05:33 UTC
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

    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
Comment 6 QA Administrators 2019-09-02 09:26:03 UTC Comment hidden (obsolete)
Comment 7 Regina Henschel 2020-09-12 22:38:04 UTC
The problem still exists in Version: (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.
Comment 8 QA Administrators 2022-09-14 03:37:51 UTC
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