[Alexandria-list] CSV import

[Timothy Malone]

On Thu, 2008-01-31 at 20:09 +0000, Cathal Mc Ginley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 30 Jan 2008 11:46:42 -0500
> Timothy Malone <timothy.malone at gmail.com> wrote:
> 
> > I've been working on an import filter for CSV files and had a few
> > questions. The primary focus of my filter is the CSV format used by
> > goodreads.com (sorta like librarything).
> 
> Neat. LibraryThing import is also somewhere on our list of things to do.
> 

I've been meaning to look into LibraryThing. I saw that it was a
requested feature.

> >  I've got it working but was
> > wondering what the status of adding a "date read" entry to Alexandria
> > was. I searched the archives and noticed that it was mentioned a
> > little while ago but wanted to check and see if it was planned for a
> > future version, or if it was waiting for a bigger overhaul of the
> > book storage format.
> 
> The "date-read" issues was recently requested as a feature on the
> tracker [#17563]. This was my comment:
> 
> "This is a fairly common request on the mailing-list. It is one
> of the features planned as part of a new design for Alexandria
> which will support more complex data storage. We don't want to
> simply bolt-on support for this, we are instead trying to ensure
> that the redesigned system supports it properly. So it won't
> be added in the near future, unfortunately."
> 
> The thing is, adding a "date-read" field would change the data format
> again, without fully satisfying the requirements of people who want
> "Reading Management" capabilities - like the date you started reading,
> number of pages read... I think we need to do a bit of analysis first,
> so I put up a page on the wiki for users to add their requirements:
> 

That is a really good point. I did write a patch for the "Date Read"
field and it worked in all my testing with no compatibility problems, so
I ended up committing it (revision 892 I believe). Feel free to reverse
that if it was a bit premature. I hadn't considered the reading
management issue before. My two cents on it would be that it should be a
tab of its own (or plugin like the wiki suggests), but that "Date Read"
is used commonly enough that it should remain on the main properties
page.

> http://wiki.alexandria-projects.org/wiki/ReadingManagementRequirements
> 
> In the mean time, if you don't want to lose the "date-read" data you're
> importing, you can save it *informally* as a Note or Tag (this kind of
> thing is also mentioned on the wiki page).
> 
> > Also, I am considering changing the way Alexandria exports CSV to make
> > it more user friendly by adding labels at the top of the columns. Any
> > thoughts on that idea?
> > 
> Yes, this should make the CSV file more useful to users. I wonder
> though, should we translate the headings to the current LANG or leave
> them in English? There are two forces here: 
> 
>  * leaving them in English would make scripting easier, even if the
> CSV format were to change.
>  * translating them would make it easy for users to import an exported
> CSV directly as a spreadsheet.
> 

My thoughts on that are that it makes sense from a user's perspective to
output a translated version. It seems like when you take your data out
of a program and put it into a format that is essentially plain text and
is directly modifiable by the user, every effort should be made to make
the data as understandable as possible. If the labels inside the program
are labeled in the user's native language then it seems reasonable to
expect the output to be labeled in their native language as well.

Tim

> Leaving them in English works for now anyway.
> 
>    -   C.