Zotero translator to produce html snippet

This is a follow-up question to
https://forums.zotero.org/discussion/35953/item-zotero-pane-to-item-on-zoteroorg-create-bibliography-from-item

Using the above translator, I can get zotero://... links. However, they are not recognised as links by Google docs.

Is it possible for a zotero translator to produce html snippets, which (with quick copy) are then placed on the clipboard, and can be pasted into Google docs (or Open Office etc) to give zotero style links?

Thanks!
Bjoern
«1
  • edited April 23, 2014
    so you mean a zotero://select link wrapped in <a href="zotero://select...>item title</a> ?
    Sure, that wouldn't be hard, would that work for paste to gdocs though?
  • Yes! Or even just something <a href="zotero://....">zotero</a>...
  • that doesn't work in google docs for me. I just get the plain text, so I'm not sure how this would help?
  • True - it doesn't work in Google docs, you're right. I wonder why that is. However, it does work e.g. with Open Office. That's still useful.

    Do you have an example translator that produces a html snippet?
  • I don't have a sample translator yet, know. I want to know first that it's actually useful before making it and putting it up somewhere. How are you getting this to turn into a link in OpenOffice?
  • I make an html file with
    <a href="zotero://select/items/1700609_RKPTKRPC">zotero</a>
    in it, then open this html file in a browser. I then copy and paste the link text into an open office document.

    Alternatively, if you have access to the command line, you could just run this:
    echo '<a href="zotero://select/items/1700609_RKPTKRPC">zotero</a>' | textutil -stdin -stdout -format html -convert rtf | pbcopy

    and then paste into an OO document. When I then open the link (from the open office document), the item opens in zotero (stand alone).
  • oh ok, so you're just generating an html document. I was thinking of a simple drag&drop solution.
  • Yes - because I don't know how to make a simple drag and drop solution!

    I managed to produce a plain text translator (see forum link above) that produces plain text, with an http:// link to our zotero group on zotero.org, and a zotero:// link.

    What I'd link to know is how I can get that translator to produce an html snippet, so that the zotero:// link can get an html link.

    Or am I misunderstanding something?
  • are you actually looking at the .js code? Because then that's pretty trivial - you just add the <a href=" etc. as literal strings the same way the translator adds zotero://select
  • Yes - I can add <a href="...">...</a> to the translator.js code. However, that just results in the literal text on the clipboard. The clipboard needs to be told that it's html. So how do I do that in the translator?

    Basically, my translator.js acts like this:
    echo '<a href="zotero://select/items/1700609_RKPTKRPC">zotero</a>' | pbcopy
    which puts the plain text html code on the clipboard.

    What I want is this:
    echo '<a href="zotero://select/items/1700609_RKPTKRPC">zotero</a>' | textutil -stdin -stdout -format html -convert rtf | pbcopy
    which converts the plain text html code into html, and then puts it onto the clipboard.
  • yeah, I don't believe we can do that, though I don't know enough about how the clipboard works to say for sure.
  • Ok, thanks! It would probably need a Zotero.writeHTML() function for html to complement Zotero.write() for plain text.
  • Zotero can copy formatted bibliographies to the clipboard (I believe that's RTF), so the general ability exists - I just don't know the details of that and it's very much possible that function isn't exposed to translators.
  • That seems right. Looking at the export preferences, for all the bib styles you can select "copy as html", while for the export formats "copy as html" is greyed out.
  • Hi Adam,

    here's another thought: Could you create http:// links that redirect to zotero:// links? I experimented a little with a http-equiv="refresh", and it seems to work (at least for Chrome and Zotero stand alone), but it could also work with an appropriate header in the request.

    I.e. you could set up something like
    http://zotero.org/redirect/1700609_RKPTKRPC
    which redirects to
    zotero://select/items/1700609_RKPTKRPC

    The above link would work in Google docs, and still redirect to Zotero.
  • I don't know much about security, but changing the protocol handler of a link via redirect would seem to me like a big security no-no.
  • Yeah, the zotero:// protocol can't be triggered from http:// addresses for security reasons.
  • Well, yes, and no.

    When I try this with Chrome, I get an "external protocol request" warning. But if I agree to that, then the item opens in Zotero just fine!

    What I did was put
    <meta http-equiv="refresh" content="0; url=zotero://select/items/1700609_NHM4H2R9" />
    into the header of an html page.

    Bjoern
  • Here's a small experiment, in setting the location header. E.g. to get
    zotero://select/items/1700609_NHM4H2R9

    Use this:
    http://oer.educ.cam.ac.uk/zotero/select/1700609_NHM4H2R9

    (This item is not public, but you can use your own zotero item code!)
    Bjoern
  • OK — I was referring to Firefox and Zotero for Firefox, where the zotero:// protocol is implemented natively. In Standalone, where Standalone just registers itself as a protocol handler with the OS, different browsers likely handle it differently.
  • It seems to work in the firefox Zotero pane as well. It opens a new page, that says "Corrupted Content", but the item is selected in the firefox pane nevertheless.
  • Oh, I think that can pretty fairly be called a bug in Firefox. Firefox throws a security warning if you click on a zotero:// link from a http:// page ("Security Error: Content at http://[...]/test.html may not load or link to zotero://select/items/[...]"), so I think the fact that this (sort of) works via Location: is an oversight. But judging by https://bugzilla.mozilla.org/show_bug.cgi?id=424201, which is essentially the same thing from an <img> tag, they don't seem too concerned. It actually works from an iframe as well — you can successfully display, for example, a Zotero timelime in an iframe from an http:// URL.

    It doesn't look like it exposes content in any way, at least as far as I can tell, but it certainly means that we shouldn't allow any data-modifying operations via the protocol handler.

    Anyway, I wouldn't really rely on this behavior in Firefox, since either Mozilla or we might fix it at any time. But this should continue to work from other browsers to Standalone like any other protocol scheme. (If we can figure out a way to display a similar prompt for Zotero for Firefox when zotero:// links are triggered, that would be a possible solution.)
  • Thanks for the comments!

    So does this also mean that zotero:// links (e.g. in OO or Google Docs) would only ever be able to interact (reliably, officially) with Zotero stand alone, and that any interaction with the Zotero Firefox pane is accidental, and not intended?

    It would be really nice to have two way interaction between a Google document and the Firefox pane, within the same window - but that doesn't seem possible?

    Thanks!
  • So does this also mean that zotero:// links (e.g. in OO or Google Docs) would only ever be able to interact (reliably, officially) with Zotero stand alone, and that any interaction with the Zotero Firefox pane is accidental, and not intended?
    As it stands now, yes. But we might be able to intercept zotero:// link clicks and display an appropriate prompt. It would make me a little nervous to allow permanent whitelisting, but I guess it's no different from what other browsers allow (which actually means we wouldn't want to allow any data-modifying operations anyway).

    For Google Docs, I don't know that it's relevant. A solution for Google Docs may very well be more sophisticated and not need to rely on zotero:// links. In any case, Zotero for Firefox can do whatever it wants with any webpage. The connectors are a bit more limited.
  • I have one more question about this!

    How does the number in:
    http://zotero.org/groups/257089/items/WUXAHI8Z

    relate to the number in:
    zotero://select/items/1669433_WUXAHI8Z

    (I.e. 257089 vs. 1669433).

    In particular, will the zotero:// link work for everybody, or does the number refer to a group specifically within my zotero app?

    Thanks!
    Bjoern
  • edited April 27, 2014
    Yep. (or rather, "Nope" -- see Dan's explanations below).

    As I understand it, the zotero.org URL carries a globally unique groupID. The zotero://select address carries a libraryID, which is specific to the local client.

    You can translate between the two with: Zotero.Groups.getGroupIDFromLibraryID(libraryId);
    and
    Zotero.Groups.getLibraryIDFromGroupID(groupId);
  • edited April 27, 2014
    but as fbennett implies, the zotero://select link does _not_ work across clients for items in a group- which has legacy reasons, but is rather unfortunate.

    this is wrong. See Dan below.
  • Close: both the group ID and library ID are global identifiers, but a libraryID can be for either a user or group library, allowing us to have a single integer to identify a library. Each library has a separate globally unique userID or groupID that requires the library type (user or group).

    (fbennett is thinking of the numeric itemID, which, unlike the item key, is local to the client. A libraryID and an item key together globally identify an item.)

    libraryIDs aren't really exposed anywhere else (and probably wouldn't be in report URLs either if I had really considered that people would use them externally).
  • but as fbennett implies, the zotero://select link does _not_ work across clients for items in a group
    No, it does.

    The URLs that don't work are the ones that still use the itemID, such as zotero://attachment/<itemID>
  • edited April 27, 2014
    libraryIDs aren't really exposed anywhere else (and probably wouldn't be in report URLs either if I had really considered that people would use them externally).
    We could actually fix this easily by just allowing something like zotero://select/groups/<groupID>/items/<itemKey> in addition to the current scheme — that is, essentially mirroring the API URL format, just with a prefix to determine the action.
Sign In or Register to comment.