Upgrade StorageColumn numbers instead of page numbers in bibliography
In short, how can I tell Zotero that the numbers in the Pages attribute of an item represent column numbers?
Some reference works in foreign languages number columns instead of pages, and must therefore be cited by column number instead of page number. This is not a problem for citations, because Zotero lets me choose "column" for the reference. Thus I can get this, which is correct:
J. GRIBOMONT, Girolamo, in Nuovo dizionario patristico e di antichità cristiane, ed. by A. Di Berardino, Marietti, Genova, 2008, col. 2268.
However, in the bibliography I get this, which is wrong, because it uses "p." instead of "col.":
GRIBOMONT J., Girolamo, in Nuovo dizionario patristico e di antichità cristiane, edited by A. Di Berardino, p. 2262–2268, Marietti, Genova, 2008.
This is, by the way, with my own style. The "p." is what I get from
This makes sense, because I never told Zotero that the numbers in the "Pages" attribute of the item are really column numbers. How do I do that? If I type "col. 2262-2268", I get "p. col. 2262-2268".
Some reference works in foreign languages number columns instead of pages, and must therefore be cited by column number instead of page number. This is not a problem for citations, because Zotero lets me choose "column" for the reference. Thus I can get this, which is correct:
J. GRIBOMONT, Girolamo, in Nuovo dizionario patristico e di antichità cristiane, ed. by A. Di Berardino, Marietti, Genova, 2008, col. 2268.
However, in the bibliography I get this, which is wrong, because it uses "p." instead of "col.":
GRIBOMONT J., Girolamo, in Nuovo dizionario patristico e di antichità cristiane, edited by A. Di Berardino, p. 2262–2268, Marietti, Genova, 2008.
This is, by the way, with my own style. The "p." is what I get from
<label variable="locator" form="short" plural="never"/>This makes sense, because I never told Zotero that the numbers in the "Pages" attribute of the item are really column numbers. How do I do that? If I type "col. 2262-2268", I get "p. col. 2262-2268".
b) the only way to handle this that I can think of is to include col. into the page field in Zotero and then to test whether the field is numeric or not and only insert the label when it is, i.e.
<choose><if is-numeric="page">
<label variable="page" form="short" suffix=" "/>
</if>
</choose>
b) I can do that in my style, but if Zotero/CSL is unable to represent the fact that some reference works number columns instead of pages, I think its data model needs to be expanded. Numbering by columns is fairly common in dictionaries or encyclopedias in other European languages. Offhand the Dictionnaire de Théologie Catholique, the Lexikon für Theologie und Kirche, and the Biographisch-Bibliographisches Kirchenlexikon come to mind.
I suppose my only argument is that it's inconsistent to allow the use of "col." in a locator for a citation but not in the "pages" for a bibliography entry.
Implementing this would be a pretty significant undertaking and I'd want to know that using column ranges to cite a work in a bibliography is actually done before I suggest this. It'd be very much possible that people don't provide any range - column, page, or otherwise - for the above encyclopedias in the bibliography.
At a minimum I'd want to see examples of citations doing that in a major journal or a book published by a major publisher.
Just two examples: On this page, http://books.google.com/books?id=fpgV5xtlT0oC&pg=PA708, from the references section of a de Gruyter book, "Sp." occurs repeatedly, and a booklet of guidelines, "Zitat und Manuskript" by Schäffer-Poeschel Verlag, http://www.schaeffer-poeschel.de/download/zitat/zitat_und_manuskript.pdf, describes the use of "Sp." explicitly. Would that be enough to convince you?
(again, though, even if everyone agrees with this, it won't happen quickly).
If found a way to workaround the problem. Given that, there are few chances to need in the same style long and short form of the "page" term, i use long form for "p." and "pp." and short form for "col." and "coll." And I put this in the locales.
Here's the code (don't know how to put it in yellow) :
<term name="page">
<single>p. </single>
<multiple>pp. </multiple>
</term>
<term name="page" form="short">
<single>col. </single>
<multiple>coll. </multiple>
</term>
Any plans to implement this?
Any plans on the CSL-m side? I don't have references that need to be specified with col. in bibliography, but access to the locator variable in bibliography will open up some interesting possibilities.
We're talking about making additional variables for things like column ranges available both in the Zotero interface and in CSL bibliographies, since items have, e.g. column ranges instead of bibliography ranges. Those would still be entered in Zotero proper and be entirely separate from the locator variable, which is entered for each citation. We're talking about "locators" on the ticket because the additional variables that we may need for the bibliography would likely be similar to what we currently offer as locators.
Frankly, I think you're approach to ask about features to facilitate a workaround is a bit misguided. If you want support for notes/annotations in numbered bibliographies, think about how that could be implemented in a non-intrusive way and make a proposal for that rather than chasing after feature requests intended to solve entirely different problems.
I cannot disagree more with your second paragraph. Just four months ago, you said yourself that the chances of Zotero supporting "Endnoted" bibliography were very slim. (https://forums.zotero.org/discussion/33900/-is-it-possible-to-create-unique-callout-numbers-for-references-and-repeat-them-in-text-in-word/#Item_6) Now you are accusing me of trying to find an "intrusive" way to pull this off rather than making a proposal? Besides, how can something be "intrusive", if all I'm trying to do is piggy back on a new feature that Zotero offers?
What I did mean to discourage - and that I stand by - is you making or supporting feature requests to facilitate a workaround. It's confusing for people who don't know what you're after from other threads and supporting workarounds is not a reason to implement features.