Is there a particular reason that the Google sheets extension will not use the language code as the CSV extension does in order to find language columns (or using a custom column header)?
I understand this would likely mean reading in the first row and parsing out what the correct column indices are but this would make adding, removing, or reorganizing google sheets a lot less prone to breaking import.
Hi,
How are you syncing with Google? Are you doing it through script or with the Editor Extension?
Column names are not available in CSV so we had to go with the names which is also prone to breaking if someone changes the name slightly. We wanted to avoid pulling the entire Google Sheet when doing a sync, with the column names we can tailor the request so we only get the data we care about returned.
We do have an option to extract them using the column headers
We could look at adding an option to read the column headers each time you push/pull and then map them across to the correct column names.
Currently using the default extension on a table, nothing fancy. And yes, I understand that adding the columns initially is not difficult. But since the columns themselves are just “A”, “B”, “C”… “AAA” and a designer could easily move them around to make it more convenient for them, this becomes an issue.
As mentioned, you don’t need to pull the whole sheet. I understand that right now you are pulling ranges instead of everything and the same could (I believe?..I’ve not worked that much with the Sheets API) done for retrieving the first row and parsing out the language columns indices by looking at their contents instead.
As a programmer, the design doesn’t bother me that much. But as someone who has written localization tools in varying iterations for 15 years… not having to worry that one designer change will break it would be a good thing.