Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Spreadsheet::ReadSXC and localization -- Google Sheets vs LibreOffice Calc

by vitoco (Hermit)
on Jan 11, 2020 at 15:27 UTC ( [id://11111329]=perlquestion: print w/replies, xml ) Need Help??

vitoco has asked for the wisdom of the Perl Monks concerning the following question:

Hi! I wrote a script that creates JSON files based on the contents of Google Sheets using Spreadsheet::Read and Spreadsheet::ReadSXC, which are previously downloaded into local files using HTTP::Tiny. All works nice, even when the localization of the Google Sheet is different than US in the formatting of numbers: in my case, comma is for decimals and period is for thousand separator.

But something wents wrong when I opened one of the downloaded ODS files with LibreOffice, edited some of the values and saved it again before procesing it with my script. The modified ODS file now gives floats with my localization standard!!! If I open again the ODS, I can see the values in my local format.

To check what is going on, I extracted the "content.xml" from both original and modified ODS files and compared a cell content. This is what I found:

Integer value (in a float cell):

- Google Sheet

<table:table-cell table:style-name="ce37" table:formula="of: +=[.D486]" office:value-type="float" office:value="2800" calcext:value +-type="float"> <text:p>2,800.00</text:p> </table:table-cell>

- LibreOffice Calc

<table:table-cell table:style-name="ce116" table:formula="of +:=[.D486]" office:value-type="float" office:value="2800" calcext:valu +e-type="float"> <text:p>2.800,00</text:p> </table:table-cell>

Float value:

- Google Sheet

<table:table-cell table:style-name="ce37" office:value-type= +"float" office:value="1138.85" calcext:value-type="float"> <text:p>1,138.85</text:p> </table:table-cell>

- LibreOffice Calc

<table:table-cell table:style-name="ce116" office:value-type +="float" office:value="1138.85" calcext:value-type="float"> <text:p>1.138,85</text:p> </table:table-cell>

As in the JSON file I must write numbers without the thousand separator, with ODS files just downloaded from Sheets, I had to remove the commas with a regexp, but in the ODS file that was modified by Calc, the regexp removes the decimal separator and multiplies the value x100!!!

So, it seems that cell and cellrow methods retrieves the value from the "text:p" tag instead of the "office:value" property of the "table:tablecel" tag. Format parsing in these methods seems to work only for dates and strings, but not for numeric values, .

Is there a way to process cell values in a "neutral" region, i.e. without localization?

Replies are listed 'Best First'.
Re: Spreadsheet::ReadSXC and localization -- Google Sheets vs LibreOffice Calc
by Corion (Patriarch) on Jan 12, 2020 at 06:54 UTC

      I didn't know about it. I've just checked the docs and it says:

      Only the contents of text:p elements are returned, not the actual values of table:value attributes.

      Then, I'll be just right now, no change... :-(

        At least the plan is to return the raw, unformatted value, but maybe the documentation needs some fixing in that branch as well.

Re: Spreadsheet::ReadSXC and localization -- Google Sheets vs LibreOffice Calc
by roboticus (Chancellor) on Jan 11, 2020 at 22:33 UTC

    vitoco:

    I can't answer your question, but looking at the data you posted, the value you're wanting is in the 'office:value' attribute of the cell, is there an easy way to access that instead of worrying about the formatted value and worrying about handling the formatting?

    ...roboticus

    When your only tool is a hammer, all problems look like your thumb.

Re: Spreadsheet::ReadSXC and localization -- Google Sheets vs LibreOffice Calc
by holli (Abbot) on Jan 12, 2020 at 02:31 UTC
    But something wents wrong when I opened one of the downloaded ODS files with LibreOffice, edited some of the values and saved it again before procesing it with my script. The modified ODS file now gives floats with my localization standard
    That's not really surprising isn't it? It has already been pointed out by roboticus that the "real value" is in the office:value attribute. What's in text:p is just a representation of it. So if you open a file and save it, then that representation will match whatever LibreOffice is currently set to.

    You can change settings like decimal point, thousands separator, currency symbols etc in the LibreOffice options under "Language settings -> Language".


    holli

    You can lead your users to water, but alas, you cannot drown them.

      What it is surprising is that Google Sheets does not save the file with the current settings as LibreOffice does, if that is the standard. Or it is the opposite? I tried to find this in the ODS file format specs but I couldn't find any reference about it.

      Changing the localization of my LibreOffice setup before saving the document is a workaround I'm not sure to take as normal. Google Sheets is clearly saving a "cannonical" version of the value in "text:p" tag, and Libreoffice is reformating that field at open time, but at save time it keeps the new localizated format there. What I haven't tried is to upload a LibreOffice modified document back to Google Sheets... What should I expect there?

        Let's take a step back.

        - Where are the Google documents coming from? As in, how do they get created? And
        - What do you want to do with them after download? Or, what is your workaround actually for?


        holli

        You can lead your users to water, but alas, you cannot drown them.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://11111329]
Approved by haukex
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2024-04-25 05:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found