I'd also like to add the option of inserting the item key into the label, so that people can more easily pull that out of the data as well.

This sounds a little odd of a solution. We have an opaque database id for machines (which cannot change), and then a natural language key for machines and humans (but which can change) to achieve the same thing: uniquely identify an item within the scope of a library. And now we'd have one field which can represent either?

I'd prefer another method to expose the machine key if necessary.

On the configurable generation, I was recently playing with a function in ruby, with I think a clever way to generate a portion of a title as a disambiguator (is that a word?):

https://gist.github.com/886834

But to Avram's point, main thing is to be able to:

1. downcase strings
2. disambiguate same author/year items

Any chance this gets implemented?

If I understand correctly, this is all tied up in the revamp of Zotero fields, which in turn is tied to rewriting syncing to ensure compatibility between clients etc. As per Simon above this is generally supported by devs and that was still the case when I talked to him a couple of months ago, but it may unfortunately take a bit of time still.

Is any news available on a possible ETA for that revamp?

"later this year" has been what Dan is saying and recent activity on github suggests things are pretty far advanced.

Hmm, note that there are two things being described as a "citation label".

The original post referred to citation-label--a variable that should actually appear in text for label/trigraph styles (e.g., "SmJo1965"). There is a discussion for providing a syntax for automatically generating labels here.

In all of the replies, that variable is usually described as a "citation key" or "citekey". That is analogous to the id variable in CSL-JSON and indicates a placeholder used while writing in plain text systems like BibTeX or Markdown, which is eventually replaced with formatted citations.

So do we want citationKey (for BibTeX/etc.) and citationLabel (for label styles) for all types, or can we just have a citationKey field that also gets used for label styles? (People are going to be confused by the difference.)

I don't know what citation-label does in CSL, but if there's a strong overlap, I could switch to citationLabel with citationKey as an alias. Bibtex users will be more used to citation key though, and semantically, in bibtex, it is a key (it uniquely identifies an item) rather than a label (which describes one of potentially multiple characteristics of an item, and can be shared between items).

My view is the field should just be key. Label formats actually vary by citation style, so ideally would be configurable algorithmically, but they are also fairly rare.

WRT algorithmic generation, would appreciate being part of the dialogue, I'd prefer to align BBTs pattern format as close as possible (even if only by adding a formatter function that will yield a style-bound key generated by the csl processor - people are going to want them)

CSL 1.1 will include style syntax for specifying a label. citation-label will be generated by the processor and should not have an item field in Zotero.

citation-key ala BibTeX should be specified as part of the item. This is mostly to facilitate use with BibTeX/pandoc systems to be a human-readable variable that can be called in lieu of the machine-readable id