However, a solution to the problem is to encapsulate the whole title in { } .... Is there any chance this will make it into any of the upcoming releases?
I don't think this is appropriate. Most BibTeX programs do NOT do this & it is useful for BibTeX to be able to change capitalization (off all fields, not just title).
Another solution to the capitalization problem is just to use a bibliography style that does not change the case of your bibliography entries. If you want to use APA style, feel free to use my bst file at:
http://stanford.edu/~messing/apaish.bst
If not, in every bst file, there should be something like "FUNCTION {format.title}" and within that function, you should see the line:
{ title "t" change.case$ }
This appears to be the thing that screws with the capitalization. If you change that line to:
{ title }
and save the file to some other name, you should be good to go. You'll have to change the \bibliographystyle{} command in your TeX doc to point to the new file.
Or you can generate a custom style from scratch, by using the command "latex makebst" and answering a series of questions about bibliography style.
@messing: Thanks, that did the trick! I reverted the Zotero BibTeX exporter to its original state and removed that title case thing from a copy of my bst file.
And... I had to do a sudo texhash before it worked, just in case anybody tries to pull this stunt at home.
I can't reproduce that problem. For example I have this entry (note the 'ñ' characters) :
1. Domingo Muñoz León, “La distinción entre acontecimiento-base artificio literario en los relatos derásicos : Una discusión con el Prof Muñoz Iglesias en su obra "Los Evangelios de la Infancia",” Estudios bíblicos 50, no. 1 (1992): 123 - 148.
This exports to BibTeX [Western (ISO-8859-1)] as:
@article{muoz_len_distincin_1992, title = {La distinci\'{o}n entre acontecimiento-base artificio literario en los relatos der\'{a}sicos : Una discusi\'{o}n con el Prof Mu\~{n}oz Iglesias en su obra {"Los} Evangelios de la Infancia"}, volume = {50}, issn = {0014-1437}, number = {1-4}, journal = {Estudios b\'{i}blicos}, author = {Domingo Mu\~{n}oz Le\'{o}n}, year = {1992}, pages = {123 -- 148} }
I'm not intimate with the BibTeX ecoding of ñ, but that looks about what I'd expect It also exports to BibTeX--UTF-8 just fine (e.g. keeping the ñ's).
Perhaps you can paste the string you have in your zotero database here so we can try it, and what you get when you export to bibtex using the codepage you want.
Scot is correct: export is handled fine. As I responded in the other thread, the issue is only on import & has nothing to do with the tilde, but with the characters that are accented not having braces.
So the import is wrong. But that means it will not be eported correctly.
Problem is reference import from this site (APS):
http://prl.aps.org/abstract/PRL/v89/i19/e195504
(Save to Zotero)
--> Núñez will be imported as N��ez and exported as N??ez
(don't know what this forum will transfrom it into)
So i imported the bibtex file which does not use braces: N\'u\~nez
And as stated above this will not export correctly.
I know that many journal publishers have no perfect bibtex export...
But correcting every import manually is really tedious. And during literature search one normally should not need to look for any import/export failures.
By the way, using scholar.google.com gives: Nunez
So this is no option either.
But one can use the RIS export from the APS site and import the RIS file with Zotero.
So, maybe it is the best option to just use RIS files for importing, for now.
Problem is knowing on which site which import does function...
So the import is wrong. But that means it will not be eported correctly.
Correct export means to export the data as close to the way it is stored in the Zotero database as possible. If you have garbage stored in the database, the correct export should also include garbage!
So i imported the bibtex file which does not use braces: N\'u\~nez
You are correct that we should handle this better.
And as stated above this will not export correctly.
But, again it exports as it is in your database!
But one can use the RIS export from the APS site and import the RIS file with Zotero.
This is because the character encoding matches when you import the file manually, but it does not match when using the APS translator at that particular page.
I found the bibtex export for webpage be less than optimal. I would very much like zotero to output the howpublished field using the \url command, as follows:
I would very much like zotero to output the howpublished field using the \url command
Please see the discussion, above. There are bibtex styles that do not use url in the howpublished field & other popular reference managers (e.g. JabRef), databases (e.g. Connotea), and "next gen" systems (e.g. BibLaTeX) do not do it this way by default, so I'm not convinced that Zotero should.
Thanks! I was only vaguely aware of biblatex. I realise that every system has its idiosyncrasies, and therefore Zotero cannot hope to support all bibtex variants, and in turn it makes sense to keep the export mechanism as straightforward as possible. My question then becomes: which variant is especially suited to work with Zotero? You write "e.g. BibLaTeX" -- does it mean some other system should be considered?
All in all, I do not care for the exact output of Zotero, but I want a streamlined operation from Zotero to latex (which also allows collaboration with co-authors using bibtex). It would be nice if a "standard" workflow for this would be documented somewhere. Thanks again!
My question then becomes: which variant is especially suited to work with Zotero?
I use bibtex-0.99 with .bst files written by publishers for most of my work. Most .bib files can be compatible with both BibLaTeX and BibTeX. BibTeX was made to have a small set of standard features and then made to be extensible to cover everything else. This means there are various idiosyncracies between different reference managers and different style files. Where possible, Zotero generally adopts the "most popular" idiosyncracy (i.e. that use by JabRef and/or BibLaTeX in many cases) that will not break too much else.
All in all, I do not care for the exact output of Zotero,
What are your specific objections & can you point to another reference manager that does not use a .bib file on the backend that you like better?
It would be nice if a "standard" workflow for this would be documented somewhere.
Because the styles are idiosyncratic, there is no "standard workflow." You can customize a style that always works well with the Zotero output (assuming that you have flexibility in choosing your style). You can always use the same set of styles & rely on scripts to transform the BibTeX output of Zotero in any ways that those specific styls require. But I don't think there's much that can be done to improve things more generally (there is a bit & we'd welcome specific suggestions, though).
All in all, I do not care for the exact output of Zotero,
@noksagt: I suspect jyp means "It doesn't matter to me exactly what Zotero outputs (just as long as I can achieve a decent workflow!)" That seems to fit the tone of the post better.
I laughed when I read jyp's request for a well-documented 'standard workflow', since it's a good one. It's funny only because those of use who have gotten a little bit used to the complexity of BibTeX (and using Zotero with it) have also gotten used to (what for me anyway) is a collection of fairly convoluted processes of data munging to get the output to do what we want. We're a little bit numb.
Noksagt is right that there couldn't be a single standard workflow. But even if there can't be be one, we would probably all be be grateful (and mostly well served) by a few which were well documented. And that might serve to throw up some of the remaining problems.
BibTeX was made to have a small set of standard features and then made to be extensible to cover everything else. This means there are various idiosyncracies between different reference managers and different style files. Where possible, Zotero generally adopts the "most popular" idiosyncrasy (i.e. that use by JabRef and/or BibLaTeX in many cases) that will not break too much else.
That's about as good a short description of BibTeX and Zotero's approach to it that I've ever read.
But I don't think there's much that can be done to improve things more generally
OK, I'll try. It would be great to give people more control from within Zotero over their BibTeX export, doing away with the need for BibTeX postprocessors for almost all Zotero-BibTeX users. Postprocessors are hard to set up, the scriptable ones that I know (bibtool and now bibtexformat) don't handle UTF-8, and they can't solve issues which involve exporting things that aren't already exported. I've just (again) spent a good few *days* trying out postprocessors, making lists of my problems, hacking at the BibTeX.js file and trying things in JabRef. I think I've just about got it to where it works. (And yes jyp, I'll try to throw up a place to document it. Aside from using a modified BibTeX exporter, it's not too complex in the end). But it was hard to get there.
I'd love to see an "Advanced BibTeX Export Preferences" tab in the UI, where people could have greater control over things that affect their own edge cases. Bibliograhic data handling is complex (as Bruce D. is good at reminding us) and the BibTeX world represents a massive amount of effort at solving those problems, some of it quite sucessful. But as you say that effort has taken many slightly differing paths. In general, I'd be glad to see Zotero interface with that diversity a little more explicitly. The nature of BibTeX is that one size doesn't fit all, and the most popular idosyncracy is the one that my bibtex style didn't choose to go with.
Hacking the BibTeX.js file is in some ways a decent solution, since it helps keep the rest of the process simple, but it's, well, Javascript (and not all that well coded for user modification). And I suspect many people who need "just one thing changed" won't manage it. I'm still not quite sure I have.
I think that the Zotero folks have been pretty clear in that they don't want to add advanced BibTeX output preferences, but it would be fairly easy to make a Zotero plugin that did only BibTeX export and provided more choices. It's not that easy right now to give a specific translator its own preferences.
This would be a similar to, I suppose, LyZ, but it wouldn't try to maintain a BibTeX file, but rather export in BibTeX-friendly ways. Maybe the LyZ project could expand a little into providing more BibTeX customization, and it could do export, in addition to LyX synchronization?
but it would be fairly easy to make a Zotero plugin that did only BibTeX export and provided more choices. It's not that easy right now to give a specific translator its own preferences.
Hmm, that's a nice idea. I'd certainly be willing to help define the requirements for such a plugin, based on forum requests and my own experience. And of course testing and documentation. Anybody have the Javascript chops and the umpf to help put this together?
hello everyone, I know there hasn't been much of a discussion lately, but I need help with the (in my view still open) issue of the upper case... Since I am using German and English literature I cannot rely on the .BST file (as @noksagt recommended) to deal with the upper case lower case decision... my solution in other programmes (such as mendeley, or citavi) was to use lower cases for English titles (except the first letter) and spell German titles correctly. Thereby, the program only had to export it by bracceting the title in {{Titel That is German}}... is there any way I can adjust this easily? I haven't found anything helpful yet. If that was all zotero can do I'd really regret migrating from citavi... any help is highly appreciated!!
Maybe it is only in my head related to the issue... but I hwven't been able to make zotero export the "language" field of each entry and map it (that is: add the language field) to every single bibtex entry. If zotero could at least put the title in {} then I wouldn't have to map language field entries at all. Ok, bibtex tehn wouldn't be able to change the spelling of the title at all... but what choice do I have? thanks for your help!!!
here are two examples: German: @book{esposito_soziales_2002, address = {Frankfurt am Main}, series = {suhrkamp taschenbuch wissenschaft}, title = {Soziales Vergessen: Formen und Medien des Gedächtnisses der Gesellschaft}, volume = {1557}, isbn = {3518291572}, publisher = {Suhrkamp}, author = {Esposito, Elena}, year = {2002}
English: @article{rasch_systems_2010, title = {Systems theory and the system of theory}, number = {61}, journal = {New German Critique}, author = {Rasch, William and Knodt, Eva M}, year = {2010}, pages = {3--7}
In the first case I also have the problem that it doesn't translate the umlaut ä to {ä} but that seems to be a different problem (although it could be solved by my suggested solution).
on .bst: I use the standard chicago.bst file the expected output therefore should look something like:
Esposito, Elena. 2002. <i>Soziales Vergessen: Formen und Medien des Gedächtnisses der Gesellschaft</i>. Vol. 1557 of <i>suhrkamp taschenbuch wissenschaft</i>. Frankfurt am Main: Suhrkamp.
Rasch, William and Knodt, Eva M. 2010. "Systems theory and the system of theory." <i>New German Critique</i> 61:3-7.
problem solved! sorry for all the trouble... found a soultion for the language mapping problem and thereby for the bibtex uppercase lower case problem (as I had it with my files...) maybe this helps others too. it would be nice if the following mapping solution could find its way into the official bitex.js although there might be one last problem:
for the workaround to work (around) the "language" field in zotero must map to "hyphenation" in the .bib file in order to work with biblatex as language identifier. this, however, might be a problem for those who find other use for the language field, e.g. emphasising that the title is in a particular language. For this purpose, unfortunately, the "language" field in zotero must be mapped to the "language" field in bibtex. a final solution, therefore, might be to add a new field "language identifier" in zotero that could be mapped to "hyphenation" without blocking the "language" - "language" mapping function...
then, however, I am a total zotero newbe... there are probably solutions I haven't come across yet or just don't know about.
for the work-around the following must be considered:
bibtex.js must include mapping (var fieldMap = { ...};):
language:"hyphenation",
preambel of the tex file must include:
\usepackage[english,ngerman]{babel}
\usepackage[language=british, authordate, natbib]{biblatex-chicago}
the above mentioned bib-file output should be as follows:
German:
@book{esposito_soziales_2002,
address = {Frankfurt am Main},
series = {suhrkamp taschenbuch wissenschaft},
title = {Soziales Vergessen: Formen und Medien des Gedächtnisses der Gesellschaft},
volume = {1557},
isbn = {3518291572},
publisher = {Suhrkamp},
author = {Esposito, Elena},
hyphenation = {ngerman},
year = {2002}
English:
@article{rasch_systems_2010,
title = {Systems theory and the system of theory},
number = {61},
journal = {New German Critique},
author = {Rasch, William and Knodt, Eva M},
hyphenation = {english}
year = {2010},
pages = {3--7}
sorry guys, its me again...
what did I miss? mapping as explained doesn't work... totally confused and I have no idea how I get it to work...
in short:
problem: how to map the "language" field in zotero to the "hyphenation" field in bibtex...
I thought the solution above worked but for some reason it doesn't (and might never had? am I halucinating?)
I really could need your help. And I would also love to learn where to learn how to do it myself... that would be awesome...
**bibtex.js must include mapping (var fieldMap = { ...};):
**language:"hyphenation",
it must read the other way around:
hyphenation:"language",
sorry, I am a complete beginner... If you know sources that can teach me what I need to not always ask stupid questions like these... please don't hesitate to enlighten me :)
Upgrade Storage
http://stanford.edu/~messing/apaish.bst
If not, in every bst file, there should be something like "FUNCTION {format.title}" and within that function, you should see the line:
{ title "t" change.case$ }
This appears to be the thing that screws with the capitalization. If you change that line to:
{ title }
and save the file to some other name, you should be good to go. You'll have to change the \bibliographystyle{} command in your TeX doc to point to the new file.
Or you can generate a custom style from scratch, by using the command "latex makebst" and answering a series of questions about bibliography style.
And... I had to do a sudo texhash before it worked, just in case anybody tries to pull this stunt at home.
Cheers,
Micha.
Zotero still is not able to export correct BIBTEX output.
E.g., this name: N\'u\~nez will not be exported correctly. CodePage setting does not matter. Problem is the ~ (tilde).
Is there a solution?
I think BIBTEX export should have a high priority.
Thanks.
http://forums.zotero.org/discussion/12866/some-european-characters-are-not-imported-correctly/#Item_6
A fix is beyond my ken; maybe someone who uses BibTeX can take a look.
I can't reproduce that problem. For example I have this entry (note the 'ñ' characters) :
1. Domingo Muñoz León, “La distinción entre acontecimiento-base artificio literario en los relatos derásicos : Una discusión con el Prof Muñoz Iglesias en su obra "Los Evangelios de la Infancia",” Estudios bíblicos 50, no. 1 (1992): 123 - 148.
This exports to BibTeX [Western (ISO-8859-1)] as:
@article{muoz_len_distincin_1992,
title = {La distinci\'{o}n entre acontecimiento-base artificio literario en los relatos der\'{a}sicos : Una discusi\'{o}n con el Prof Mu\~{n}oz Iglesias en su obra {"Los} Evangelios de la Infancia"},
volume = {50},
issn = {0014-1437},
number = {1-4},
journal = {Estudios b\'{i}blicos},
author = {Domingo Mu\~{n}oz Le\'{o}n},
year = {1992},
pages = {123 -- 148}
}
I'm not intimate with the BibTeX ecoding of ñ, but that looks about what I'd expect
It also exports to BibTeX--UTF-8 just fine (e.g. keeping the ñ's).
Perhaps you can paste the string you have in your zotero database here so we can try it, and what you get when you export to bibtex using the codepage you want.
So the import is wrong. But that means it will not be eported correctly.
Problem is reference import from this site (APS):
http://prl.aps.org/abstract/PRL/v89/i19/e195504
(Save to Zotero)
--> Núñez will be imported as N��ez and exported as N??ez
(don't know what this forum will transfrom it into)
So i imported the bibtex file which does not use braces: N\'u\~nez
And as stated above this will not export correctly.
I know that many journal publishers have no perfect bibtex export...
But correcting every import manually is really tedious. And during literature search one normally should not need to look for any import/export failures.
By the way, using scholar.google.com gives: Nunez
So this is no option either.
But one can use the RIS export from the APS site and import the RIS file with Zotero.
So, maybe it is the best option to just use RIS files for importing, for now.
Problem is knowing on which site which import does function...
Thanks you.
http://forums.zotero.org/discussion/11498/ You are correct that we should handle this better. But, again it exports as it is in your database! This is because the character encoding matches when you import the file manually, but it does not match when using the APS translator at that particular page.
if(item.itemType == "webpage") {
Zotero.write(",\n\t howpublished = {\\url{" + item.url + "}}");
}
Could you consider changing the bibtex export in that way? Thanks!
All in all, I do not care for the exact output of Zotero, but I want a streamlined operation from Zotero to latex (which also allows collaboration with co-authors using bibtex). It would be nice if a "standard" workflow for this would be documented somewhere. Thanks again!
I laughed when I read jyp's request for a well-documented 'standard workflow', since it's a good one. It's funny only because those of use who have gotten a little bit used to the complexity of BibTeX (and using Zotero with it) have also gotten used to (what for me anyway) is a collection of fairly convoluted processes of data munging to get the output to do what we want. We're a little bit numb.
Noksagt is right that there couldn't be a single standard workflow. But even if there can't be be one, we would probably all be be grateful (and mostly well served) by a few which were well documented. And that might serve to throw up some of the remaining problems. That's about as good a short description of BibTeX and Zotero's approach to it that I've ever read. OK, I'll try. It would be great to give people more control from within Zotero over their BibTeX export, doing away with the need for BibTeX postprocessors for almost all Zotero-BibTeX users. Postprocessors are hard to set up, the scriptable ones that I know (bibtool and now bibtexformat) don't handle UTF-8, and they can't solve issues which involve exporting things that aren't already exported. I've just (again) spent a good few *days* trying out postprocessors, making lists of my problems, hacking at the BibTeX.js file and trying things in JabRef. I think I've just about got it to where it works. (And yes jyp, I'll try to throw up a place to document it. Aside from using a modified BibTeX exporter, it's not too complex in the end). But it was hard to get there.
I'd love to see an "Advanced BibTeX Export Preferences" tab in the UI, where people could have greater control over things that affect their own edge cases. Bibliograhic data handling is complex (as Bruce D. is good at reminding us) and the BibTeX world represents a massive amount of effort at solving those problems, some of it quite sucessful. But as you say that effort has taken many slightly differing paths. In general, I'd be glad to see Zotero interface with that diversity a little more explicitly. The nature of BibTeX is that one size doesn't fit all, and the most popular idosyncracy is the one that my bibtex style didn't choose to go with.
Hacking the BibTeX.js file is in some ways a decent solution, since it helps keep the rest of the process simple, but it's, well, Javascript (and not all that well coded for user modification). And I suspect many people who need "just one thing changed" won't manage it. I'm still not quite sure I have.
This would be a similar to, I suppose, LyZ, but it wouldn't try to maintain a BibTeX file, but rather export in BibTeX-friendly ways. Maybe the LyZ project could expand a little into providing more BibTeX customization, and it could do export, in addition to LyX synchronization?
here are two examples:
German:
@book{esposito_soziales_2002,
address = {Frankfurt am Main},
series = {suhrkamp taschenbuch wissenschaft},
title = {Soziales Vergessen: Formen und Medien des Gedächtnisses der Gesellschaft},
volume = {1557},
isbn = {3518291572},
publisher = {Suhrkamp},
author = {Esposito, Elena},
year = {2002}
English:
@article{rasch_systems_2010,
title = {Systems theory and the system of theory},
number = {61},
journal = {New German Critique},
author = {Rasch, William and Knodt, Eva M},
year = {2010},
pages = {3--7}
In the first case I also have the problem that it doesn't translate the umlaut ä to {ä} but that seems to be a different problem (although it could be solved by my suggested solution).
on .bst: I use the standard chicago.bst file the expected output therefore should look something like:
Esposito, Elena. 2002. <i>Soziales Vergessen: Formen und Medien des Gedächtnisses der Gesellschaft</i>. Vol. 1557 of <i>suhrkamp taschenbuch wissenschaft</i>. Frankfurt am Main: Suhrkamp.
Rasch, William and Knodt, Eva M. 2010. "Systems theory and the system of theory." <i>New German Critique</i> 61:3-7.
for the workaround to work (around) the "language" field in zotero must map to "hyphenation" in the .bib file in order to work with biblatex as language identifier. this, however, might be a problem for those who find other use for the language field, e.g. emphasising that the title is in a particular language. For this purpose, unfortunately, the "language" field in zotero must be mapped to the "language" field in bibtex. a final solution, therefore, might be to add a new field "language identifier" in zotero that could be mapped to "hyphenation" without blocking the "language" - "language" mapping function...
then, however, I am a total zotero newbe... there are probably solutions I haven't come across yet or just don't know about.
for the work-around the following must be considered:
bibtex.js must include mapping (var fieldMap = { ...};):
language:"hyphenation",
preambel of the tex file must include:
\usepackage[english,ngerman]{babel}
\usepackage[language=british, authordate, natbib]{biblatex-chicago}
the above mentioned bib-file output should be as follows:
German:
@book{esposito_soziales_2002,
address = {Frankfurt am Main},
series = {suhrkamp taschenbuch wissenschaft},
title = {Soziales Vergessen: Formen und Medien des Gedächtnisses der Gesellschaft},
volume = {1557},
isbn = {3518291572},
publisher = {Suhrkamp},
author = {Esposito, Elena},
hyphenation = {ngerman},
year = {2002}
English:
@article{rasch_systems_2010,
title = {Systems theory and the system of theory},
number = {61},
journal = {New German Critique},
author = {Rasch, William and Knodt, Eva M},
hyphenation = {english}
year = {2010},
pages = {3--7}
this worked for me (so far...)
what did I miss? mapping as explained doesn't work... totally confused and I have no idea how I get it to work...
in short:
problem: how to map the "language" field in zotero to the "hyphenation" field in bibtex...
I thought the solution above worked but for some reason it doesn't (and might never had? am I halucinating?)
I really could need your help. And I would also love to learn where to learn how to do it myself... that would be awesome...
cheers,
Above I wrote:
**bibtex.js must include mapping (var fieldMap = { ...};):
**language:"hyphenation",
it must read the other way around:
hyphenation:"language",
sorry, I am a complete beginner... If you know sources that can teach me what I need to not always ask stupid questions like these... please don't hesitate to enlighten me :)