Upgrade StorageImproving BibTeX export
This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.
var citeKeyField = Zotero.getPrefs("bibtexKeyField") ? Zotero.getPrefs("bibtexKeyField") : "callNumber";
Sorry, but I am new at this.
On the other hand, it would be much simpler to just replace all the files. Then in about:config, define a new pref: extensions.zotero.translator.bibtexExportLocalFilePath = true
I'm using the firefox addon, and when unpacked, I couldn't find the bibtex.js file.
I'm comfortable unpacking, editing, etc the files, just not sure where or how when it comes to the firefox addon. Thanks
download at https://gist.github.com/956623/
===============
New Updates:
updated: Mar 16, 2012
1. updated for Zotero 3.0.3
2. item_local.js is replaced by translate_item.js
3. installation guide:
(a) go to https://gist.github.com/956623/ and download the full tar file
or the following 4 files: translate.js, translate_item.js, BibTeXTan.js,
and BibTeXKeyOnly.js
(b) go to your firefox profile directory, then use any zip tool to open
extensions/zotero@chnm.gmu.edu/chrome/zotero.jar. Then navigate to the
archive directory: content/zotero/xpcom/translation/ and use drag & drop
to replace the two files of translate.js and translate_item.js in the jar
file.
(c) go to your zotero data directory (default location is called zotero
right under your firefox profile directory). copy the following files
to the translators directory: BibTeXTan.js and BibTeXKeyOnly.js
(d) restart your firefox.
this is excellent! thank you so much, really. this is a really good way to use zotero sensibly with bibtex (and with bibtex comes -not surprisingly- a plethora of other tools, to me Sciplore/Docear, JabRef, and all..) Especially the ability to export the file paths - unbeliavable:)))
I do heartily agree with your comments on the bibtex users to be more vocal for a more robust bibtex support, but also I think you have already provided a possible answer to that - every now and then I see bibtex related questions in the forum, which distil at the very same point: lacking proper bibtex support. so, your contribution is really appreciated (I do:)
What would increase the visibility of the existence of this tool, in the absence of a better bibtex support integrated into zotero (and from what I understand, this seems to stay so for the near future) would be converting your contribution into a zotero plug-in. I really don't know the technical difficulties related with such endeavour but I believe your bibtex version would reach a lot more bibtex lovers just for the very basic reason that people will know more about it:) See the excellent ZotFile or LyX, for instance. they do have a user base. I really do not know much about coding, and I don't know if you'd like (or have time) to convert your bibtex version to a plug-in, but I'd like to help if you decide so.
And lastly, an idea (again, I don't know whether it is feasible/doable): what about a dedicated bibtex tag for bibtex keys? it could be a suffix (eg. @bibkey_) and would be added automatically to the items (depending on the user preference) and as such, it would display the automatically added bibtex key (eg. @bibkey_doe2012) and the user can remove/change it on demand (@bibkey_johndoe2012).
Sorry for the long post - I hope it was a bit clear,
Again thank you very very much for your dedicated support to bibtex in zotero:))
emrea
I really hoped most of the features I proposed here would've got merged to the official code. but almost a year passed, it seems that it is not going to happen.
Thanks for your great improvement of bibtex support. Too bad that is not yet included in the official code !
Does your code work with the standalone version and how to install it?
I was wondering if you could integrate italic support in your code.
<i> ... </i> to \textit{ ... } but have no idea to do it
Thanks in advance
Regards
On the other hand, I really hope Zotero includes your patches, and merge them to the official version. bibtex is -still- widely used, and not only for the basic purpose it is created for but also as a universal and widely common citation format import/export tool, facilitating the cooperation between different software on whatever platform. Zotero in this regard deserves a much improved bibtex support, in my opinion, and your modifications are really a huge step towards what it should be. So thanks again, a million:)
Best wishes,
emrea
It can not export the local path of attachments. And the user preference settings have to be done manually in the js file. If you want these features, unfortunately you still have to install my implementation.
I have installed your files, and put "extensions.zotero.translator.bibtexExportLocalFilePath"into "about:config" as a new preference, it registers as a 'string', not 'Boolean'. And it doesn't seem to be working. I'm sure I carried out the instructions in the 'ReadMe', so am disappointed.
Integration of Zotero with SciPlore, through JabRef, is what I've been working on. So far, I've been doing it manually, which is laborious and time-consuming. I'm not a programmer, so haven't been able to code my way though this.
If your changes are working for others, then it should work on my system. So there must be an error somewhere.
Anyway, thank you for this additional functionality, all SciPlore users will be grateful. I will, too, when I get it to work.
The way to change it is to first remove it and then create a boolean preference named as the above.
At least one FF Addon is creating JavaScript errors, could this be affecting your modifications?
The filepaths are being exported in the BibTeX export, and appear in JabRef. Initially, they appear as normal, with "\" between the folder names. However, if one clicks on the entries in the 'File' field, the backslashes disappear from the filepath, the folder names all coming toether, with no spaces between them.
Doubl-clicking on the file link in the 'File' field of the imported entry in JabRef brings up the 'Edit file link' pane with the 'OK' button greyed out, and only a solitary 'C' in the 'Link' field. Clicking the 'Open' option does not open the file attachment.
So JabRef is receiving the filepaths, but for some strange reason, it changes them so that they don't work. cb2Bib doesn't open the files, either.
These are application configuration issues, and hopefully can be resolved by adjustment of programme settings.
The main thing is that the paths are being exported accurately. For that, I, and I'm sure, every SciPlore/Docear user, is grateful. So, thank you, spartanroc.
I would ask to zotero development team to integrate the code into the next official release. Zotero integration in Docear I think it is the main weakness of Zotero now. Many people share this opionion, based on internet forum messages and published guides to migrate from Zotero to Jabref and Mendeley. I worked with many reference managers, now I really prefer Zotero for its functionality and because it is open source but the technology is going on and I think that zotero integration with docear is strategic now.
To get the parts that everyone agrees on included:
There are issues that need to be resolved.
1) Rename pdfs with the BibTeX citekey.
I've kind of done this, through Zotero's 'about:config', although there are issues with lack of unanimity in length of title, between the actual BibTeX citekeys and the new names.
It would be preferable to generate the citekeys in Zotero, rather than generate them after, in JabRef. And, also, if necessary, to have JabRef's key generation format brought into synchronisation with that used in Zotero's, so all applications are speaking the same 'language', so to speak, so that JabRef and Zotero can 'deputise' for each other.
I can kind of do this, but haven't quite achieved a seamless integration yet, meaning, it doesn't work yet..
2) Link to Zotero's stored PDFs and user-created folder of PDFs.
spartanroc's modifications are exporting the filepaths correctly, but there is a problem with JabRef and cb2Bib reading them properly, the files won't open, as well as JabRef removing all the '/' separators in the local link addresses. Very odd.
Is it possible for JabRef to set both Zotero's database of stored files and a user created folder of PDFs as specific folders to be scanned by the 'autolink' feature? Setting 'C:\' as the external folder doesn't seem to work too well.
I'm now aware that one has to set PDF folders in two places, for JabRef's 'autolink' function to work, but I'm not clear about how to achieve the specificity I want, in terms of its scope.
As to the incorporation of spartanroc's modifications within Zotero's core programme, I would think that the important issue is that the functionality it provides is made available, in some form or other, which is not prohibitively difficult to implement. A plugin sounds a good idea. That way, those who require it's capabilities, have access to it, and those who don't, won't be burdened by yet more complexities.
I would imagine that what people who are trying to use SciPlore or, previously, VUE, want, is for the mirage of seamless Zotero inoperability to be more than a shimmering, hazy idea. To not have to set out on a quest, tracing a maze
of 'workarounds' that doesn't lead anywhere, except to more mazes.
Upon a double click on the PDF entry in the file field, this (in the BibTeX field):
file = {Author and Author - 2012 - BookTitle.pdf:C:\Users\Name\Documents\MY DOCUMENTS !\BookTitle.pdf:application/pdf},
changes to:
file = {Author and Author - 2012 - book.pdf:C:UsersNameDocumentsMY DOCUMENTS !\BookTitle.pdf},
You're right! Apparently, the correct form for JabRef is:
file = {Author and Author - 2012 - book.pdf:C\:\\Users\\Name\\Documents\\MY DOCUMENTS !\\BookTitle.pdf:application/pdf},
Now, the only problem is to convert the first batch of 1600 filepaths to the correct form. I can't seem to find anything relevant in the JabRef documentation, except for this, possibly:
"Using Regular Expression Search for Auto-Linking
...All other text is interpreted as a regular expression. But caution: You need to escape backslashes by putting two backslashes after each other to not confuse them with the path-separator."
I don't understand this. If two backslashes, one after the other, are required to prevent confusion with the 'path-separator', that seems to contradict the requirement of two backslashes to actually distinguish a path-separator.
There doesn't seem to be anything specifically concerning JabRef's filepath handling, only this reference.
JabRef is an intermediary application, between Zotero and SciPlore/Docear. The goal is to get both bibliographic data and file links into SciPlore. JabRef is supposed to help with this, by maintaining a bibtex file with the relevant file connections. The problem was that Zotero was not exporting file links, together with the bibliographic data, in a way that could be imported into SciPlore. spartanroc' s work might mean that JabRef , it was a workaround, anyway, is not required.
And, as it so happens, its worthiness extends to the task of fixing the filepath problem. Its 'Replace string' function has field-specific options, and can easily change the filepaths to the correct form.
Tools/Replace string
or Ctrl-R
The reason I did not look before, was because of an erroneous assumption that there would only be a conventional Find/Search and Replace functionality, and that a high degree of expertise in "regular expressions", and the like, would be required.
Anyway, everything works!
Hopefully, these posts will be of some benefit to those non-programmers trying to use spartanroc's modifications to achieve a better integration between Zotero and SciPlore/Docear.
I am grateful to you, spartanroc, it's saved me from a lot of repetitive work. I can now use SciPlore seamlessly.
I think I've got £2.17($3.477859) online somewhere, it's yours, have a coffee.
Unfortunately, it's not working for everyone, yet.
Theo: you are welcome.
a) you're not seeing them and
b) this seems like a good place to deal with them.
EDIT: unless of course GS translator was changed to use spantanroc's translator.