Re. 1: The final case in your citations should depend upon the particular .BST file that you use w/ BibTeX. While I can see a justification for encapsulating words that have an uppercase letter in other-than-the-first position, I don't know if I feel the same way about words that only have an initial cap (title case).

Given the title "DNA: The Secret of Life," you will almost always want to capitalize all of "DNA," but the initial case of other words may vary.

Re. 3: @url and @electronic are very uncommon. I don't know if I'd want any zotero type to map to them. Which mappings would you propose for these types?

I think that @conference should map to Zotero's "Conference Paper" type. I think that the "Conference Paper" type should continue to map to "@inproceedings," though. @inproceedings is much more common (I think that @conference might be a legacy format that is almost always handled identically to @inproceedings). Would there be some significant disadvantage of losing the explicit @conference mapping that I am missing?

EDIT: I don't think that zotero should write out any type that isn't a core, enumerated type. Postel's law supercedes the ability to round-trip data.

In BibTeX, there is no difference between @conference & @inproceedings.

https://www.zotero.org/trac/ticket/1183 addresses most concerns raised in this thread to some degree.

@neatnate, I can't reproduce (1) in the trunk. (2) is fixed by the patch (-- was actually being replaced by a quotation dash, which is a unique unicode entity from an en- an em-dash)

I propose that Zotero survey its users through a poll email to establish from which data bases and citation programs users need to import and to which they want to export. Zotero already owns all the login email adresses from forum users and could put a link to the online survey on the website. There is no need to get precise numbers but the interest in such a poll is to know where the bulk is situated.

-ft

@ftr: what does that proposed pole have to do with BibTeX?
@jamessuthe:
The case issues were addressed by the patch I described. The URL issue was at least partially addressed--"\url" and "\href" are stripped on import. This is the right way for the links to be stored in Zotero at least until full fields support semantic markup/rich text. It is still exported as-is, without an explicit link. I disagree that an option is the right way to solve this, but don't know what the right way is.

As I've said in another thread on this issue, Zotero a) should not adapt ANY features specifc to BibTeX, and b) needs to consider these requests in the context of larger goals. WRT to this example, the relevant larger goals are the forthcoming social networking and collaboration functionality.

A BibTeX key is a local natural language identifier. WRT to a BIbTeX file that's imported, the key is local to (and hence unique within) just that file.

For an app like Zotero 1.0, the key would have to be local to the database. Here you're already faced with a practical problem of resolving potentially duplicate keys. E.g. if you import two files and both have keys "smith1999" but are in fact referring to different items, then you need some way to resolve them.

Zotero 2.0 is intended to allow social-networking-like sharing and discovery of items. Imagine you have an item that is part of the libraries of 100 users. Let's say we give that item a global identifier like , and/or maybe . What's the key, and what's its scope?

You might reasonably say for the first problem that Zotero should just automatically resolve the duplicate keys (though that's not necessarily so straightforward). Or, for the second, you might say the local scope remains the user, so that we might in theory have 100 different keys for the same item. But I'm just emphasizing that this isn't so straightforward as you suggest.

As I've said in another thread on this issue, Zotero a) should not adapt ANY features specifc to BibTeX, and b) needs to consider these requests in the context of larger goals. WRT to this example, the relevant larger goals are the forthcoming social networking and collaboration functionality.

I strongly agree with your desire not to wed Zotero to problematic citation solutions in ways that might impede its progress towards forward-looking (elegant, easy, standardized, or even just, working) mechanisms for academic citations, and you have collaborated in and led some of the most interesting recent work on these things. However, I'm not convinced that explicit Zotero support of Bibtex keys would mean that Zotero would be taking on cruft which would slow down progress to better citation technologies.

The request for good management of BibTeX keys could just be rolled into a broader request for usable, self-consciously local, human-readable, record IDs, as you I and I discussed in this thread. These would then be presumably mapped onto global a robust global equivalent of the BibTeX key (URIs). You wrote:

So, for example, you have a generic notion of a citation and a reference. A citation is an ordered list of references. Each reference contains, say, a local id label, and a global id (a URI), plus optional locators, prefix and suffix, etc.

What I'm trying to suggest that local identifiers (like BibTeX keys) are one pretty versatile means by which high-quality citation formatting could be added easily to text written in a wide variety of writing tools, including those which use plain-text formatting like the recent spate of lightweight markup languages. The only odd thing in the present situation, and the reason these requests come forward as "BibTeX support" requests, is that BibTeX is the sole longstanding, open implementation of this idea. Whatever its own faults, managing citations the way BibTeX does (with a simple human-generatable reference to (1) a prior work needing to be cited and (2) a citation style with which to format the citation, is a pretty good one. As I suggest in that thread, it could also be a workable path for Zotero/CSL citation to be usable for a broad range of currently unsupported word-processors and text editors, both on- and offline.

So yes, you're right to urge keeping Zotero from developing a debt to legacy citation engines which we all hope will be superseded, and to local and individually-focused solutions in particular, but a human readable "LocalID" field could (it seems) be implemented in the near term, in a way that is deliberately aimed at providing a means for working with other citation tools alongside BibTeX, (citeproc-hs comes to mind) but which could also provide immediate benefits to those who are working with various incarnations of LaTeX. For those who use it them, this field would be mapped to BibTeX keys. For all its cruft, LaTeX still has a lot of users who have found nothing to replace its breadth, design flexibility, and massive FLOSSy extensibility. For it, and for any solution which operates in plain-text, nice, usable, local IDs seem to me to be one good for the writer to specify just what prior work s/he wants to make reference too.

This has been reported:
http://forums.zotero.org/discussion/5762/

Hi, I guess this thread is relevant. I have an capitalization {Gy.} which I wish to preserve, but all other words in the title should follow sentence-case capitalization.

Can I markup the title in zotero somehow to tell it that the G should stay capitalized on export to bibtex?

OK. Thank you noksagt.

I was able to workaround by including curly braces within the zotero title (as I currently do for bibtex), but obviously this is not a long-term solution.

For those interested, I made a copy of the BibTex translator that allows you to export only the \cite{key}. This enables me to use Zotero to drag-and-drop or copy-paste the citekey into a waiting text editor. The cite key is the same as the one that the default zotero BibTex translator uses.

Link is here:
http://www.people.fas.harvard.edu/~leifer/zotero/BibTexCiteKeyOnly.js

Instructions here:
http://forums.zotero.org/discussion/146/integration-with-latex/#Item_18

Thank you noksagt for pointing out, and thank you Dan Stillman for fixingmuch of the BibTex capitalization problems. I was wondering if there are any new ideas regarding how the BibTex exporter should handle capitalization for the title field.

I know this was being considered as a general issue with Zotero, and I like the about:config setting solution, but obviously this doesn't affect the BibTex output.

I have a lot of citations with "C. elegans" in the middle of the title that I need to output to Bibtex. This is doubly tricky because "C." is always capitalized but "elegans" never is. Is there an obvious way to deal with that?

If its simple I could even edit the Translator file myself.
Thanks again.

I just ran into the issue of upper/lower case when exporting to BibTeX. It appears to me that the biggest issue is that of proper nouns getting lower-cased by various style sheets applied to BibTeX entries. It appears that if a token (~word) has an upper case letter in non-initial position, the export process correctly brackets it. This (and maybe some other tricks I haven't noticed) goes a long way towards a solution, but of course it doesn't solve the problem for most proper nouns.

I can think of two possible (albeit partial) solutions to the proper noun issue: have a dictionary of proper nouns, and bracket any token matching a word in that dictionary; or have a dictionary of non-proper nouns, and bracket any token *not* in that dictionary. The latter seems much more reasonable, since such dictionaries already exist (one could start with the aspell dictionaries, for example); and the list of proper nouns is open ended.

Would something like this be feasible? It won't work where a noun is ambiguous (George W. bush), but it might go a long ways.

I also have the problem concerning captial words in BibTeX exports, in my case "Chlamydomonas reinhardtii" became "chlamydomonas reinhardtii". I guess that article titles should be printed as they are, and don't get why LaTeX performs its own capitalization. However, a solution to the problem is to encapsulate the whole title in { }, the following diff (against a freshly checked out subversion trunk as of 2010-05-06) resolves the problem by adding curly braces around the title in .bib files:

Index: translators/BibTeX.js
===================================================================
--- translators/BibTeX.js	(revision 6025)
+++ translators/BibTeX.js	(working copy)
@@ -1833,8 +1833,12 @@
 	if (Zotero.getOption("exportCharset") != "UTF-8") {
 		value = value.replace(/[\u0080-\uFFFF]/g, mapAccent);
 	}
-	Zotero.write(value);
-	if(!isMacro) Zotero.write("}");
+    if ((!isMacro) && (field == "title"))
+        Zotero.write("{");
+    Zotero.write(value);
+    if ((!isMacro) && (field == "title"))
+        Zotero.write("}");
+    if(!isMacro) Zotero.write("}");
 }
 
 function mapEscape(character) {

Is there any chance this will make it into any of the upcoming releases? I would be happy if I didn't have to patch this file every time Zotero is updated.

Cheers - Micha.