-
-
Notifications
You must be signed in to change notification settings - Fork 2
Add hereinafter
variable
#37
Comments
In how far is this necessary next to title-short? Are there cases where you would need different shorttitle and hereinafter in one entry? I can imagine that a hereinafter variable is useful if a user wants to override the title-short entry on a per document basis in order to disambiguate. But that would require Zotero et al. to implement mechanism and interface for that functionality. (IIRC that’s what Juris-M does). |
You will probably use one or the other. This is used in certain disciplines a lot, e.g., philosophy or literature, where you'll have citations like this:
You are right with your comment concerning concerning setting this on a per document basis. I think this will most likely be the main problem here. How will users use this variable, given that the abbreviation filter does not work with Zotero at the moment. (As you note, it works with Juris-M, and you can also use abbreviations per document with pandoc, but unfortunately not with Zotero.) |
Couldn't ND be a |
I don't see how this could work. As said above, To stick with this example: Like here: But in the Adorno example above, I just want: |
If I understand correctly, this I remain convinced that a |
If this were implemented, it should be separate from
See the example in the CSLm spec: https://citeproc-js.readthedocs.io/en/latest/csl-m/#hereinafter-extension That said, |
I've just used that name in the proposal as CSLm also uses that name for this variable. That said, I have no objections against using another name for this, e.g. Anyway, @bwiernik is absolutely right with his assertion that such a variable is not like similar variables, and that this poses an obstacle to adding this at the moment. |
Thinking about this again, I propose we look into this for 1.1. I assume this variable could be handled without too many problems in systems like pandoc. @jgm What do you think? In Zotero it's obviously more difficult. But it's a bit a chicken and egg problem. Without such a variable, there's one reason less for implementing abbreviation filter like functionality. But I'm optimistic that this could be solved somehow @dstillman ? Also, having this variable without accompanying features in e.g Zotero won't be a huge deal either. The way this will be handled in styles just means that there's no problem if the variable is missing. |
My understanding of uses for
The first would be handled by the proposed change to the So, what is hereinafter for beyond these cases? |
What I was thinking of is actually no.3. Just that it won't be auto-generated and that only specific items will be cited by label. |
If we use |
So this is just a shortened form for the citation or name, to allow more concise subsequent representations. Right? So why a variable? And what's the demand for this? Seems like perhaps one of those archaic conventions that may not be needed? |
It’s fairly common in, for example, commentaries on a work in stats or math to do something like: It’s arguably useful when you are going to refer to the authors 100 times in the course of the comment (personally I’m not a fan). I think this use is reasonably well-covered by |
Yes, the use-case is exactly as per @bwiernik's description. That's quite common in certain disciplines, say, e.g. literature or philosophy. When you are writing about one author or even one book, you will want to use shorthands for this particular work or all the works of this author. How do you think that could be handled by typing a suffix @bwiernik ? Typing the shorthand manually might work in some cases, but it fails if you also need to use "ibid." Anyway, I agree that there's probably no need for a new variable: For pandoc, I imagine a solution where you have your bibliography: references.yaml
citation-labels:
- id: adorno2003NegativeDialektik
citation-label: ND
- id: SmithJonesTest2009
citation-label: SJT09 Maybe something for a filter, or for the new citeproc library @jgm ? Do you think something like this could work? In Zotero/Word this will be more complicated, of course, but perhaps one could just load a json file with the labels from the word processor plugin, so a full abbbreviation filter wouldn't be needed. |
I just meant the user would manually add "hereafter, "SJT08" as a suffix to the citation, then type SJT08 as regular text later in the document. I'm not really too concerned about an interface for this. Supplying a But honestly, if the improvement over manually typing this to support ibid, that seems not worth the effort. Using two different forms of shortened subsequent citations seems like terrible reader-hostile practice. All of this seems like it could be accomplished using existing CSL style features. For example, test for |
Hmm, that feels a bit like going back to the days of preparing bibliographies manually. You'd have to be sure to have the suffix that introduces a shorthand really on the first citation of a particular item.
That's true. But if you use BBT, you can really only make these edits as the final step.
Good idea.
Maybe true.
Yeah, that's how I thought it can be done with <if variable="citation-label">
<text variable="citation-label"/>
<if>
<else>
{regular subsequent text}
</else>
I wasn't aware of that: Is the idea that processors always generate labels? I thought so they should only do this when explicitly instructed to do so (using the proposed new citation-label syntax). |
I second that. Whichever variable is used, the term "hereinafter" must be set as a plain text prefix. Given how common it is used in styles, a dedicated term would be a cleaner solution for single-locale styles and the only solution for multi-locale styles, where hard-coding is not an option. This might be a separate issue entirely, as an |
Oh, I suppose that would be a better idea. Currently citeproc-js and citeproc-rs automatically generate a citation label for each item when |
@p-heckler No, please keep discussion of this issue in one place. |
So, let's imagine a user is writing a style where they want to use a
That work? |
Yes. That should work if |
Do we really need two |
I thought one is for introducing |
But using |
Used for styles that switch to an abbreviated `citation-label` format for subsequent citations. Long and short forms might be localized as "henceforth cited as" and "henceforth" respectively. Closes citation-style-language/csl-evolution#37
Used for styles that switch to an abbreviated `citation-label` format for subsequent citations. Long and short forms might be localized as "henceforth cited as" and "henceforth" respectively. Closes citation-style-language/csl-evolution#37
Used for styles that switch to an abbreviated `citation-label` format for subsequent citations. Long and short forms might be localized as "henceforth cited as" and "henceforth" respectively. Closes citation-style-language/csl-evolution#37
Used for styles that switch to an abbreviated `citation-label` format for subsequent citations. Long and short forms might be localized as "henceforth cited as" and "henceforth" respectively. Closes citation-style-language/csl-evolution#37
CSL-M has a
hereinafter
variable for special shorttitles/abbreviations/short citation forms of particular items. Wouldn't it make sense to include this in CSL? (I don't think that adding the variable poses particular challenges in itself. The main challenge is probably how this variable will be populated by users...)The text was updated successfully, but these errors were encountered: