Created attachment 164666 [details] Screenshot of the problem in Writer This is followup to bug #123389 Attachment #163977 [details] demonstrates Word table formula made with German locale where decimal separator is comma. This is incorrectly parsed in Writer, leading to ** Expression is faulty ** errors in the cells with ROUND(2,345;1) and A1 *10,1 formulae. Steps to reproduce: 1. Open Attachment #163977 [details] in Writer Actual results: ** Expression is faulty ** error in D3 and D5 Expected results: Correct formula calculations. Currently changing the decimal separator to dot from comma fixes the forumlae, but this should happen automatically depending on the locale specific decimal separator. LibreOffice details: Version: 7.1.0.0.alpha0+ (x86) Build ID: a06a83b29a9da770787bffe416b138102aa12531 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: de-DE (hu_HU); UI: en-US Calc: CL
Does this mean that it should take "/w:settings/w:decimalSymbol" from word/settings.xml into account maybe?
(In reply to Mike Kaganski from comment #1) But Word doesn't seem to depend on that setting itself...changing it in the file does not make it open the formula wrong (and updating the fields works). OMG! It's a huge mess! Setting my system locale to en-US, and opening the (unmodified) document in Word, then updating fields, results in "!Syntax Error, ;" in the cell. So the OOXML so-called "file format" again is not self-contained, and such files are only correctly usable on the system that had created them...
(In reply to Mike Kaganski from comment #1) > Does this mean that it should take "/w:settings/w:decimalSymbol" from > word/settings.xml into account maybe? I don't have the latest build of LO installed on the machine I am currently using, so I have not attempted to open the attachment. I will say that in my patch I made it read the decimalSymbol from the settings file, so that is available. However, at the time (and still today) I wasn't sure how to get the decimal symbol of the user's current locale, so I did not attempt to convert that symbol if a user in one locale opens a document created in another locale. I wrote this in the commit notes for the patch. I'm happy to circle back around to that eventually, if nobody else gets to it sooner. I've just been a bit busy at work lately.
(In reply to Michael Warner from comment #3) > However, at the time (and still today) I wasn't sure how to get > the decimal symbol of the user's current locale, so I did not attempt to > convert that symbol if a user in one locale opens a document created in > another locale. Maybe LocaleData Service [1] could be helpful? [1] https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1i18n_1_1LocaleData.html
This issue got fixed by author Miklos Vajna <vmiklos@collabora.com> 2020-11-11 14:31:18 +0100 committer Miklos Vajna <vmiklos@collabora.com> 2020-11-11 22:40:41 +0100 commit 1abf4e6d07ca0ac31bc54f812df84efc82d2af1b (patch) tree 40053fb54077d81a94f273a3adb9660aea09068b parent 6ab5c9e99dccec23a80eb1980dc46986b8c5abca (diff) DOCX import: don't throw away cached value of SwHiddenTextField ... @Miklos, thanks for fixing this issue!!
Verified in: Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: aa9cb8e14749e7fb7a83b55a2bb095501f731a18 CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded