Is there a way to change the bibtex keys generated by zotero? I don't like long ones like mutuota_kigotho_teaching_2004, would prefer just Kigotho2004.
At this time, you'd need to modify the source code for the BibTeX translator. Many people just post-process Zotero-generated BibTeX using another application. JabRef is pretty easy to use and good for automatic citekey generation and is on all platforms. There are many other choices.
Note that the title fragments are mostly used to keep the citekeys more unique (as some references will likely have the same author/year.
I'd prefer to apply my naming scheme on the zotero entries as well. I don't want my document to look inconsistent and renaming everything manually after an export doesn't work out.
@noksagt (aside): The reason for asking is that there was recently an exchange on the CSL list about how best to implement the citation-label variable, which has been lurking in the CSL schema for awhile. It is apparently meant to be an automagic thing, generated from field content. Hooking it up will allow the CSL processor to offer AMS and other bibkey-based styles directly, which will help us to start exploring that region of bibliography-space, and bring us closer to the possibility of a direct Zotero/LaTeX tieup (i.e. with the document in LaTeX, and a Zotero plugin running the CSL processor as a BibTeX substitute -- which with the capabilities in CSL 1.0 and the modularity of the new processor should be within reach, if someone in LaTeX world were inclined to put in the work to build it).
We'll be starting with a generic key, but that's probably not enough, and one of the issues on the table is whether a manual override (through a user-controlled field in the Zotero UI) is required. We're all kinda hoping that it's not, but I'm curious how common fully automated key management is on the native LaTeX/BibTeX side.
Relevant ticket: https://www.zotero.org/trac/ticket/763 (plus many, many forum threads, all of which, if I recall, have pretty much concluded that a user-controlled field is necessary.)
Note, for what it's worth, that the discussions have generally assumed use of the BibTeX export translator, not CSL. There's a basic BibTeX CSL style, but as far as I know there are still some features that even the new CSL processor wouldn't be able to provide, such as export character set selection and mapping of extended characters to LaTeX codes when using a non-Unicode character set.
This thread is talking about the citation key, which is used to refer to an individual entry. A common key might be "Bennett-2009".
I do not know what you mean by "AMS and other bibkey-based styles." Do you mean styles, such as the alpha BibTeX style and/or the various alphabetic options to the AMS style, which produce citations like '[Ben09]' and use these to preface each entry in the bibliography? If so, this is not the same as the cite key. The amsrefs package, etc. generate these from the bibliographic info & not from the user-provided cite key.
Back to the subject of keys, though: manual editing of the key is an almost ubiquitous feature of programs that use the BibTeX file format as the data backend. It is very common in programs that import/export BibTeX as a core format. Zotero is a notable exception. Auto-generation of the key is very common & I'd say that many of the apps that auto-generate the key allow you to set the auto-generation rules.
I had thought that there was a general consensus that there was no real way to avoid putting user-defined identifiers, such as the BibTeX key, into Zotero to allow people that authored documents where they manually type such keys a break. There is simply no way to make everyone happy with keys that are auto-generated and cannot be customized: they must be simple for the author to remember, allow for disambiguation, and be compatible with documents/BibTeX databases started before the use of Zotero.
Upgrade Storage
Note that the title fragments are mostly used to keep the citekeys more unique (as some references will likely have the same author/year.
We'll be starting with a generic key, but that's probably not enough, and one of the issues on the table is whether a manual override (through a user-controlled field in the Zotero UI) is required. We're all kinda hoping that it's not, but I'm curious how common fully automated key management is on the native LaTeX/BibTeX side.
Note, for what it's worth, that the discussions have generally assumed use of the BibTeX export translator, not CSL. There's a basic BibTeX CSL style, but as far as I know there are still some features that even the new CSL processor wouldn't be able to provide, such as export character set selection and mapping of extended characters to LaTeX codes when using a non-Unicode character set.
I do not know what you mean by "AMS and other bibkey-based styles." Do you mean styles, such as the alpha BibTeX style and/or the various alphabetic options to the AMS style, which produce citations like '[Ben09]' and use these to preface each entry in the bibliography? If so, this is not the same as the cite key. The amsrefs package, etc. generate these from the bibliographic info & not from the user-provided cite key.
Back to the subject of keys, though: manual editing of the key is an almost ubiquitous feature of programs that use the BibTeX file format as the data backend. It is very common in programs that import/export BibTeX as a core format. Zotero is a notable exception. Auto-generation of the key is very common & I'd say that many of the apps that auto-generate the key allow you to set the auto-generation rules.
I had thought that there was a general consensus that there was no real way to avoid putting user-defined identifiers, such as the BibTeX key, into Zotero to allow people that authored documents where they manually type such keys a break. There is simply no way to make everyone happy with keys that are auto-generated and cannot be customized: they must be simple for the author to remember, allow for disambiguation, and be compatible with documents/BibTeX databases started before the use of Zotero.