Original Date of Publication

  • edited November 19, 2010
    Fully agree. To mount my own hobby-horse, I see a pattern here: all too often in Zotero development, essential and not so difficult-to-implement features are held back in anticipation of the Grand Final Featureset that will solve this and a thousand other things. From a user's point of view, Zotero could use more agile software development.
  • To be clear, I don't have a position on this. I'm happy to implement it if there's consensus that it makes sense to do so now, without hierarchical support.
  • edited November 19, 2010
    No, Zotero could use more developers. [Lest there be any confusion, this is in reference to mark's comment, not Dan's]

    That said, I've added original publication fields to the work in progress that is the 2.1 type and field changes whiteboard: https://github.com/ajlyon/zotero-bits/wiki/Zotero-types-whiteboard

    Your contributions and comments are welcome; just create a Github account and post here or send me a message. This is part of an attempt to create a short list of high-priority and highly necessary adjustments to the Zotero items types and fields, with the goal of getting the changes into the final version of Zotero 2.1. The core devs have committed to implementing well-considered changes to the system.
  • To be clear, I don't have a position on this. I'm happy to implement it if there's consensus that it makes sense to do so now, without hierarchical support.
    I'd just add it now. It's easy enough to convert to a more relational model.
  • edited November 19, 2010
    I'd just add it now.
  • +1 and sorry to be harping on issues that I cannot unfortunately help out with myself (being a mere scientist with no coding experience).

    @adamsmith, I agree — Zotero always needs more developers — but I do think it could use more agility also, particularly in cases were a quick fix makes users happy and doesn't stand in the way of a more complete solution later. This very issue is a good example. It can't be much more than an extra field in the UI and the DB and some links to the CSL processor; CSL has been able to handle it at least since August 2009. Why let users wait for so long? Duplicate detection is another example — had a simple fix preventing at least creation of duplicate items in local libraries in place from early on, the duplicate problem would not nearly have been as ugly as it is now for large libraries (even allowing for the fact that groups clearly do present new challenges).
  • hey, i didn't say anything! ;-)

    I actually agree with you on duplicate protection and this issue, but I think Zotero is pretty agile otherwise.
  • Zotero's development processes are quite agile, I'd say. Where there are bottlenecks, it's more a matter of developer bandwidth, the complexity of the problem that the software addresses, and the diverse requirements of the community that it serves -- and this thread itself shows that we're making progress against that tide.
  • (ah, I now see that my remark was aimed at ajlyon's "no", not adamsmith's post)
  • I have added a couple of instructions to the international organizations.csl to provide a temporary solution to the problem of citing original dates and ISBN numbers in bibliographies. It adapts the idea from mattsl. As a non-programmer I am offering something very simple. Perhaps someone can help give us something more sophisticated.

    I use the Publisher and Date fields in Zotero for the original. I put the name of the publisher and the date of the reprint in the Extras field.

    Then at the end of the bibliography section I add after <text macro="access"/>:_

    <text variable="note" prefix=". Reprint: " suffix="." />
    <text variable="ISBN" prefix=". ISBN: " suffix="." />
    (picking up as before)

    The first new line takes the info from the Extras field as the "note" variable, puts Reprint: before it, and a period after.

    The second new line takes the info from the ISBN field and formats it similarly.

    I am not sure whether this works in all styles but at least it keeps the info I need all in one place for the time when the style is updated as promised.
  • ISBN doesn't really fit here - it's already included and can be cited. If it should be included in an existing style, please report it in a new thread as stated here
    (for what it's worth ISBNs are not part of the IO style.)
  • Just another bump to keep this issue on the radar. I'm also not able to contribute any coding or anything, but it would be really great to see this feature included soon.
  • This is planned as part of the set of schema changes for, hopefully, Zotero 2.1.
  • That's great! And thanks for the quick response. Zotero continues to be the best bibliographic tool out there, hands down.
  • Zotero 2.1 has been released, but this feature doesn't seem to have been added. I've been waiting for it for several years now, and it's extremely inconvenient not to have it. Can we have a status update on its implementation?
  • Can we have a status update on its implementation?
    I'm not speaking for the devs but it should be added to Zotero 2.2 with other changes: http://forums.zotero.org/discussion/15636/1/changes-to-fields-and-item-types-for-zotero-22/
  • as for a status update - CSL 1.0 - which Zotero 2.1 uses - has support for
    # original-publisher
    # original-publisher-place
    # original-title
    # original-date

    so adding these is now more easily feasible and will likely happen whith the update that Gracile mentions (which may be 2.2 or 3.0)
  • Please, please then make sure the original-date"-field will be included in 2.2 -- this would be such a huge improvement to people (like me) working with the humanities and history!
  • Like mattsl I'm also having difficulty getting Zotero to display APA 6th citation of a republished book correctly, i.e. with something like (Original work published 1900) at the end of the reference item and e.g. (Freud, 1900/1953) in the text. [8.02 item 21 in the Concise Rules of APA Style].

    I gather from your discussion above that this will be fixed in version 2.2. Any idea when this will be? Any suggestions for a workaround that isn't completely manual?
  • 2.2 would still seem to be a bit out - certainly months.
    I believe there is a workaround, but I'd need to check on the details, so let me get back to you with that.
  • Did you get anywhere with the workaround?
  • edited May 24, 2011
    it looks like the workaround will be included in 2.1.7 - remind me once that version is out.
    edit: Which should be very soon, I believe.
  • edited May 24, 2011
    It's available in the branch XPI, if you'd like to try it. A few caveats:
    • As always, be sure to back up your data before installing new software, and especially before installing prerelease versions.
    • The workaround is intended for testing styles in advance of the appearance of appropriate mappings in Zotero; it is not meant to be, and should not be used as, a permanent solution in user data.
    • The workaround works only with ordinary fields and dates. It does not work for name variables.
    • Continuing support of this behavior in the processor is not guaranteed
    With those qualifications, it works by putting an entry like this in the Extra field:{:original-date: 1932-03-09}Note the colons on both sides of the CSL variable name.

    A list of valid CSL variable names is available here.
  • But just entering that variable won't make it appear - afaik the only style in the repository that currently has original-date is the new AAA style.
  • 2.1.7 is out: any news on the original date work around?
  • As I noted above, the syntax was introduced for testing purposes. It's working in current 2.1.8, but it is likely that it will be disabled in the next release.
  • Is there any progress on this? As far as I can tell, this basic feature has been just around the corner for 3 years now... :-(
  • well, the feature has been around the corner for about one year, i.e. since the implementation of csl 1.0.
    My understanding is that because of issues related to syncing (any change in Zotero fields means the syncing code needs to change) this will have to wait until 3.1, when it is going to be included with a whole range of other field updates.
  • edited October 6, 2011
    I'm using this info in my present work. And also, for the translations, the 'original title' the 'original edition', and the 'original language'.
    My Handbook of Style demands:

    Balz, Horst – Schneider, Gerhard, Diccionario Exegético del Nuevo Testamento (α-κ), vol. I, Salamanca 22001, (= Exegetisches Wörterbuch zum Neuen Testament, 21992).

    OR, the minimum is:

    Balz, Horst – Schneider, Gerhard, Diccionario Exegético del Nuevo Testamento (α-κ), vol. I, Salamanca 22001 (alem. 21992).

    The parenthesis + equal symbols refer to the original edition.
    The little number beside the year is the edition (2nd, in this case).
    The book is a translation from the second edition of the original in German.

    Presently I'm doing a very strange solution, puting this information in the URL [!] field and formatting it manually: (= <i>Exegetisches Wörterbuch zum Neuen Testament</i>, <sup>2</sup>1992)
    I've adapted myself the CSL.

    I know that that means nearly the complete register of the original book. That seems too much.
  • I work with Islamic sources which require that an individual citation has two dates - the original Islamic date and the Christian calendar equivalent.

    Just to make sure I understand the gist of this thread: (1) currently one cannot even include the Islamic date in parentheses in the date field; (2) there may be some sort of workaround, but those of us luddites who do not want to mess around with coding are out of luck; (3) this problem will be rectified in a future release of Zotero (3.1?), but whether this update is imminent or another year away is note entirely clear so I shouldn't count on it if I have any publication deadlines in the next couple of months.

    Is that about the size of it, or am I missing something? Absolutely love Zotero; looking forward to overcoming this problem so I can rely on it for tracking more than just secondary sources.
Sign In or Register to comment.