Scaffold in Firefox 3.1

Scaffold does not seem to support Firefox 3.1. Are there any plan on making it compatible?

  • Firefox 3.1 isn't an issue—you can easily override compatibility checking with the Nightly Tester Tools.

    Scaffold doesn't support Zotero 1.5, however, and updating it isn't a priority, since translators in 1.5 are stored as individual JS files in the data directory and are trivial to edit.

    If creating a new translator, just copy an existing one into a new file and generate a new GUID. The only required parts are the JSON block at the top, detectWeb(), and doWeb().

    Theoretically Zotero should reload the code every time a page is refreshed, so you'd only need to restart Firefox if you updated the target regexp in the JSON block. It may not currently be reloading the code on refreshes, however, so restart Firefox if changes don't seem to be taking.
  • edited April 8, 2009
    I've updated Scaffold's update manifest, so (after a Find Updates or automatic check) it should now install into Firefox 3.1, but it'll still only work with Zotero 1.0.9. We'd prefer translators posted to the dev list be in the new format, so if you prefer Scaffold you can write the translator in there, copy the metadata into a JSON block in a new text file, and then copy the detect and code sections (directly from Scaffold, not the SQL output) below it.
  • edited May 31, 2009
    I (still) prefer Scaffold for writing translators. Debug output is generated in the same window, and testing a change only requires the press of a button. Testing the translator results in debug-output indicating what fields are saved, instead of filling up the developer's library, which is also faster. Also, the different parts of the translator (metadata, detectWeb and doWeb) are conveniently separated. So in short, I'd like to take a look at the code to see whether I'm capable of getting it running on the trunk, but I can't access the code via SVN ( gives a 403). Could you make it available?
  • edited May 31, 2009
    Opened (though it's the same files as in the XPI itself).

    In Zotero, Zotero.Translator in translate.js and _translatorXMLToFile() in schema.js would probably be helpful.
  • Another thing: there's no separation between detect code and saving code in 2.0 translators, which would make the two code panes in Scaffold problematic when opening existing translators. So you'd probably need to have just a single code block.
  • A small update for people interested: I just opened a public Mercurial repository* to keep track of my development of a Zotero 2.0 compatible version of Scaffold. I started out with the current trunk version of Scaffold from the Zotero SVN. If I can get this working the final version can probably be merged back into the Zotero SVN. I don't have a lot of coding experience, so progress might be slow. The current version is mostly broken and is only suitable for further developing Scaffold.

  • FYI, a version with modified Zotero.Translators and Zotero.Translate won't be merged back into Zotero SVN. If there's something you can't figure out how to do with the existing architecture, let us know.
  • edited June 4, 2009
    If I get Scaffold running in combination with Zotero 2.0, I'll probably make a patch with some proposed changes to the Zotero trunk. Copying Zotero functions into Scaffold is just an (ugly) short-term solution to keep things together.
  • edited June 6, 2009
    In Zotero, Zotero.Translator in translate.js and _translatorXMLToFile() in schema.js would probably be helpful.
    How does _translatorXMLToFile() work exactly? Are the translators only XMLified in Zotero's translator repository, and if so, is the used code available somewhere?

    I'm now at the point where Scaffold has to save the translator to the local translator directory. If I could XMLify the translator code myself, I guess I could just use the unmodified _translatorXMLToFile().
  • No, don't go that route. The repository XML is still geared towards the previous SQL-based system and will be changing (since right now translators need to be converted back to SQL, with manually split detect/code blocks, just to be served via the repository. Also, _translatorXMLToFile() is a private method and not accessible externally.

    I've created, code) on the trunk. You can use that for saving. I tested it only briefly, so let me know if you have any problems with it.
  • edited June 6, 2009
    I can't seem to be able to call the new save function. Even stripping it down entirely doesn't work. I tried

    var fileName = Zotero.Translators.getFileNameFromLabel(metadata.label);
    var fileName2 =;
    (code in scaffold.js)
    this.getFileNameFromLabel = function(label) {
    return Zotero.File.getValidFileName(label) + ".js";
    //comments = function(label) {
    return Zotero.File.getValidFileName(label) + ".js";
    (code in translate.js)

    but I only get output for "Zotero.debug(fileName);" (I don't get a result for "Zotero.debug("test");" however). Renaming the new save function (from "save" to something else) also didn't work. Could it be that the save function still has to be registered someplace else?
  • 1) Are you using r4642?

    2) Do you have showInConsole enabled in about:config and the Error Console open? You can't debug Mozilla-based code without it.

    3) Be sure to pass 'code' to as well.
  • edited June 7, 2009
    @1) Mea culpa. When I switched from the latest beta to the SVN trunk I just deleted the Zotero extension folder and replaced it with the referring text file. Clearly not a smart move. Using a new profile did the trick (I got the expected output).

    @2) Up to this point I just ran Firefox from the command prompt with debug logging enabled. Thanks for the pointer. But how are error messages exactly distributed over the command prompt and the error console?
  • When I switched from the latest beta to the SVN trunk I just deleted the Zotero extension folder and replaced it with the referring text file.
    That should be fine, but you would have to run 'svn update' to get the latest revision. But a separate development profile is still a good idea. (Even if you wanted to use the trunk for your main database, I'd recommend the dev XPI over SVN.)
    But how are error messages exactly distributed over the command prompt and the error console?
    Zotero logs informational messages to the debug console, but actual errors, including native JavaScript errors such as " is not a function", will appear in the error console. Zotero will sometimes log to the debug console the exceptions it throws itself (or catches), causing those to appear in both places, but generally you need the error console open and showInConsole enabled. (Such errors would also appear in Report Errors regardless of the showInConsole setting, but that's a slow way to debug.)

    For your dev profile, I'd recommend Console2 and the -jsconsole command-line flag to open it on startup.
Sign In or Register to comment.