https://bugs.documentfoundation.org/show_bug.cgi?id=125137
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- Ever confirmed|0 |1 --- Comment #15 from [email protected] --- It does not work exactly this way in my Calc. Here is what I do: A1==pi() B1==TEXT(A1;"0.00") C1=="<circle cx='8' cy='9' r='"&B1&"' />" A1, B1 and C1, they all show decimal commas, not point. Even if I format all the three cells via Format -> Cells -> Numbers -> Language to English, the commas remain. As @Leyan mentioned, I need to do a manual refresh to enforce the decimal _point_ to appear. This is not a big deal, I could live with this. But my original problem was how much work is needed to fix a spreadsheet. My original SVG example was a simplified example. It is quite easy to imagine a spreadsheet that has much more complex relationships between various cells located on different worksheets. Let me show another example, which is just slightly different from my original one. Let's say the author produces this spreadsheet in order to create SVG circles from a given diameter and then they want to parse the computed radius via regular expression: A1=3.8 B1=="<circle cx='8' cy='9' r='"&ROUND(A1/2;1)&"' />" C1==REGEX(B1;"r\=\'[0-9.]+\'") D1==MID(C1;4;LEN(C1)-4) You can ask why the author made it this way, rather than computing the radius in B1 and use it in C1. It can have several reasons: laziness, incompetence, historic reasons, other systems are depending on the existing columns, etc. Spreadsheets are not always suboptimal. If this spreadsheet is opened in an English LO, the parsed radius is displayed nicely. However, if I open it in a non-English Calc, you will see "#N/A" errors in D1 and E1 because the decimal value the regexp looks for, does not exist in the string. In order to understand why it doesn't work, - I need to understand what the purpose of the cells E1 and D1 are, - I need to be aware that a localisation problem can cause the failure in LibreOffice In order to fix it, - I need to add the extra column to do the TEXT conversion, E1==TEXT(A1;"0.0") - I need to change the formula in B1 to use the value from E1 instead of A1... - Oops, it doesn't work, E1 is already a text, I cannot use it in computations, so I need to move the computation from B1 into E1. E1==TEXT(ROUND(A1/2;1);"0.0") - Oops, there is a funny thing. For some weird reason, ROUND("1.9",2) is 22103 (honestly, WHY???:)). - I also need to format all the important cells, including the newly created one to language=English - Still wrong? Never mind, just press Shift+Ctrl+F9 After this, the D1 cell will show the correctly parsed rounded radius. It works how the author planned. A long story short: figuring out why the spreadsheet doesn't work is not easy. But fixing it is even more complicated, even in this very simple case. If there are more complex computations, it can be a huge task. Most of the users would say: - "the author sent me a wrong spreadsheet" (and the author would say the other party cannot use LO) - LibreOffice is baaad. What works for them, doesn't work on my computer. Most of the users wouldn't work so much on a spreadsheet. They would just simply be unhappy and frustrated. By contrast, if Calc would tell them when they open the file: "The file has been created in English but your system is Hungarian. Some computations can work unexpectedly. Do you you want to open it in English or Hungarian?" Well, in this case the user could have a guess what is going wrong and they could simply reopen the file with the original language settings. I reopen it because I hope you will reconsider this. -- You are receiving this mail because: You are the assignee for the bug.
